Closed Bug 1760880 Opened 9 months ago Closed 9 months ago

Recent regression in GV release 100.0.20220322065927: UIAutomator unable to locate widget content elements in all app clients (UI Tests on mobile apps failing)

Categories

(Core :: Disability Access APIs, defect)

ARM64
All
defect

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 --- unaffected
firefox100 --- fixed

People

(Reporter: aaronmt, Assigned: eeejay)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Assuming this is GeckoView related as there is nothing else on A-C upgrade that is causing issues.

Last working A-C version: 100.0.20220321143410
Broken A-C version: 100.0.20220322143329

https://github.com/mozilla-mobile/android-components/commit/44200eff24cfa3420c8eeade7077220669699abb

So therefore last working version: 100.0.20220321065848
Broken version: 100.0.20220322065927

What changed in this update?

UiAutomator which we use for locating elements in Gecko on Android is not working, thus all interactions with web content (e.g, clicking a link) are not working.

Example Espresso/UI Automator test: https://github.com/mozilla-mobile/fenix/blob/master/app/src/androidTest/java/org/mozilla/fenix/ui/DownloadTest.kt#L68

Tagging possible candidate bug 1756700 maybe (?) need changelog (:jnicol)

Attaching an example XML hierarchy

Regressed by: 1756700
Summary: Recent regression in 100.0.20220322065927: UIAutomator unable to locate elements in all app clients (UI Tests on mobile apps failing) → Recent regression in GV release 100.0.20220322065927: UIAutomator unable to locate widget elements in all app clients (UI Tests on mobile apps failing)
Summary: Recent regression in GV release 100.0.20220322065927: UIAutomator unable to locate widget elements in all app clients (UI Tests on mobile apps failing) → Recent regression in GV release 100.0.20220322065927: UIAutomator unable to locate widget content elements in all app clients (UI Tests on mobile apps failing)

Set release status flags based on info from the regressing bug 1756700

:jnicol, since you are the author of the regressor, bug 1756700, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(jnicol)

Bug 1756700 landed well before the last working version identified above. Is there a reason you suspect it's related to this?

Here is the pushlog between the last good and first bad version

Flags: needinfo?(jnicol) → needinfo?(aaron.train)

Does UIAutomator use accessibility? I'm wondering if it's related to Bug 1758540

