Closed Bug 1763035 Opened 2 years ago Closed 2 years ago

crash when opening the "about page Info" window

Categories

(Core :: Layout, defect, P3)

Firefox 95
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
103 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox101 --- verified
firefox102 --- verified
firefox103 --- verified

People

(Reporter: yoasif, Assigned: emilio)

References

()

Details

(Keywords: crash, rtl)

Crash Data

Attachments

(2 files)

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

Attached file about:support

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

Flags: needinfo?(yoasif)

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.

Component: Untriaged → Widget: Cocoa
Flags: needinfo?(gsvelto)
Product: Firefox → Core

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

Severity: -- → S3
Priority: -- → P3

(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

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.

Flags: needinfo?(gsvelto)

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?

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

Component: Widget: Cocoa → Layout
Flags: needinfo?(emilio)
Keywords: rtl
OS: macOS → All

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: nobody → emilio
Blocks: 1771796

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.

Flags: needinfo?(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
Attachment #9278816 - Flags: approval-mozilla-release?
Attachment #9278816 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/12684e6e17ed
Don't inherit direction in cached scrollbar parts. r=jfkthame

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

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch
Crash Signature: [@ _chkstk | nsSprocketLayout::GetXULPrefSize ]

Should we dupe bug 1715017 to this?

Flags: needinfo?(emilio)

Yes

Flags: needinfo?(emilio)

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.

Attachment #9278816 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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 on attachment 9278816 [details]
Bug 1763035 - Don't inherit direction in cached scrollbar parts. r=dholbert,boris

Approved for 101.0.1.

Attachment #9278816 - Flags: approval-mozilla-release? → approval-mozilla-release+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.