Closed Bug 1812405 Opened 2 years ago Closed 1 year ago

[Wayland] Firefox becomes unresponsive after opening downloads menu

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 109
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1875369

People

(Reporter: evanmohr22, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

about-support
117.75 KB, application/octet-stream
Details
log.txt
2.27 MB, text/plain
Details

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

Steps to reproduce:

  1. Observe general responsiveness of browser by opening tabs, closing them, typing in URL bar, etc.
  2. Begin downloading a file
  3. Open the downloads menu (the little circle that fills up as the download goes)
  4. Observe the unresponsiveness of the browser by trying to open tabs, close them, etc.

System details: Occurs on Fedora 37 with Flathub Firefox packaging and on Ubuntu 22.10 with Snap packaging. MOZ_ENABLE_WAYLAND=1 set as environmental variable. I believe this issue first started on Firefox 108.

Actual results:

The browser becomes unresponsive, not responding when trying to open tabs, close tabs, type in text fields.

Video demonstration: https://youtu.be/FnSQ5C7A058. In the beginning of the video, I demonstrate that Firefox is responsive, I am able to open and close tabs, type, etc. But once I open the downloads menu, I can no longer create new tabs or close them. As I try to switch tabs, it is unresponsive. Eventually, it responds to my actions, but then becomes unresponsive again. I can't type in the URL bar, but I can type in the Google bar. Shortly after, I can't even type in the Google search bar, I can only highlight and click the "x" to clear my input. Once I hit the downloads menu button again, everything registers at once. The tabs I tried to open before all open at once, some of the text I entered in the URL bar show up,

Expected results:

Firefox remains responsive

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Can you try plain Mozilla binary?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(evanmohr22)

I wasn't able to reproduce the bug on the plain Mozilla binary nor the Arch Linux firefox package. Maybe the issue is somehow related to the sandboxing technologies used by snap and flatpak?

Flags: needinfo?(evanmohr22)

Update: The issue is not related to sandboxing, I just the issue occur on the Arch package too.

Please try to reproduce on plain Mozilla binary. Do you use Arch or Fedora?
Also please attach about:support from affected browser. I wonder if that's X11 or Wayland session, snadboxed or not (flatpak/snap).
Thanks.

Flags: needinfo?(evanmohr22)

The issue still occurs in Firefox 116. I was able to reliably reproduce it on the plain Mozilla binary on Fedora Silverblue 38, but it also occurs on snap package in Ubuntu 23.04 and flatpak package on every distro I've tested it on. More importantly, I've only run into reproduce the issue while using the native Wayland window (MOZ_ENABLE_WAYLAND=1).

The most reliable setup I've found is:

  1. Open Firefox, sign into GitHub (needed to download the following file), and bookmark this link (for convenience): https://github.com/canonical/ubuntu-core-desktop/actions/runs/5868602310
  2. Close out of Firefox
  3. Open Firefox
  4. Open a new tab (so that you have 2 tabs open; I couldn't reproduce the issue with just one tab open)
  5. Click on the bookmark link
  6. Download the file by clicking on "image" under the "Artifacts" section.
  7. Click on other tab or other parts of Firefox UI; notice how everything is unresponsive

One oddity I've mentioned is that activating the Gnome Activities view will cause Firefox to update the UI. So it could possibly be a Gnome Bug? I will test later.

Another video recreation: https://www.youtube.com/watch?v=_e5kno7uI_g

Some things to note: between 0:08 and 0:11 I'm trying to switch tabs, but nothing happens. Between 0:11 and 0:13, I'm trying to open the hamburger menu but nothing happens. At 0:14 there is a delayed opening of the extensions screen and hamburger menu, but text is missing from the hamburger menu. Pocket menu is empty at 0:15, but I don't use it so I don't know if that's a common bug or not. And after 0:15, Firefox is behaving correctly.

Flags: needinfo?(evanmohr22)

Update: not a Gnome specific bug. I was able to replicate the issue on Sway.

Can you try XWayland? (i.e. run firefox with MOZ_ENABLE_WAYLAND=0)

Flags: needinfo?(evanmohr22)
Priority: -- → P2
Summary: Firefox becomes unresponsive after opening downloads menu → Firefox becomes unresponsive after opening downloads menu [compositor pause]

XWayland does not have the issue.

Flags: needinfo?(evanmohr22)

Yes, it's because we don't pause compositor on X11.

Flags: needinfo?(stransky)

Still affects Firefox 121.

Will try to reproduce. The reproducer at https://github.com/canonical/ubuntu-core-desktop/actions/runs/5868602310 looks outdated/deleted, is it still relevant? I guess you can reproduce it because the download is still running and the popup is updating, right?

Does the reproduction works with any large file, for instance iso from https://fedoraproject.org/workstation/download ?

Okay, found another image at github but I still can't reproduce it :(

The Fedora download doesn't cause it, but downloading the Ubuntu Core Desktop image does trigger the issue.

As far as I can tell, the main difference between downloading the Fedora image and Ubuntu Core image is that the Ubuntu Core image starts off by saying something like "unknown time remaining" for the downloading while the Fedora image immediately shows the time remaining. If that is what is causing the issue, then maybe internet speed is a factor since I have relatively slow internet (2MB/s download).

(In reply to evanmohr22 from comment #15)

The Fedora download doesn't cause it, but downloading the Ubuntu Core Desktop image does trigger the issue.

As far as I can tell, the main difference between downloading the Fedora image and Ubuntu Core image is that the Ubuntu Core image starts off by saying something like "unknown time remaining" for the downloading while the Fedora image immediately shows the time remaining. If that is what is causing the issue, then maybe internet speed is a factor since I have relatively slow internet (2MB/s download).

Coll, thanks. Will try with ubuntu image.

Could you post a link which you use for Ubuntu image download? The one I used calculates download time so I can't reproduce the issue.
Thanks.

Flags: needinfo?(stransky) → needinfo?(evanmohr22)
Flags: needinfo?(stransky)

Please try to use Firefox profiler (https://profiler.firefox.com/), run profiling and reproduce the freeze and upload the profile here. It may reveal where Firefox is frozen.
Thanks.

I can confirm this happens for me with downloads of unknown size such as compressed source files on github, not files of known size. I ran the profiler and it being all new to me, it was a bit confusing and it took a while to complete a run without Firefox freezing while doing the offending task. I could only do it after just downloading one compressed source file from github and not touch anything on Firefox's interface.

Here's the url to my profiler run: https://share.firefox.dev/3O7VAGb. That's with a new profile and on nightly. At first I thought you/it meant to upload my firefox profile that has the crash logs in it, which I did, and it was asking for something else. Sorry, this is all new to me.

Just to add, an example download file that I've been using is: https://codeload.github.com/mozilla/DeepSpeech/tar.gz/refs/tags/v0.9.3. But my experience, any compressed source files of unknown size make Firefox freeze. This also doesn't happen with MOZ_ENABLE_WAYLAND=0 environment variable set.

Thanks for the profile. Looks like we're waiting for system events there. If you open the download and Firefox is frozen, what happens when download is finished? Is everything back to normal? Or do you need to do any unusual steps to wake up the browser?

Also please try to crash browser when it's frozen (use latest nightly please):
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Getting_Mozilla_crash_report_from_running_or_frozen_Firefox
And attach crash ID here. That gives general overview of all processes/threads there.

Thanks.

Flags: needinfo?(mida)
Duplicate of this bug: 1874527
Flags: needinfo?(stransky)
Summary: Firefox becomes unresponsive after opening downloads menu [compositor pause] → [Wayland] Firefox becomes unresponsive after opening downloads menu
Flags: needinfo?(stransky)

I couldn't make it crash but I force killed it via terminal and submitted the data when Firefox asked. The content part of Firefox becomes completely blank when it happens and the interface doesn't want to respond. When it does I can't switch tabs. I'm working on adding more troubleshooting information here if I can figure things out. I'm new to Linux, new to bug teting. Here's a link to what I copied in the report I submitted: https://pastebin.com/ak6s4et1

Flags: needinfo?(mida)

I'm not sure this is what you need but here's my journalctl output from time of starting firefox to crashing: https://pastebin.com/DjWaisRQ

Cool!

  1. Please attach crash ID from about:crashes page (also please submit them).
  2. Do Firefox resume to normal operation when download is finished or not?

Thanks.

Flags: needinfo?(mida)

  1. Crash ID: 0b4d948a-08ca-5a8d-6ed2-fd2fef79235d

  2. If it was a fast single download, yes, it'd often resume. If not, it would stall for up to a minute and I wouldn't have the patience to wait so I'd kill it

Flags: needinfo?(mida)

Please run on terminal with MOZ_LOG="WidgetVsync:5 nsRefreshDriver:5 WidgetPopup:5" env variables, reproduce the freeze, terminate firefox and attach the log here.

For instance run as:

MOZ_LOG="WidgetVsync:5 nsRefreshDriver:5 WidgetPopup:5" firefox > log.txt 2>&1

and attach the log.txt here.

Thanks.

Flags: needinfo?(mida)

Also please attach your about:support page.
Thanks.

Attached file about-support —
Flags: needinfo?(mida)
Attached file log.txt —

Output of following from time of process start to force kill: MOZ_LOG="WidgetVsync:5 nsRefreshDriver:5 WidgetPopup:5" firefox > log.txt 2>&1

I managed to wait it out for five minutes and Firefox fully recovered. Of course while downloading the offending file I still had unresponsive tabs and content but the main menu was still responsive.

So from the logs it seemed like this was a vsync issue so in about:config I set widget.wayland.vsync.enabled=false and downloaded multiple offending files and thankfully the Firefox interface remained responsive. Thank you guys for your work.

I can also confirm that setting widget.wayland.vsync.enabled=false fixed the issue.

Flags: needinfo?(evanmohr22)

Although setting that to false also seems to bring down the frame rate to 60fps, but manually setting layout.frame_rate to my monitor's refresh rate (170) fixes that issue.

I set layout.frame_rate to my monitor's 144hz, restarted and it showed 60hz according to www.vsynctester.com. But I digress, no relation to the issue in question.

I'm not sure it's relevant or if it showed in the logs but I use KDE and have "Reduce latency by allowing screen tearing artifacts in fullscreen windows" aka vsync disabled on my system.

Ok, after testing, changing KDE's vsync option doesn't make a difference.

Flags: needinfo?(fnkimnki)

I did not run into the issue on the new build, so it seems to be fixed.

Flags: needinfo?(evanmohr22)

I can confirm also. With the default vsync config I had no trouble with the offending downloads.

Flags: needinfo?(fnkimnki)
Flags: needinfo?(evanmohr22)

New build also doesn't have the issue

Flags: needinfo?(evanmohr22)

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

Great, Thanks. Can you please try this new build?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f9JnpTGVTlCS5M0t7Sg55Q/runs/0/artifacts/public/build/target.tar.bz2

Can confirm. That build works as well with either vsync settings.

Flags: needinfo?(fnkimnki)

New build is also good, no issues.

In my short testing it's worked fine. I normally run stable but I'm gonna run this version full time to better test. If no reply here then all's good.

Flags: needinfo?(fnkimnki)

Can you please check latest nightly if you still see it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(stransky) → needinfo?(evanmohr22)

Latest nightly is good, I couldn't reproduce the issue.

Flags: needinfo?(evanmohr22)
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1875369
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: