Status Update
No update yet.
Comments
po...@google.com
Over to Ralston to take a look. I imagine with the new relocation logic it should be fixed?
po...@google.com
se...@google.com
What is happening here is that the TextField does not know that it is in a scrollable container, and since the keyboard is going to hide the currently focused text, the text field calls View.requestRectangleOnScreen which causes the entire app to pan up, and that clips the top bar.
The Relocation APIs are experimental right now. It is not used in TextField as we are past the alpha stage and can only use stable APIs in TextField. So this bug can only be fixed post 1.0
se...@google.com
This should be fixed by
I verified that this sample code now works when soft input mode is AdjustResize.
ae...@google.com
Mihai has transferred to a different team, my team is the Popup/Dialog owner now (albeit we don't have many cycles to work on it).
The main benefit is that almost all external developers use Popup itself and they would find it burdensome to maintain a copy of it. If ExposedDropdownMenuPopup requires these capabilities it's very likely that external developers would want it too.
se...@google.com
Understood!
Does it make sense to have this bug live (re-worded) under foundation specifically?
ae...@google.com
It's in UI not Foundation, but sure.
lp...@google.com
Would it be feasible to expand popup and popupproperties in a way that could be sufficiently generic for every use case, i.e. exposing all window flags or most relevant ones?
Yeah, some discussions in related bugs have been around giving full control to fully customize window flags, instead of exposing specific properties for each thing that might need to be customized. Long term we definitely should move away from custom implementations, there's a huge amount of code duplication, and it makes it tricky to handle any bug fixes we make with regards to complex things like sizing / focus / accessibility / etc. So we should either keep this bug to track migrating Material components when we land support for this in UI, or file a separate bug to make sure we do the migration part in the future
ma...@google.com
ap...@google.com
Branch: androidx-main
commit eb9707742d46866f4581ba378e527bb74050567f
Author: Max Alfonso-Ying <maxying@google.com>
Date: Tue Feb 20 19:42:54 2024
Use Popup for ExposedDropdownMenu
Test: Updated unit tests. Updated benchmarks because Popup can't be benchmarked directly
Fixes:
Change-Id: Id7a53238cdbcde8c6ecaebea1f6c943a852b40f4
M compose/material3/benchmark/src/androidTest/java/androidx/compose/material3/benchmark/ExposedDropdownMenuBenchmark.kt
M compose/material3/benchmark/src/androidTest/java/androidx/compose/material3/benchmark/MaterialBenchmarkExtensions.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ExposedDropdownMenuTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ExposedDropdownMenu.android.kt
ma...@google.com
I have a CL out to remove it in the M3 version. The M2 version has not been changed so those dependencies have to stay.
ap...@google.com
Branch: androidx-main
commit a9d91e38507845c76e664c819fc079897e719c35
Author: Max Alfonso-Ying <maxying@google.com>
Date: Tue Mar 12 23:07:06 2024
Delete unused ExposedDropdownMenuPopup
Bug:
Test: n/a
Change-Id: Ie3be18c0014ce368af19ffd187cd71d8af6c0bf5
M compose/material3/material3/build.gradle
D compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/ExposedDropdownMenuPopup.android.kt
Description
No description yet.