1854914 - Browser window stops responding after resizing the window

Status: RESOLVED INCOMPLETE

(Core :: Widget, defect)

Description

[peter]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Resized the browser window for https://duckduckgo.com/?iaxm=maps&q=hoyerswerda (uses mapkit.js) but also occurs for https://graphhopper.com/maps/ which is open source and uses openlayers.

I'm using firefox 117.0.1 on Linux, but was able to reproduce a crash on the mobile firefox too (window size changes are more likely and more frequent there due to the software keyboard). A colleague was able to crash firefox on MacOS too: https://github.com/graphhopper/graphhopper-maps/issues/353

Actual results:

The tab crashed. See here the video: https://github.com/graphhopper/graphhopper-maps/issues/353#issuecomment-1733156821

Expected results:

No crash when changing the width or the height.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Hani Yacoub, Desktop QA]

I couldn't manage to reproduce the issue on Ubuntu 20.04 x64 on Firefox 117.0.1.
Could you please try if the issue occurs in safe mode. Here is a link that can help you do that: 
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 3

[peter]

Thanks a lot for the fast response!

I can not reproduce this issue on Desktop Firefox in safe mode (or at least I tried several minutes without success). But in normal mode I can also reproduce it without any add-ons activated. What could be the difference?

Also on Android I can reproduce it in Firefox using the landscape mode for GraphHopper Maps and typing an address (triggers the keyboard which resizes the window) and at some point the tab freezes (try hiding and showing the keyboard multiple times). Also here I had no add-ons enabled.

Comment 4

[peter]

On Android I can provoke a freeze easier with GraphHopper Maps: just zoom in and out a few times (I just tried a few times and after ~30seconds it happened).

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hi peter,

Thanks for filing this! I have some questions here:

1. From your video, it looks like the site stops responding to the window resizing. Does the site become entirely unresponsive? The first comment in the GitHub ticket from a different reporter suggests that the entire window stops being responsive. Is that what you're observing?
2. If the entire browser becomes unresponsive, can you kill it using SIGABRT, like this:

sudo kill -SIGABRT <Firefox process id>  

If all goes well, that should result in the crash reporter dialog appearing. If you submit that crash report, then the next time you open Firefox, if you visit about:crashes, it should be the top entry in the "Submitted Crash Reports" list. If that's the case, can you please provide the link to that crash report?

Comment 7

[peter]

Is that what you're observing?

Yes

If the entire browser becomes unresponsive, can you kill it using SIGABRT, like this:

I was able to create the crash report: https://crash-stats.mozilla.org/report/index/100d9a3a-7bcc-4a9e-8994-694060231017

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Thanks, peter!

Hey gsvelto, if you have a moment, do you see anything in this crash report that might explain why the browser is completely unresponsive? It looks to me like it's still polling the OS for events... maybe I'm not seeing something?

Comment 9

[Gabriele Svelto [:gsvelto]]

Unfortunately there's not much to work on in the crash. All the threads are waiting for events, including the main thread which is in the main event loop. This suggests that the browser was simply not receiving input events at that point.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

It sounds to me then that the OS got into a state where it stopped sending Firefox user input events. Perhaps we're in some kind of modal drag drop state? Unclear.

It's also not clear where the failure is occurring... but considering that the OS isn't giving us events, I'm going to suspect the border between the OS and the application, and choose Core :: Widget. Perhaps a Widget log would be useful.

If you go to about:logging and set the New log modules: to be Widget:5, hit "Set Log Modules" and then choose "Log to a file" and choose a place on the file system to log to... and then hit "Set Log File", and finally "Start Logging" - then, if you reproduce the issue, a copy of that log file would be very interesting to see attached to this bug. It might help us determine what strange state Firefox / the OS got into.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.