+++ This bug was initially created as a clone of Bug #1781167 +++

I am creating a clone of the previous issue because it was seemingly closed without checking if the newest Firefox nightly actually fixed the issue like someone asked.

I have tested the newest Firefox nightly 109.0a1 (2022-11-23) (64-bit) and the issue still exists.

I have attached a video of the reproduction of the bug

This is very unfortunate news :(

Thank you for filing this bug! Bugs are automatically closed when a patch lands in them, but you should still be able to comment on them, and we will usually reopen bugs if the patch entirely fails to address the problem.

Markus,

Bug #1781167 says "You need permission to comment on this closed bug." So we are unable to report test results, etc., on that topic. I am testing the 20221123094429 Nightly as well, but mine has not yet frozen

Sorry to add to the unfortunate news. I got the below build running at ~3:15 p.m. At a little before 9p.m. I was re-watching a short video clip on Twitter. The video froze not long after it started and when I went to see if I could move my mouse, Firefox completely shut down. I attached the core dump I pulled from syslog. This is the first time I've had it dump on me. I'll try the prior build. Maybe there's been some other change between 107.0 and this one which is problematic for my system.

~/.local/bin/mozregression --launch 20221123094429
0:01.60 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2022/11/2022-11-23-09-44-29-mozilla-central/firefox-109.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
4:17.74 INFO: Running mozilla-central build for buildid 20221123094429
4:45.84 INFO: Launching /tmp/tmpcztoibm8/firefox/firefox
4:45.84 INFO: Application command: /tmp/tmpcztoibm8/firefox/firefox -profile /tmp/tmpn54gm9_s.mozrunner
4:45.85 INFO: application_buildid: 20221123094429
4:45.85 INFO: application_changeset: f150bc1f71d09e1e1941065951f0f5a38628f080
4:45.85 INFO: application_name: Firefox
4:45.85 INFO: application_repository: https://hg.mozilla.org/mozilla-central
4:45.85 INFO: application_version: 109.0a1

I noticed to freeze is very likely to happen when you triple click on a period to select the whole paragraph. Doesn't always happen, but i noticed that is onw of the main triggers when i do it inside the Gutenberg editor of a Wordpress website (and also happened in another personal website local hosted)

a little update, the triggere doesn't seems to be the triple clicking, but more like the selecting. Right now some case litterally makes the browser unusable. Is there a way to obtain some kind of log?

I checked the last release w/o fix - 20221122214324 and it did freeze on me (but no crashes).

I then re-ran first release w fix - 20221123094429 and hit 48 hours with no freezes (my success criteria when regression testing) approximately 9 hours ago. So it seems the freeze problem I was experiencing since FF102 is gone and the fix did work for my issue. My plan to continue running this build until the patch is uplifted or FF109 is released, whichever comes first.

With regards to the crash I had, I did start noticing ~FF106 that sometimes when I clicked to watch a video I would first see my desktop background in the square where the video would subsequently start playing. It was like a window through Firefox appeared and then it disappeared when the video started. I noticed that happened again while testing one of these two builds so it is possible whatever is causing that to happen factored into the crash. I would think the 'transparent window' is a different issue than Jessica's freeze issue and should I get any future crashes I will search for an existing bug or open a new one. I consider my freeze issue resolved.

Like Susan, I am running 20221123094429 and have been for nearly 5 days now, without issue. During my regression testing, all of the 'bad' builds would fail in a few hours - much less than one day. So I would agree that the fix for the freeze issue seems to have corrected the problem.

(In reply to Jessica from comment #0)

+++ This bug was initially created as a clone of Bug #1781167 +++

I am creating a clone of the previous issue because it was seemingly closed without checking if the newest Firefox nightly actually fixed the issue like someone asked.

Have you been seeing this issue since the end of June when Firefox 102 was released? Bug 1781167 started with a specific code change in Firefox 102 (which RandyS and I found through regression testing).

I'm asking because in Bug 1790206 comment 23 you indicated you were noticing the problem with Firefox 106.0.1. Around that time is when I noticed the "window issue" related to videos I described in comment 7 of this bug. You specifically mention having a video open in a tab makes it easy for you to reproduce the issue. A video-related issue precipitated the crash I had in comment 3 of this bug. I don't recall videos really relating at all to the original issue I had. Maybe there is a second problem which has not yet been identified.

(In reply to Susan from comment #9)

(In reply to Jessica from comment #0)

+++ This bug was initially created as a clone of Bug #1781167 +++

I am creating a clone of the previous issue because it was seemingly closed without checking if the newest Firefox nightly actually fixed the issue like someone asked.

Have you been seeing this issue since the end of June when Firefox 102 was released? Bug 1781167 started with a specific code change in Firefox 102 (which RandyS and I found through regression testing).

I'm asking because in Bug 1790206 comment 23 you indicated you were noticing the problem with Firefox 106.0.1. Around that time is when I noticed the "window issue" related to videos I described in comment 7 of this bug. You specifically mention having a video open in a tab makes it easy for you to reproduce the issue. A video-related issue precipitated the crash I had in comment 3 of this bug. I don't recall videos really relating at all to the original issue I had. Maybe there is a second problem which has not yet been identified.

I'm not sure if it's been happening since Firefox 102, since there was a KDE KWin bug around the same time causing other issues.

It seems like it's just switching tabs too many times causes it for me, something I do more when I am listening to a video in the background since I will be switching to the video tab and back again. So having a playing video is most likely unrelated.

FYI, the patch for bug 1781167 is now available on the Firefox Beta channel as well in 108.0b8 or later. Any additional testing would be greatly appreciated!

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)

FYI, the patch for bug 1781167 is now available on the Firefox Beta channel as well in 108.0b8 or later. Any additional testing would be greatly appreciated!

I just passed the 48 hour mark with no freezes (my success criteria) running 108.0b8 so this patch continues to work for my install.

This is a separate issue from the libX11 issue, the rendering issue I have been getting does not cause the browser to crash, as shown in my video.

The libX11 issue is only about a month old, and would cause the browser to permanently freeze or crash. the rendering freeze issue has been going on for about 5 months and does not cause a browser crash or freeze.

(In reply to Jessica from comment #17)

This is a separate issue from the libX11 issue, the rendering issue I have been getting does not cause the browser to crash, as shown in my video.

The libX11 issue is only about a month old, and would cause the browser to permanently freeze or crash. the rendering freeze issue has been going on for about 5 months and does not cause a browser crash or freeze.

Splitted back into 2 bugs, thanks!

I can also reproduce this bug in fedora 36 with firefox 107.0.1

(In reply to Santino Mazza from comment #19)

I can also reproduce this bug in fedora 36 with firefox 107.0.1

Do you also have KDE with an Nvidia graphics card?

(In reply to Jessica from comment #0)
The tab is shortly dragged at 7s which should cause a small window preview (introduced 2021-11-02 by bug 1730533 comment 27) to show up next to the mouse pointer.

There is a known KDE/Nvidia bug, maybe it is related:

• EGL&GLX/KDE/Nvidia with compositor disabled:
  taskbar window preview can freeze Firefox if Firefox has partial present enabled: bug 1723323 comment 16 (maybe a regression caused by bug 1663273).
  bug 1751252 should have disabled partial present on Nvidia.
• EGL&GLX/KDE/Nvidia with compositor enabled:
  taskbar window previews can freeze Firefox and glxgears: bug 1723323 comment 12

Please open about:config, set gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0,
close Firefox,
disable the KDE compositor by pressing Shift+Alt+F12 (or in Settings>Display&Monitor>Compositor>Uncheck "Enable compositor" and then logout&login), all windows should have lost their border shadows,
start Firefox, and check if the problem is still reproducible.
If the problem is gone, then this is the same as bug 1723323.

(In reply to Darkspirit from comment #20)

(In reply to Santino Mazza from comment #19)

I can also reproduce this bug in fedora 36 with firefox 107.0.1

Do you also have KDE with an Nvidia graphics card?

Nope, I don't have an nvidia card.
I'm using gnome 42.6

(In reply to Darkspirit from comment #20)

(In reply to Santino Mazza from comment #19)

I can also reproduce this bug in fedora 36 with firefox 107.0.1

Do you also have KDE with an Nvidia graphics card?

(In reply to Jessica from comment #0)
The tab is shortly dragged at 7s which should cause a small window preview (introduced 2021-11-02 by bug 1730533 comment 27) to show up next to the mouse pointer.

There is a known KDE/Nvidia bug, maybe it is related:

• EGL&GLX/KDE/Nvidia with compositor disabled:
  taskbar window preview can freeze Firefox if Firefox has partial present enabled: bug 1723323 comment 16 (maybe a regression caused by bug 1663273).
  bug 1751252 should have disabled partial present on Nvidia.
• EGL&GLX/KDE/Nvidia with compositor enabled:
  taskbar window previews can freeze Firefox and glxgears: bug 1723323 comment 12

Please open about:config, set gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0,
close Firefox,
disable the KDE compositor by pressing Shift+Alt+F12 (or in Settings>Display&Monitor>Compositor>Uncheck "Enable compositor" and then logout&login), all windows should have lost their border shadows,
start Firefox, and check if the problem is still reproducible.
If the problem is gone, then this is the same as bug 1723323.

Just tested with those settings off and the compositor off, I was still able to reproduce the bug after enough tab switching

I've noticed, in the patch for the original bug 1781167, that DispatcherRefWithCount::mCount is a size_t. From what I understand, operations on mCount are performed from multiple threads. Shouldn't it be of an atomic type?

I was also able to reproduce the bug as well (Linux Mint + Cinnamon 20.1, Firefox 108.0.1 w/ Nvidia card) and from my experience, it also occurs when switching between tabs sometimes when I end up dragging a tab a very short distance instead of clicking on it, as described by Darkspirit. It appears once this occurs I can re-drag the original highlighted tab to restore the rendering functionality of the tab list.

I am currently experiencing the same issue as shown in the video that was posted by Jessica. Seems I can reproduce this bug 90% of the time just by clicking back and forth between tabs.

OS: Pop!_OS 22.04 LTS x86_64
DE: GNOME 42.3.1
Firefox: 108.0 64-bit (Default .deb install from Pop!_OS 22.04 LTS)
GPU: NVIDIA GeForce GTX 1060 6GB (Driver: 525.60.11)
RAM: 16GB DDR3

(In reply to Jessica from comment #0)
I wonder why nobody (including me) has suggested using mozregression.
Please test this:
$ pip3 install mozregression

Does the problem occur with this build?
$ mozregression --repo autoland --launch 9648a34ca72f2cf7dc1115b2b8f957e58280bf26 -a https://www.wikipedia.org/ -a https://en.wikipedia.org/wiki/Main_Page

Is this build fine?
$ mozregression --repo autoland --launch 78a0b6b0e8420c82792c9911d24696f2ec5b74ea -a https://www.wikipedia.org/ -a https://en.wikipedia.org/wiki/Main_Page

• If both answers have been yes, we can close this as duplicate of bug 1796960.
• Otherwise, please try to find a regression range (if possible).
  $ mozregression --good 2022-01-30 --bad 2022-11-23 -a https://www.wikipedia.org/ -a https://en.wikipedia.org/wiki/Main_Page

I too can reproduce this.
Linux Mint MATE 20.3
Marco compositor
X11, Intel G31 i915

But interestingly I have never encountered it before until I actually tried to reproduce it specifically with the technique cited above of slightly dragging tabs when switching between them. Otherwise I'm normally very precise about clicking and not dragging