Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
mu...@gmail.com <mu...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug: b/264018028
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
https://android-review.googlesource.com/2373449
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
d....@gmail.com <d....@gmail.com> #4
deleted
an...@gmail.com <an...@gmail.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
an...@gmail.com <an...@gmail.com> #6
Tested on google PixelXL(API 29) also same issue so it's not device specific.
il...@google.com <il...@google.com> #7
There's a couple of problems here relating to how Dialogs and Fragments work:
1. Dialogs are separate windows that always sit above your activity's window. This means that the dialog will continue to intercept the system back button no matter what state the underlying FragmentManager is in or what FragmentTransactions you do.
2. Operations on the fragment container (i.e., your normal <fragment> destinations) don't affect dialog fragments. Same if you do FragmentTransactions on a nested FragmentManager.
The initial release of Navigation's <dialog> support did not take these limitations into account and would treat dialog destinations just like any other in that, from Navigation's point of view, they could be put on the back stack and treated like any other <fragment> destination.
As that's not actually the case, we've made a few changes for Navigation 2.1.0-alpha06 to ensure that Navigation's state of the world matches what you actually see on the screen and prevent crashes like that in comment#5 .
The summary of this is that <dialog> destinations are now automatically popped when navigate to a non-dialog and non-activity destination, such as a <fragment> destination. For reference, this was done inhttps://android-review.googlesource.com/996359 and https://android-review.googlesource.com/1007662
1. Dialogs are separate windows that always sit above your activity's window. This means that the dialog will continue to intercept the system back button no matter what state the underlying FragmentManager is in or what FragmentTransactions you do.
2. Operations on the fragment container (i.e., your normal <fragment> destinations) don't affect dialog fragments. Same if you do FragmentTransactions on a nested FragmentManager.
The initial release of Navigation's <dialog> support did not take these limitations into account and would treat dialog destinations just like any other in that, from Navigation's point of view, they could be put on the back stack and treated like any other <fragment> destination.
As that's not actually the case, we've made a few changes for Navigation 2.1.0-alpha06 to ensure that Navigation's state of the world matches what you actually see on the screen and prevent crashes like that in
The summary of this is that <dialog> destinations are now automatically popped when navigate to a non-dialog and non-activity destination, such as a <fragment> destination. For reference, this was done in
j....@gmail.com <j....@gmail.com> #8
So what I can do to show the dialog again when the user press back on the fragment?
[Deleted User] <[Deleted User]> #9
So what I can do to show the dialog again when the user press back on the fragment?
Is this still not possible?
ar...@gmail.com <ar...@gmail.com> #10
So, what you suggest to do for this case? Are there alternative solutions?
il...@google.com <il...@google.com> #11
Dialog destinations cannot be put on the back stack, that's still and will always be the case.
gu...@gmail.com <gu...@gmail.com> #12
I think the only solution at present is to make fragment B a full dialog
Description
Version used: 2.1.0-alpha04
Devices/Android versions reproduced on: S10
I am trying to navigation from DialogFragment to Fragment in Navigation Component, but getting weird result.
When I navigate from DialogFragment to Fragment, background fragment is changing to target fragment with current dialog on top of it, instead of just moving to target fragment. Why I am getting this behavior or how to fix it?
By fixing I mean normal dialog behavior. Say, I have a dialog D on top of a fragment A and move to a fragment B from a button on D, the screen should show B. And when I pop back from B, it should go to previous stage of D on top of A.
Here is the navigation graph.
<navigation
xmlns:android="
xmlns:app="
xmlns:tools="
android:id="@+id/home"
app:startDestination="@+id/titleScreen">
<fragment
android:id="@+id/titleScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.Title"
android:label="@string/title_home"
tools:layout="@layout/fragment_title">
<action
android:id="@+id/action_title_to_about"
app:destination="@id/aboutScreen"/>
</fragment>
<dialog
android:id="@+id/aboutScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.About"
android:label="@string/title_about"
tools:layout="@layout/fragment_about">
<action
android:id="@+id/action_aboutScreen_to_register"
app:destination="@id/register" />
</dialog>
<fragment
android:id="@+id/register"
android:name="com.example.android.navigationadvancedsample.formscreen.Register"
android:label="fragment_leaderboard"
tools:layout="@layout/fragment_leaderboard" />
</navigation>
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).