1998188 - Crash in [@ mozilla::EventTargetChainItem::HandleEventTargetChain]

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Dianna Smith [:diannaS]]

Crash report: https://crash-stats.mozilla.org/report/index/85a0b761-5b54-45e6-8b11-dafd30251104

Reason:

SIGSEGV / SEGV_MAPERR

Top 1 frame:

0  libxul.so  mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::Event...  dom/events/EventDispatcher.cpp:493

Crash report: https://crash-stats.mozilla.org/report/index/fa118784-e5e7-4976-8716-8c77e0251112

Reason:

SIGSEGV / SEGV_MAPERR

Top 2 frames:

0  libxul.so  nsCOMPtr<mozilla::dom::EventTarget>::nsCOMPtr(nsCOMPtr<mozilla::dom::EventTar...  xpcom/base/nsCOMPtr.h:385
0  libxul.so  mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::Event...  dom/events/EventDispatcher.cpp:495

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

This isn't actionable without some stack.

Comment 2

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 5 desktop browser crashes on Linux on beta

:edgar, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

gsvelto, the crash reports are very broken. Do you have any ideas about this?

Comment 4

[Henri Sivonen (:hsivonen)]

(In reply to Dianna Smith [:diannaS] from comment #0)

Crash report: https://crash-stats.mozilla.org/report/index/fa118784-e5e7-4976-8716-8c77e0251112

Bit flip confidence is 25 for this one. (Had trouble finding the other one in the relevant view.)

Comment 5

[Gabriele Svelto [:gsvelto]]

It must be some kind of stack-walking issue. We get the first frame on the stack, but then the stack walker immediately stumbles upon the end of the stack. I'm leaving the NI? because I have to investigate why that could be happening.

Comment 6

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

(Bumped to S2 due to the topcrash)

Comment 7

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

I looked over the recent reports and found that some of them have more frames on the stack.

• https://crash-stats.mozilla.org/report/index/eeb2fefa-400e-45ca-a80b-c47140251118
• https://crash-stats.mozilla.org/report/index/d9811c45-243c-49d8-b7db-c39940251118
• https://crash-stats.mozilla.org/report/index/f714c0cb-8498-4d74-86e3-7763b0251118
• https://crash-stats.mozilla.org/report/index/68bfa7b0-5012-4be2-b63f-12c020251118

All of them show a long recursive call in AppWindow::Center().

Comment 8

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

The crashes mostly happen on Linux. There was a recent change in the relevant code in bug 1992198 and it also seems to match the spike in crash reports. :stransky, could the spike be something related to the changes in bug 1992198? Thanks!

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Yes, looks like so. Where is the AppWindow::Center() used? Can it be tested somehow?

Comment 10

[Gabriele Svelto [:gsvelto]]

That looks like bug 1999259, same issue?

Comment 11

[Gabriele Svelto [:gsvelto]]

BTW this explains the broken stacks: the stackwalker is starting from a frame that is already outside of the stack mapping, so the walk stops straight away as it cannot find where the stack actually is.

Comment 12

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #9)

Yes, looks like so. Where is the AppWindow::Center() used? Can it be tested somehow?

AppWindow::Center() can be used while opening a top-level chrome window with centerscreen chrome flag, one case is "Create Profile Wizard", you can open it via clicking Create a New Profile in about:profiles.

But from the crash report in comment# 7, the uptime is pretty short (less than 10 sec) and I also see XPCOMSpinEventLoopStack has AppWindow::ShowModal. So it looks like the modal window is opened pretty soon after Firefox is launched, not sure what is it, can that be "Primary Password" dialog?

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Isn't there a new "choose profile" dialog at startup?

Comment 14

[Bala M [:BalaM314]]

This issue is triggered when attempting to open the developer tools in separate-window mode. (set devtools.toolbox.host to "window")

Opening the developer tools immediately and reliably causes a crash. Here's my crash report: https://crash-stats.mozilla.org/report/index/6b750483-7af4-4ae9-a439-1f62a0251121#tab-details

I got this after updating to 146.0b5.

Workaround: open about:config and set devtools.toolbox.host to bottom

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Cool, Thanks.

Comment 16

[Wayne Mery (:wsmwk)]

Thunderbird also has this crash signature. And like bug 1999259, approx 65% are startup crashes.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

(In reply to Bala M:BalaM314 from comment #14)

This issue is triggered when attempting to open the developer tools in separate-window mode. (set devtools.toolbox.host to "window")

Opening the developer tools immediately and reliably causes a crash. Here's my crash report: https://crash-stats.mozilla.org/report/index/6b750483-7af4-4ae9-a439-1f62a0251121#tab-details

I got this after updating to 146.0b5.

Workaround: open about:config and set devtools.toolbox.host to bottom

Tested and can't reproduce. Can you attach your about:support page? It may be seen on particular resolution/scale.
Thanks.

Comment 18

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criteria:

• Top 10 desktop browser crashes on nightly (startup)
• Top 5 desktop browser crashes on Linux on beta

For more information, please visit BugBot documentation.

Comment 19

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

Opening the developer tools immediately and reliably causes a crash. Here's my crash report: https://crash-stats.mozilla.org/report/index/6b750483-7af4-4ae9-a439-1f62a0251121#tab-details

FWIW, in the crash report, there is monitor information, not sure if this is what you are looking for, though..
"monitors":[{"screenWidth":1920,"screenHeight":1200,"defaultCSSScaleFactor":1.25,"contentsScaleFactor":1.25}]

Comment 20

[Bala M [:BalaM314]]

Attachment: Troubleshooting Information.xhtml

Attached about:support page

Comment 22

[max]

Attachment: xulstore.json

Comment 23

[max]

I had the issue, as also already described it happens when opening the dev tools. As a workaround I could resolve it, by removing the xulstore.json from my profile.
I added the xulstore.json as attachment.

I have the suspicion that the last time I opened the dev tools (when it worked) was on an external monitor. But cannot say that for sure. Here is my output configuration from my laptop:

❯ swaymsg -t get_outputs
Output eDP-1 'BOE 0x0C8E Unknown' (focused)
  Current mode: 2560x1600 @ 240.000 Hz
  Power: on
  Position: 0,0
  Scale factor: 1.250000

Comment 24

[max]

I further looked into it, I can reproduce it with "width": "675", in the xulstore.json of the chrome://devtools/content/framework/toolbox-window.xhtml entry.

When changing it to 1015 (which was the value, after I removed the file) I can open the dev tools without any issue.

Comment 25

[Valery Ledovskoy]

I think the crash in bug 2002717 is not a duplicate of this bug. Perhaps my problem is also related to a certain screen resolution combined with a certain scale. Therefore, I will add more details.

All the actions listed in this bug are normally worked out without crashes. Firefox crashes only when I trying to open the 'About Firefox' window.

I have Ubuntu 25.10 with current updates. The problem started reproducing from version 146, it wasn't reproducible before. It was reproduced today on the current beta of Firefox 146.0b9-1.
https://crash-stats.mozilla.org/report/index/bp-ab8c765a-c142-4ebe-bbcc-210b40251130

I have two screens on my laptop - own laptop screen and a 4K TV. The crashes only occur on the own laptop screen. It has the following parameters:
Resolution: 1920 x 1080 (16:9)
Scale: 125 %
Fractional scaling is enabled.

I should also add that in the current beta of Thunderbird 146.0b3-4, crashes on the same screen do not occur when the "About Thunderbird" window is opened.

I'm ready to provide additional information if necessary.

Comment 26

[Edgar Chen [:edgar] (OOO 08/03 ~ 08/07)]

(per comment #8, move to Widget: GTK for now)

Comment 27

[Martin Stránský [:stransky] (ni? me)]

I tried with various screen resolution but I don't see it. Tested 1920x1200@1.25 and 1920x1080@1.25. I wonder if also titlebar is a factor here. Which desktop do you run? I'm testing under Gnome / Fedora 42.

Comment 28

[max]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #27)

I tried with various screen resolution but I don't see it. Tested 1920x1200@1.25 and 1920x1080@1.25. I wonder if also titlebar is a factor here. Which desktop do you run? I'm testing under Gnome / Fedora 42.

I am using sway and running Firefox without a titlebar. For me at least I can reproduce the error, when I change only the width (and leave the height untouched).

Usually when I then open the debugger tools, it tries to resize it to half my screen size.
But to be honest I am not sure how the half of my screen is 1015.

I have the following gap settings:

    smart_gaps on
    gaps inner 3
    gaps outer 0

    smart_borders on
    default_border pixel 2

With these settings I would assume the width to be 1014 (= 2560/2/1.25 - 10).

Note when I for example set it to another value which works (for example 615), and then open the debugger, restart Firefox, the settings are again set to "half screen size", i.e. 1015.

Can I do further things to help you debug? I will later look, if I can provide you with a more detailed stacktrace or something similar (now I have some other meetings first).

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Can you please try to run on terminal with MOZ_LOG="Widget:5,WidgetPopup:5" env variable, make it crash and attach the output here?
Thanks.

Comment 31

[Martin Stránský [:stransky] (ni? me)]

From all the reports it looks related to 125% screen scale, environment Sway/KDE/Gnome, Wayland and various resolutions.

Comment 32

[max]

Attachment: moz-crash.log.gz

As the crash log became quite big, I gzipped it.

Note I had set the value in the xulstore.json to 675 and my screen was only half, as I had on the other half my terminal open.

Comment 33

[Martin Stránský [:stransky] (ni? me)]

Thanks. Looks like rounding error while positioning the popup:

[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::Move to [686 x 25] scale 1.250000 scaled [857.50 x 31.25]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]:   bounds 0 x 0
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::NativeMoveResize mLastMoveRequest [686,25] mClientMargin [0,0] move 1 resize 0 to [686,25] -> [675 x 1230]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::Move to [687 x 25] scale 1.250000 scaled [858.75 x 31.25]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]:   bounds 686 x 25
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::NativeMoveResize mLastMoveRequest [687,25] mClientMargin [0,0] move 1 resize 0 to [687,25] -> [675 x 1230]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::Move to [686 x 25] scale 1.250000 scaled [857.50 x 31.25]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]:   bounds 687 x 25
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::NativeMoveResize mLastMoveRequest [686,25] mClientMargin [0,0] move 1 resize 0 to [686,25] -> [675 x 1230]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]: nsWindow::Move to [687 x 25] scale 1.250000 scaled [858.75 x 31.25]
[Parent 37926: Main Thread]: D/Widget [7fc324d80600]:   bounds 686 x 25

so we're cycling over 687 x 25 / 686 x 25 values.

Comment 34

[Martin Stránský [:stransky] (ni? me)]

I think we need to update AppWindow::Center() to just skip if difference is +/- screen scale (1.25 is ceiled scale 2).

Comment 35

[Bala M [:BalaM314]]

I am using GNOME 49.1 on Arch Linux.

Comment 36

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1998188 Allow only one recursion of AppWindow::Center() r?emilio

Comment 37

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox146 (beta). However, the bug still has low priority.

:jstutte, could you please increase the priority for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cd8414274ddd
https://hg.mozilla.org/integration/autoland/rev/c2f5652f283f
Allow only one recursion of AppWindow::Center() r=emilio

Comment 39

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c2f5652f283f

Comment 41

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 42

[Dianna Smith [:diannaS]]

:stransky do you think this is low risk to uplift to the next planned dot release or should it ride the 147 train?

Comment 43

[Martin Stránský [:stransky] (ni? me)]

I think uplift is perfectly safe.

Comment 44

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 9530802 [details]
Bug 1998188 Allow only one recursion of AppWindow::Center() r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Crashes on window centering on some screen sizes.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We restrict maximal recursion for re-center.
• String changes made/needed:
• Is Android affected?: Yes

Comment 47

[Dianna Smith [:diannaS]]

:stransky this doesn't cherry-pick cleanly to release (missing changes that were done in bug 1999619). Does bug 1999619 need to be uplifted as well? If not, could you submit a rebased patch for release? thank you!

Comment 48

[Martin Stránský [:stransky] (ni? me)]

Yes, it should apply to release cleanly.

Comment 49

[Dianna Smith [:diannaS]]

Comment on attachment 9530802 [details]
Bug 1998188 Allow only one recursion of AppWindow::Center() r?emilio

Approved for 146.0.1 dot release

Comment 50

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/70d247a0101e
https://hg.mozilla.org/releases/mozilla-release/rev/6fe0ef2c7dfe

Comment 54

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.