Status Update
Comments
bd...@google.com <bd...@google.com> #2
Hello, thanks for reporting.
I can reproduce this issue by targeting SDK 35 and running the test on an emulator running Android 35.
I couldn't reproduce in a test that detects that content is occluded though. Both isDisplayed()
and !isNotDisplayed()
still return true, which seems to be caused by a bug in View.getGlobalVisibleRect
, which doesn't take the action bar into account either and which we rely on to get the clipped bounds of the AbstractComposeView.
I also couldn't reproduce with a View only test using Espresso and the following assertion: Espresso.onView(withText("Hello World")).check(matches(isCompletelyDisplayed()))
. Espresso also seems to rely on View.getGlobalVisibleRect
(
vi...@gmail.com <vi...@gmail.com> #3
Thank you for addressing this issue. I believe verifying the visibility and clickability of UI components is crucial for both UI and AI agent tests. Therefore, I think it's worth filing an issue to address this. Currently, I can achieve this through touch events, but it's not an ideal solution.
@RunWith(AndroidJUnit4::class)
class ExampleInstrumentedTest {
@get:Rule
val composeTestRule = createComposeRule()
@Test
fun useAppContext() {
composeTestRule.setContent {
Column {
var isClicked by remember { mutableStateOf(false) }
// You can click the Button with this text
// Text("Hello\n\n\n\n\n\n\n\n\n\n World, $isClicked")
Button(onClick = { isClicked = true }) {
Text("Click me $isClicked")
}
}
}
val rect = composeTestRule.onNode(hasText("Click me false")).getBoundsInRoot()
val activity = (composeTestRule as AndroidComposeTestRule<*, *>).activity
val metrics = activity.windowManager.currentWindowMetrics
val density = metrics.density
println("density: $density $rect")
val x = (rect.left.value + rect.width.value / 2F) * density
val y = (rect.top.value + rect.height.value / 2F) * density
println("x: $x, y: $y")
activity.runOnUiThread {
activity.window.decorView.dispatchTouchEvent(MotionEvent.obtain(0, 0, MotionEvent.ACTION_DOWN, x, y, 0))
activity.window.decorView.dispatchTouchEvent(MotionEvent.obtain(0, 0, MotionEvent.ACTION_UP, x, y, 0))
}
composeTestRule.onNode(hasText("Click me true")).assertIsDisplayed()
}
}
bd...@google.com <bd...@google.com> #4
Clicks sent with the input injection methods (performClick
, performTouchInput
, etc) are not affected by the occlusion because we're essentially doing the same as in your workaround; we send the MotionEvents directly to the View that's hosting the compose content. You should be able to replace your custom injection logic with composeTestRule.onNode(hasText("Click me false")).performClick()
. If that doesn't pass, can you try the following test?
@Test
fun clickUnderActionBar() {
var clicked = false
composeTestRule.setContent {
Button(onClick = { clicked = true }) { Text("Click me") }
}
composeTestRule.onNodeWithText("Click me").performClick()
composeTestRule.runOnIdle { assert(clicked) { "Box was not clicked" } }
}
se...@gmail.com <se...@gmail.com> #5
Thank you for your continued work on this issue and the information about performClick()
.
I confirmed that both composeTestRule.onNode(hasText("Click me false")).performClick()
and the clickUnderActionBar()
test work as expected.
My aim was to provide a reproducing test case that demonstrates user clicks are unable to reach components as expected when they are overlaid by the ActionBar.
I'm very positive about the current direction of applying the appropriate theme, and I believe this approach will effectively resolve the underlying issue.
Thank you again for your efforts.
jh...@googlemail.com <jh...@googlemail.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Jelle Fresen <
Link:
Use NoActionBar theme for default test activity
Expand for full commit details
Use NoActionBar theme for default test activity
When targeting SDK 35, an activity is edge-to-edge by default. The
default theme has an ActionBar, which is now overlapping with the UI.
Fix this by setting a NoActionBar theme to remove the ActionBar. This
should not be a problem for existing tests, as the intended usecase for
using the ComponentActivity as a compose host is to test composables in
isolation.
Also changes the inappropriately named ActivityWithActionBar we use for
internal testing with the more appropriate name
CustomComposeHostActivity, as it had nothing to do with having an action
bar or not.
Bug: 383368165
Test: Added regression test in ComponentActivityLaunchesTest
Relnote: "The activity that is used as the host for the composable under
test when using `ComposeContentTestRule.setContent` now uses the theme
`Theme.Material.Light.NoActionBar`, to avoid the ActionBar from
overlapping with test content when targeting SDK 35. To opt out of this
behavior, you can remove the dependency on `ui-test-manifest` and add an
activity entry in your test app's AndroidManifest.xml for
ComponentActivity with the theme of your choice."
Change-Id: I7ae1bd28f5e341dafc07442b35ee4249793d257d
Files:
- M
compose/material/material-navigation/build.gradle
- M
compose/ui/ui-test-manifest/integration-tests/testapp/build.gradle
- M
compose/ui/ui-test-manifest/integration-tests/testapp/src/androidTest/java/androidx/compose/ui/test/manifest/integration/testapp/ComponentActivityLaunchesTest.kt
- M
compose/ui/ui-test-manifest/src/main/AndroidManifest.xml
- M
compose/ui/ui-test/src/androidInstrumentedTest/AndroidManifest.xml
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/BitmapCapturingTest.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/CustomComposeHostActivity.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/IsDisplayedTest.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/gesturescope/SendClickTest.kt
- M
constraintlayout/constraintlayout-compose/build.gradle
Hash: 18d7693b4eba2ec6b1d1162b2154e914ba6ef25d
Date: Mon Dec 16 20:31:21 2024
jh...@googlemail.com <jh...@googlemail.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material-navigation:1.8.0-alpha08
androidx.compose.ui:ui-test:1.8.0-alpha08
androidx.compose.ui:ui-test-android:1.8.0-alpha08
androidx.compose.ui:ui-test-jvmstubs:1.8.0-alpha08
androidx.compose.ui:ui-test-linuxx64stubs:1.8.0-alpha08
androidx.compose.ui:ui-test-manifest:1.8.0-alpha08
vi...@gmail.com <vi...@gmail.com> #8
The current state in android is currently :
* Default browser: No support
* Opera Mini : OK but no access to intranet
* Opera Micro : OK but in beta
* Firefox : OK but in beta and unusable with current partition
sizes on most android phones as it create a multi megabyte cache
on main partition.
* Java applications, Ok since Gingerbread. Obviously you need a rendering
engine to render webpages but at least REST calls could now work.
Basically there are downsides to every solution but the clear picture is that SNI support is now working everywhere in android except in the default browser.
Next version of Debian (Stable !!!) will even integrate the correct version of apache to support SNI server side out of the box...
jh...@googlemail.com <jh...@googlemail.com> #9
jh...@googlemail.com <jh...@googlemail.com> #10
bd...@google.com <bd...@google.com>
sc...@gmail.com <sc...@gmail.com> #11
at...@gmail.com <at...@gmail.com> #12
bd...@google.com <bd...@google.com> #13
SNI might work on 2.3 with alternative browsers that have their own https stack, such as Firefox. Usually I test with
(changing owner since the old username was no longer valid)
ma...@klauseder.com <ma...@klauseder.com> #14
ch...@gmail.com <ch...@gmail.com> #15
bd...@google.com <bd...@google.com> #16
vi...@gmail.com <vi...@gmail.com> #17
Non "corporate gibberish" summary :
* Gingerbread (2.3) Will never get this update officially.
* Honeycomb (3.0) contains the fix but isn't available on phones.
* Ice Cream Sandwich (4.0) will provide this feature to phones but isn't already available (soon).
Also :
* The fix from Honeycomb could have been backported by the manufacturers that got it's source code but none that I know off did it.
* As Honeycomb is a closed source release none of the alternative distribution could merge the patch without re-developing it.
* As Ice Cream Sandwitch will include this patch it will be in all distributions and could even be backported to Gingerbread.
Sadly coupled with the fact that google don't control at all the updates of previous phones it lock SNI in an "Unusable for most of Android users" state for 2+ Years at least for environements where you don't control users hardware.
At least now for companies you could plan an upgrade (software or hardware depending on the phone models your employees got) as soon as ICS is released.
[Deleted User] <[Deleted User]> #18
[Deleted User] <[Deleted User]> #19
[Deleted User] <[Deleted User]> #20
I am developer and I am facing the same issue. Do you know how we can overcome this issue from server side.
Description
- Steps to reproduce the problem.
- Open the android browser
- Browse to the page
- What happened.
- The browser displayed a security alert but shouldn't have if SNI was working.
- The test site doesn't report SNI as enabled.
- What you think the correct behavior should be.
- As the chrome browser and all other modern browsers SNI should be supported.
Don't forget to mention which device you have, and which version of Android
is installed on it. (Find it under Home > Menu > Settings > About phone.)
- The device is an HTC Desire
- Android is at version 2.2 (CyanogenMod-6.0.2-Desire) but the android emulator with the 2.2 rom seem to have the same behavior.