Closed Bug 1534287 Opened 2 years ago Closed 11 months ago

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

Categories

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

Unspecified
Android
defect

Tracking

()

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: 2 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: 2 years ago11 months 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.

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