Crash in [@ java.lang.NullPointerException: at org.mozilla.focus.fragment.BrowserFragment.onAccessibilityStateChanged(BrowserFragment.kt:40)]
Categories
(Focus :: General, defect, P2)
Tracking
(firefox110 wontfix, firefox111 fixed, firefox112 fixed)
People
(Reporter: cpeterson, Assigned: mcarare)
References
Details
(Keywords: crash, Whiteboard: [fxdroid] [experience])
Crash Data
Attachments
(2 files)
|
59 bytes,
text/x-github-pull-request
|
Details | Review | |
|
59 bytes,
text/x-github-pull-request
|
dmeehan
:
approval-mozilla-release+
|
Details | Review |
Crash report: https://crash-stats.mozilla.org/report/index/5b746ee5-b059-41f2-9066-e04700230227
I suspect this crash was a regression in Focus 107. The earliest crash reports are from Focus 107.1.0.
Java stack trace:
java.lang.NullPointerException
at org.mozilla.focus.fragment.BrowserFragment.onAccessibilityStateChanged(BrowserFragment.kt:40)
at android.view.accessibility.AccessibilityManager.lambda$-android_view_accessibility_AccessibilityManager_36305(AccessibilityManager.java:1007)
at android.view.accessibility.-$Lambda$T3m_l9_RA18vCOcakSWp1lZCy5g$1.$m$0(Unknown Source:6)
at android.view.accessibility.-$Lambda$T3m_l9_RA18vCOcakSWp1lZCy5g$1.run(Unknown Source:0)
at android.os.Handler.handleCallback(Handler.java:808)
at android.os.Handler.dispatchMessage(Handler.java:101)
at android.os.Looper.loop(Looper.java:166)
at android.app.ActivityThread.main(ActivityThread.java:7396)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:245)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:926)
Updated•3 years ago
|
| Assignee | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
| Reporter | ||
Comment 2•3 years ago
|
||
If the fix is safe, we should consider uplifting this Focus crash fix to Beta and maybe even a dot release.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Updated•3 years ago
|
| Reporter | ||
Comment 3•3 years ago
|
||
No need to uplift to 110, but we should consider for a 111 dot release.
| Reporter | ||
Comment 4•3 years ago
|
||
Petru, do you think this Focus crash fix would be a good uplift for a 111.0.1 dot release next week? Or should it wait for another week of testing in Beta 112?
Comment 5•3 years ago
•
|
||
Yes, this is a straightforward patch that comes to bring on Focus the same null check we were already doing in Fenix.
Haven't look much into the issue but would agree that it's a recent one, from when Focus got the dynamic toolbar.
Mihai to confirm and work out the backport patch.
| Assignee | ||
Comment 6•3 years ago
|
||
I can confirm the change is minor, the only change consists in using a nullable variable instead of a non-null one, in order to be able to null check, instead of throwing an NPE.
Comment 7•3 years ago
|
||
| Assignee | ||
Comment 8•3 years ago
|
||
Comment on attachment 9323031 [details] [review]
[mozilla-mobile/firefox-android] Bug 1819012 - Change browser toolbar behavior only if view is created. (backport #1006) (#1238)
Beta/Release Uplift Approval Request
- User impact if declined: In some cases, the app can crash if the change in the a11y services state occurs before the browser fragment view is created.
- Is this code covered by automated tests?: Unknown
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce: Reproducing this requires specific timing that is not easily controlled: activating the a11y services at the exact moment that the view is not created, but navigation to the browser fragment has already occurred.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The only relevant change is code is replacing a non-null variable with a nullable variable and a null check.
- String changes made/needed: None.
- Is Android affected?: Yes
Comment 9•3 years ago
|
||
Comment 10•3 years ago
|
||
Description
•