crash when opening the "about page Info" window
Categories
(Core :: Layout, defect, P3)
Tracking
()
People
(Reporter: yoasif, Assigned: emilio)
References
()
Details
(Keywords: crash, rtl)
Crash Data
Attachments
(2 files)
25.20 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
|
Details | Review |
From https://www.reddit.com/r/firefox/comments/tvnxsm/firefox_crash_when_opening_the_about_page_info/
When I try to open the Page Info window then FireFox crashes immediately.
Issue began on Firefox 95.
This does not reproduce in a fresh profile.
I can't reproduce this on Catalina, but the user can reproduce the issue on Big Sur and Monterey.
User is using a Hebrew language version of Firefox, but is using English for their macOS account settings.
Regression range seems to be:
10:56.76 INFO: Got as far as we can go bisecting nightlies... 10:56.76 INFO: Last good revision: 32a3cf57dd4396e123ebbba2f894e540528d0781 (2021-10-11) 10:56.76 INFO: First bad revision: 691a703f1fa2ba4cccfccc60feae36ff5b20f04c (2021-10-12) 10:56.76 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=32a3cf57dd4396e123ebbba2f894e540528d0781&tochange=691a703f1fa2ba4cccfccc60feae36ff5b20f04c
Reporter | ||
Comment 1•1 year ago
|
||
Comment 2•1 year ago
|
||
Can we get a crash report? That would be useful in narrowing down what is broken...
Reporter | ||
Comment 3•1 year ago
|
||
The user previously provided these crash reports:
bp-40e944be-f48f-4868-a9c1-747c00220404
bp-5e962e3c-f3ac-4496-902f-0c8e90220404
bp-16d58de1-5977-4345-bec5-6e1710220404
bp-d74e0946-6fb2-472e-ac9d-02f430220404
bp-e1ec12de-2884-4965-a459-6e49d0220404
bp-aeed243b-cf4a-43ef-b805-3aef50220404
bp-808fe999-d44f-47ec-8e7c-8e36d0220404
bp-2cdccb2f-ac3c-4ca8-a67d-2ee1e0220404
bp-a5587753-b2a2-4cfb-bc32-a71b60220404
bp-3db57c68-3aaf-4291-aee2-60b4c0220404
bp-02534cd3-8d00-44ef-ade7-b55f90220403
bp-0cfa2f33-d1fa-4c27-9b56-610640220403
bp-088d9112-1381-46a0-bf50-58f3a0211217
No idea how useful they are. Please needinfo me again if you would like me to reach out for additional reports.
Comment 4•1 year ago
|
||
All but 2 of these have "EMPTY: no crashing thread identified". Gabriele, is there some way we can get more data there?
The 2 other ones are https://crash-stats.mozilla.org/report/index/e1ec12de-2884-4965-a459-6e49d0220404 and https://crash-stats.mozilla.org/report/index/40e944be-f48f-4868-a9c1-747c00220404 and both point at sort of different things...
I'm going to tentatively move to Cocoa land for further investigation, I guess.
Comment 5•1 year ago
|
||
It'd be interesting to hear if this still reproduces if the page info dialog is resized (assuming there is enough time to do so before the crash).
Reporter | ||
Comment 6•1 year ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #5)
It'd be interesting to hear if this still reproduces if the page info dialog is resized (assuming there is enough time to do so before the crash).
The reporter says:
No, The second that I try to open the page info it’s crash
Comment 7•1 year ago
|
||
Can't get much out of those crashes. They're very large (8 MiB each) but completely empty. Apart from a few bytes in the header the rest is entirely made of zeros. It would be useful if the user could send us a crash report obtained via the operating system crash reporter.
I am a Hebrew Firefox user myself, and I noticed that this issue still persists.
It's very easy to reproduce this crash, just change the Firefox interface language to Hebrew and try to open "about page Info" or the "downloads window (Ctrl + J on Windows)", and Firefox should crash immediately.
I checked this with a fresh install of Firefox on Windows 11 and also on Fedora Linux.
Here is the crash report: https://crash-stats.mozilla.org/report/index/a19df2c5-3b72-4a70-b536-441490220530
Maybe that is a problem with RTL languages?
Comment 9•1 year ago
|
||
(In reply to gon10 from comment #8)
I am a Hebrew Firefox user myself, and I noticed that this issue still persists.
It's very easy to reproduce this crash, just change the Firefox interface language to Hebrew and try to open "about page Info" or the "downloads window (Ctrl + J on Windows)", and Firefox should crash immediately.I checked this with a fresh install of Firefox on Windows 11 and also on Fedora Linux.
Here is the crash report: https://crash-stats.mozilla.org/report/index/a19df2c5-3b72-4a70-b536-441490220530Maybe that is a problem with RTL languages?
That stack looks like a weird infinite recursion in presshell code. Actually, come to look at it again, that matches 1 of the 2 non-empty crashes I linked in comment #4, so I guess let's move this to layout. Maybe Emilio can help.
Assignee | ||
Comment 10•1 year ago
|
||
Thanks, I can repro. Bisect on Linux points to bug 1147847, which explains why this was probably only reproducible on macOS until relatively recently.
Assignee | ||
Comment 11•1 year ago
|
||
This is the most minimal fix for the bug. The issue is basically that
XUL <tree>s have a non-anonymous scrollbar that doesn't match the rule
above the one I'm modifying (which resets scrollbar directionality to
ltr).
Its anonymous kids would inherit this rtl directionality and cache it,
and the wrong directionality would be used for actual anonymous
scrollbars, causing havoc later on due to the nsGfxScrollFrame reflow
callbacks.
This is wrong, anyways, there's no reason for inheriting the
directionality of the scrollbar to begin with.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 12•1 year ago
|
||
Comment on attachment 9278816 [details]
Bug 1763035 - Don't inherit direction in cached scrollbar parts. r=dholbert,boris
Beta/Release Uplift Approval Request
- User impact if declined: RTL builds crash on platforms with overlay scrollbars.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0. Also reproduces with l10n.pseudo=bidi, ftr
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
- String changes made/needed: none
- Is Android affected?: No
Assignee | ||
Updated•1 year ago
|
Comment 13•1 year ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/12684e6e17ed Don't inherit direction in cached scrollbar parts. r=jfkthame
Reporter | ||
Comment 14•1 year ago
|
||
My guess is that this never reproduced for me because I have overlay scrollbars disabled in both macOS and Linux.
Comment 15•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Updated•1 year ago
|
Comment 20•1 year ago
|
||
Comment on attachment 9278816 [details]
Bug 1763035 - Don't inherit direction in cached scrollbar parts. r=dholbert,boris
Easy to hit crash for rtl users, approved for 102 beta 3, thanks.
Comment 21•1 year ago
|
||
bugherder uplift |
Updated•1 year ago
|
Comment 22•1 year ago
|
||
I have reproduced the issue on Firefox 101 and verified the fix on Firefox Nightly 103.0a1 (20220601213138) and Firefox Beta 102.0b3 (20220601100855)
Updated•1 year ago
|
Comment 23•1 year ago
|
||
Comment on attachment 9278816 [details]
Bug 1763035 - Don't inherit direction in cached scrollbar parts. r=dholbert,boris
Approved for 101.0.1.
Comment 24•1 year ago
|
||
bugherder uplift |
Comment 25•1 year ago
|
||
Reproduced the bug on Win 11 and macOS 11, using Firefox 101.0.
The issue is also verified as fixed on 101.0.1 across platforms: Win 11 x64, macOS 11 and Ubuntu 18.04 x64.
Description
•