This bug was filed from the Socorro interface and is report bp-b36b04b6-d385-4201-98d5-a49ac0180703. ============================================================= Seen while looking at release crash data: https://bit.ly/2Kuq86f. Crashes appear to have started in 61b15 and carried into release. #25 top crash so far and it is flagged as a startup crash. Devices are all running 19 (REL). Top 10 frames of crashing thread: 0 libxul.so libxul.so@0x11d3b6a 1 libxul.so libxul.so@0x11d300f 2 dalvik-mark-stack (deleted) dalvik-mark-stack @0xbbb01b 3 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x37c46e 4 libdvm.so libdvm.so@0x1eb8e 5 data@email@example.com@classes.dex data@firstname.lastname@example.org@classes.dex@0x5ca869 6 dalvik-heap (deleted) dalvik-heap @0x2c116 7 libdvm.so libdvm.so@0x4f255 8 data@email@example.com@classes.dex data@firstname.lastname@example.org@classes.dex@0x5ca866 9 libxul.so libxul.so@0x11d2ff3 =============================================================
Hi Eitan, do you have any idea how we'd be seeing this crash on release Fennec 61?
Chris, n-i to you as we discussed. We're wondering if this might be GeckoView related.
Assignee: nobody → eitan
Looks like lower version android devices will hit this. I'll post a fix today.
Created attachment 8989614 [details] [diff] [review] Use a new accessible node for each a11y focus event. r?jchen This allows us to avoid using removeAction which needs a higher API version. We already do this in 62 and 63. https://treeherder.mozilla.org/#/jobs?repo=try&revision=2cc847437f439a2ff22c841e2de2d1efbb89855b
Attachment #8989614 - Flags: review?(nchen)
Tested, it looks good.
Attachment #8989614 - Flags: review?(nchen) → review+
Comment on attachment 8989614 [details] [diff] [review] Use a new accessible node for each a11y focus event. r?jchen Approval Request Comment [Feature/Bug causing the regression]: [User impact if declined]: Users with Android KitKat (4.4) or earlier will be crashing if using accessibility. [Is this code covered by automated tests?]: In newer branches, yes. [Has the fix been verified in Nightly?]: No. I tested it on a try build. [Needs manual test from QE? If yes, steps to reproduce]: [List of other uplifts needed for the feature/fix]: [Is the change risky?]: As much as uplifting anything to release is. [Why is the change risky/not risky?]: [String changes made/needed]: None
Attachment #8989614 - Flags: approval-mozilla-release?
Ritu, Eitan requested mozilla-release uplift for this fix for a Fennec 61 bug, but no release manager has reviewed his uplift request for 21 days. This bug does NOT affect Fennec 62 Beta or 63 Nightly. Eitan, is this fix still worth uplifting to Fennec 61 Stable release if we need to spin a new dot release just for this fix?
What I tend to do and what I think Ryan is doing here is letting this sit in the approval:? queue as a potential ridealong in case we end up with a 61 fennec dot release. Right now this doesn't look to me like a strong release driver on its own. So it isn't ignored, just in a holding pattern for the moment.
(In reply to Chris Peterson [:cpeterson] from comment #7) > Ritu, Eitan requested mozilla-release uplift for this fix for a Fennec 61 > bug, but no release manager has reviewed his uplift request for 21 days. > This bug does NOT affect Fennec 62 Beta or 63 Nightly. > > Eitan, is this fix still worth uplifting to Fennec 61 Stable release if we > need to spin a new dot release just for this fix? Hi Chris, we don't have a strong dot release driver at the moment and this doesn't seem like a dot release driver by itself (as Liz also said). We have a list of 61 dot release drivers and ride-alongs in a spreadsheet (will share on slack with you). I can add this one to that list so it's reviewed when and if the time comes to ship 61.0.2. The likelihood of that seems low since .1 has been out for ~2 weeks now and things seem stable. Bugs that are nom'd for uplift to m-r are generally kept in the queue as is (not denied) as we cannot predict at any point with 100% accuracy whether a dot release will be needed or not for the remainder of the release cycle. We (relman team) might consider adding a comment like this "....will be reviewed when the next dot release is planned, nothing on the horizon so far". So far that has been implicit by way of leaving it in the queue. Hope that helps!
Thanks. I see now that the 61 release tracking spreadsheet says this bug fix is "Low-risk, worth taking as a Fennec ride-along."
I would defer to the release team on how urgent this crasher is. Seems like it's not.
moving to Firefox for Android's General component because this is not a GeckoView-specific issue.
Component: GeckoView → General
Comment on attachment 8989614 [details] [diff] [review] Use a new accessible node for each a11y focus event. r?jchen Simple Fennec crash fix already on Nightly and Beta. Approved for 61.0.2.
Attachment #8989614 - Flags: approval-mozilla-release? → approval-mozilla-release+
status-firefox61: fix-optional → fixed
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.