(In reply to Jamie Nicol [:jnicol] from comment #5)

Bug 1756700 landed well before the last working version identified above. Is there a reason you suspect it's related to this?

Whoops I was looking at the wrong push logs

(In reply to Agi Sferro | :agi | [slow ni? rn sorry] | ⏰ PST | he/him from comment #6)

Does UIAutomator use accessibility? I'm wondering if it's related to Bug 1758540

That is indeed the culprit. Tested by disabling the Gecko preference and my tests ran successfully locally here (the ones that are touching web content clicking on links).

I know nothing about the feature and how it interacts with UIAutomator.

:eeejay any thoughts here? Worst case, maybe there's a way to disable the preference in pre-setup steps?

Component: General → Disability Access APIs
Flags: needinfo?(aaron.train)
Product: GeckoView → Core
Regressed by: 1758540
No longer regressed by: 1756700
Flags: needinfo?(eitan)

The hierarchy for the web content seems to be there. Can you post another version with caching preffed off to see how it differs? My original thought was that we don't pass resource-id, but that depends on DOM id which is anyway absent from that page, so it must be something else..

Flags: needinfo?(eitan) → needinfo?(aaron.train)

Sure. The only difference I see are bound coord changes. This is the test page HTML I am dumping (i.e, adb exec-out uiautomator dump /dev/tty
): https://storage.googleapis.com/mobile_test_assets/test_app/downloads.html

Flags: needinfo?(aaron.train)
Has Regression Range: --- → yes

Aside, I don't see any related GeckoRuntimeSetting I can toggle from the application context as a workaround (I see fullAccessibilityTree but I'm not sure how to set that from application context post activity launch without touching app code). This bug is blocking a large chunk of content related UI tests on Focus/Fenix.

Flags: needinfo?(eitan)

Thanks Aaron, I'm looking into this right now.

Flags: needinfo?(eitan)

Do we know what caused this? Is this something we can back out? Currently this is preventing Fenix PRs from landing (since yesterday).

Flags: needinfo?(eitan)

I am looking for a solution right now, if i can't resolve this quickly we will need to back out bug 1758540.

Flags: needinfo?(eitan)

(In reply to Eitan Isaacson [:eeejay] from comment #13)

I am looking for a solution right now, if i can't resolve this quickly we will need to back out bug 1758540.

Thanks!

Testing this is hard because the point of failure would be if we
recieved NotifyOfResolutionChange before the IPC doc is constructed.

Assignee: nobody → eitan
Status: NEW → ASSIGNED
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4761e9b4843d
Push document resolution in initial cache. r=morgan
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

Looks like a fixed version of geckoview was pulled into A-C. Aaron, can you confirm that espresso tests are passing?

Flags: needinfo?(aaron.train)

(In reply to Eitan Isaacson [:eeejay] from comment #18)

Looks like a fixed version of geckoview was pulled into A-C. Aaron, can you confirm that espresso tests are passing?

Eitan, it looks like there are still a number of problems in our Content testing Espresso UI tests with some working with this fix and a number of failures and timeouts: https://console.firebase.google.com/u/0/project/moz-fenix/testlab/histories/bh.66b7091e15d53d45/matrices/5849132562068109450

pref flip backed out : https://hg.mozilla.org/mozilla-central/rev/8df21a016510fb6197417c1754ea22c5413f04b3 (new GV nightlies under way as per RyanVM)

Flags: needinfo?(aaron.train)

I can't access that firebase link -- it just sits at loading :( is there another way to see the test failures?

(In reply to Morgan Reschenberg [:morgan] from comment #20)

I can't access that firebase link -- it just sits at loading :( is there another way to see the test failures?

Check your email for an invitation to Firebase.

With a revert of A-C on Fenix, UI tests are in a working order https://github.com/mozilla-mobile/fenix/commit/26891cd44dad062b94e73a6ac1637696813b585f at the moment.

As a fix for this already landed, I wonder if this isn't still related: https://console.firebase.google.com/u/0/project/moz-fenix/testlab/histories/bh.66b7091e15d53d45/matrices/8340803670320999655/executions/bs.3f4e6bd3f9ff34bc/testcases/1/logs

04-05 14:28:48.667: W/BinderNative(2070): Uncaught exception from death notification 04-05 14:28:48.667: W/BinderNative(2070): java.lang.NullPointerException: Attempt to read from field 'android.accessibilityservice.IAccessibilityServiceClient com.android.server.accessibility.AbstractAccessibilityServiceConnection.mServiceInterface' on a null object reference 04-05 14:28:48.667: W/BinderNative(2070): at com.android.server.accessibility.UiAutomationManager.destroyUiAutomationService(UiAutomationManager.java:179) 04-05 14:28:48.667: W/BinderNative(2070): at com.android.server.accessibility.UiAutomationManager.access$200(UiAutomationManager.java:41) 04-05 14:28:48.667: W/BinderNative(2070): at com.android.server.accessibility.UiAutomationManager$UiAutomationService.binderDied(UiAutomationManager.java:230) 04-05 14:28:48.667: W/BinderNative(2070): at android.os.BinderProxy.sendDeathNotice(Binder.java:1193) 04-05 14:28:48.668: W/SurfaceFlinger(1943): Attempting to destroy on removed layer: AppWindowToken{28d9acb token=Token{221119a ActivityRecord{2f5f645 u0 org.mozilla.fenix.debug/org.mozilla.fenix.HomeActivity t4}}}#0 04-05 14:28:48.669: W/ActivityManager(2070): Crash of app org.mozilla.fenix.debug running instrumentation ComponentInfo{org.mozilla.fenix.debug.test/androidx.test.runner.AndroidJUnitRunner} 04-05 14:28:48.669: I/ActivityManager(2070): Force stopping org.mozilla.fenix.debug appid=10092 user=0: finished inst 04-05 14:28:48.669: I/ActivityManager(2070): Killing 7028:org.mozilla.fenix.debug:tab7/u0a92 (adj 0): stop org.mozilla.fenix.debug

Two UI tests suddenly failed on Focus after Android-Components 102.0.20220524015637 update.
#7098 #7099

You need to log in before you can comment on or make changes to this bug.