Closed Bug 1534287 Opened 3 years ago Closed 2 years ago

Crash in [@ java.lang.IllegalStateException: at android.view.accessibility.AccessibilityManager.sendAccessibilityEvent(AccessibilityManager.java)]

Categories

(Firefox for Android Graveyard :: General, defect, P1)

Unspecified
Android
defect

Tracking

(firefox-esr6873+ fixed, firefox65 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 wontfix, firefox72 wontfix, firefox73 wontfix, firefox74 fixed)

RESOLVED FIXED
Firefox 74
Tracking Status
firefox-esr68 73+ fixed
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- fixed

People

(Reporter: marcia, Assigned: eeejay)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-e6055628-1964-4a19-84e6-ebe0b0190309.

Seen while looking at nightly data, but visible all the way back to at least 64: https://bit.ly/2F4wWDd. About 1800 crashes so far in 65/65.01.

Very high correlation to zh-CN:
(100.0% in signature vs 16.71% overall) accessibility = Active
(99.72% in signature vs 25.39% overall) moz_crash_reason = MOZ_CRASH(Uncaught Java exception)
(19.83% in signature vs 00.95% overall) adapter_device_id = Mali-G72 MP3 [80.90% vs 03.02% if adapter_vendor_id = ARM]
(72.73% in signature vs 02.33% overall) useragent_locale = zh-CN

Java stack trace:

java.lang.IllegalStateException
	at android.view.accessibility.AccessibilityManager.sendAccessibilityEvent(AccessibilityManager.java:478)
	at android.view.ViewRootImpl.requestSendAccessibilityEvent(ViewRootImpl.java:7827)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at android.view.ViewGroup.requestSendAccessibilityEvent(ViewGroup.java:1049)
	at org.mozilla.geckoview.SessionAccessibility.sendEvent(SessionAccessibility.java:736)
	at org.mozilla.geckoview.SessionAccessibility$NativeProvider$1.run(SessionAccessibility.java:777)
	at android.os.Handler.handleCallback(Handler.java:873)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:201)
	at android.app.ActivityThread.main(ActivityThread.java:6806)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Marking fix optional per the triage.

Very trivial volume. Closing this one out as WFM.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

Reopening since this has resurfaced in Fennec 68.1.1 in the top 20 crashes. APIs range from 21 to 29. Various OPPO devices are the top crashers, including PACM00.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Stefan can you prioritize and get someone to look at this?

Priority: P5 → --

Petru, does your team have cycles to look into this Fennec crash?

Flags: needinfo?(petru.lingurar)
Flags: needinfo?(petru.lingurar)
Priority: -- → P1

Based on my findings, AccessibilityManager throws an IllegalStateException if accessibility if it is not enabled - https://android.googlesource.com/platform/frameworks/base/+/ee0b3e9/core/java/android/view/accessibility/AccessibilityManager.java#256 .

I see we have a check in place - https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/SessionAccessibility.java#754, but somehow we still end up in that exception.

@Eitan, since :neha mentioned this bug being a regression, could it have been introduced from bug 1535701? I see that the affected area is in geckoview and I'm not too familiar with it

Flags: needinfo?(eitan)

Possibly? I wonder if isInTest is returning true in some special conditions that I am not aware of. Might just be worth catching that exception.

Flags: needinfo?(eitan)
Assignee: nobody → eitan

I think there are some cases when gecko a11y is turned on - but not system a11y, and for some reason there is no attached display. Let's just catch the exception and stop checking for system a11y at all.

Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f4cc06c14090
Catch exception when sending a11y event when platform a11y is disabled. r=geckoview-reviewers,snorp
Status: REOPENED → RESOLVED
Closed: 3 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 74

Is this patch applicable to Fennec on ESR68 also or is a different patch needed there? If it's OK to uplift as-is, please nominate for approval.

Flags: needinfo?(eitan)

Comment on attachment 9119888 [details]
Bug 1534287 - Catch exception when sending a11y event when platform a11y is disabled. r?#geckoview-reviewers!

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes a common crasher
  • User impact if declined: More crashes
  • Fix Landed on Version: 74
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a simple catch statement. It has been in nightly for a while.
  • String or UUID changes made by this patch:
Flags: needinfo?(eitan)
Attachment #9119888 - Flags: approval-mozilla-esr68?

Comment on attachment 9119888 [details]
Bug 1534287 - Catch exception when sending a11y event when platform a11y is disabled. r?#geckoview-reviewers!

a11y crash fix for fennec 68.5

Attachment #9119888 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

Hi, unfortunately we do not own Oppo phones and on the available devices I could not reproduce the issue in order to verify the patch on the latest beta build.
I will leave the ticket as it is, to see whether the crash signature will be present again on the latest builds.

Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.