Status Update
Comments
ri...@gmail.com <ri...@gmail.com> #2
pa...@google.com <pa...@google.com> #3
I don't think we plan on replacing current Dialog with a full compose one.
ni...@google.com <ni...@google.com> #4
po...@google.com <po...@google.com>
ci...@google.com <ci...@google.com> #5
Note that there are some optimization in place currently in the window manager that makes sure that you won't have multiple scrims when multiple dialogs are showing. I'm not sure if that's really common enough of an issue to preserve, but I thought I'd mention it.
pa...@google.com <pa...@google.com>
le...@gmail.com <le...@gmail.com> #6
we have experienced a bug when clicking on the part of the ui quickly will cause the click to go through while the dialog is not rendered yet
I believe that might be connected to the "When clicking anywhere, the touch should be consumed even if there are no click listeners" part of the issue
I must admit that the scenario can rarely happen in the real world, but it can still happen
please see the video attached
thank you
zu...@tutu.tech <zu...@tutu.tech> #7
When clicking the area around the dialog, the dialog should be dismissed (or not, depending on its configuration, similar to setCanceledOnTouchOutside)
When clicking anywhere, the touch should be consumed even if there are no click listeners
The scrim color of Android's Dialog should be fully transparent, it should be drawn by the Compose Dialog.
All of it was introduced in Material3 1.3.0 in ModalBottomSheet
Please make similar changes to androidx.compose.ui.window.Dialog
lo...@gmail.com <lo...@gmail.com> #8
4+ years passed. anyone alive of the maintainers?
lp...@google.com <lp...@google.com> #9
The dialog exposes configuration for handling dismissing on click outside / back press. We don't have plans to move scrim drawing outside, as this gets complicated for multi-window cases, and it's better to leave the window manager handle this directly.
When clicking anywhere, the touch should be consumed even if there are no click listeners
For this specifically, this is inconsistent with normal Android dialogs, which do not consume events if the dialog cannot be dismissed by a touch outside.
If there is a specific feature request here that you have, please file a new bug - we have no plans to address anything listed in this existing (and obsolete) bug.
ak...@gmail.com <ak...@gmail.com> #10
The scrim color of Android's Dialog should be fully transparent, it should be drawn by the Compose Dialog.
Does this mean the current Dialog implementation uses the scrim color from Android's Dialog?
I'm encountering an issue on Chinese Android OEM devices (Point-of-sale) where the dialog scrim color isn't displaying correctly; there's no scrim behind the dialog. This problem is similar to an issue reported on the Android emulator (see
So I'm not sure that drawing the scrim/background within the Compose Dialog will resolve this, or not.
lp...@google.com <lp...@google.com> #11
Does this mean the current Dialog implementation uses the scrim color from Android's Dialog?
Yes, Compose does not apply any scrim effect manually, it just comes from the Dialog's implementation - and as mentioned in
re...@gmail.com <re...@gmail.com> #12
I'm sorry, but reading that this issues was closed as infeasible, and Google is not even trying to fix this on future Android SDKs, in case that is the only way, is somewhat disappointing to me.
Closing this as won't fix, also includes not fixing things like, not being able to set scrim color (reported
Anyway, it just feels like Jetpack Compose will unfortunately always be lacking functionality and be somewhat dependent on Android View, which is sad based on how far the project has got.
lp...@google.com <lp...@google.com> #13
Closing this as won't fix, also includes not fixing things like, not being able to set scrim color (reported here) on Compose Dialogs, while modal bottom sheet dialogues do have such capability.
This is a separate issue. ModalBottomSheetDialog is a more opinionated dialog / layout, for example it always takes up the entire window so it is able to just draw a scrim. Other dialogs like an AlertDialog do not take up the whole window, and window manager draws a scrim behind the dialog accordingly.
We should make it possible to disable the default scrim / background, so you can draw your own scrim in cases where your dialog is full screen (this is what ModalBottomSheetDialog does) - but that is unrelated to what is discussed in this bug, which was about always drawing the scrim within Compose code, both for full screen / smaller dialogs.
ap...@google.com <ap...@google.com> #14
Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <
Link:
Removes obsolete Dialog TODO
Expand for full commit details
Removes obsolete Dialog TODO
This bug is closed as infeasible
Bug: b/159900354
Test: n/a
Change-Id: Ie3bfff55c7c56165feef5766ebe3615789905f18
Files:
- M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/window/AndroidDialog.android.kt
Hash: 5a72e173ae06c327ff60f0eb6ec1a0cc21404ee1
Date: Fri Jan 31 12:41:36 2025
Description
Currently, a dialog has a scrim around it that we get from Android's Dialog implementation. This should ideally all move to Compose, where the Android Dialog will just be a full screen panel for our Compose implementation of Dialog.
Take care of the following caveats:
The margins should be 24.dp (see b/144798445 )