1763035 - crash when opening the "about page Info" window

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Asif Youssuff]

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

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

[:Gijs (he/him)]

Can we get a crash report? That would be useful in narrowing down what is broken...

Comment 3

[Asif Youssuff]

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

[:Gijs (he/him)]

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

[Stephen A Pohl [:spohl] (OOO until 6/12)]

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).

Comment 6

[Asif Youssuff]

(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

[Gabriele Svelto [:gsvelto]]

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.

Comment 8

[gon10]

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

[:Gijs (he/him)]

(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-441490220530

Maybe 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.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Thanks, I can repro. Bisect on Linux points to bug 1147847, which explains why this was probably only reproducible on macOS until relatively recently.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1763035 - Don't inherit direction in cached scrollbar parts. r=dholbert,boris

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.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

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

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12684e6e17ed
Don't inherit direction in cached scrollbar parts. r=jfkthame

Comment 14

[Asif Youssuff]

My guess is that this never reproduced for me because I have overlay scrollbars disabled in both macOS and Linux.

Comment 15

[Sandor Molnar]

https://hg.mozilla.org/mozilla-central/rev/12684e6e17ed

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Should we dupe bug 1715017 to this?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Yes

Comment 20

[Pascal Chevrel:pascalc]

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

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/4feebd97258c

Comment 22

[Peter Magyari (Desktop QA)]

I have reproduced the issue on Firefox 101 and verified the fix on Firefox Nightly 103.0a1 (20220601213138) and Firefox Beta 102.0b3 (20220601100855)

Comment 23

[Ryan VanderMeulen [:RyanVM]]

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

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/b08940212e43

Comment 25

[Ciprian Georgiu, Desktop QA]

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.