Closed Bug 1796960 Opened 2 years ago Closed 7 months ago

Cinnamon+KDE+MATE: Firefox breaks when dragging tabs at the same time as switching them

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 105
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1875369
Milestone:
123 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox106 --- wontfix
firefox107 --- wontfix
firefox108 --- wontfix
firefox109 --- wontfix
firefox110 --- wontfix
firefox111 --- wontfix
firefox121 --- wontfix
firefox122 --- wontfix
firefox123 --- wontfix
firefox124 --- fixed

People

(Reporter: yoasif, Assigned: stransky, NeedInfo)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: hang, regression)

Attachments

(9 files)

screencast of issue
2.01 MB, video/webm
Details
Bug 1796960 [Linux] Return correct nsWindow::IsMapped state on X11 r?emilio
48 bytes, text/x-phabricator-request
Details | Review
log.txt
689.73 KB, text/plain
Details
log.txt
954.58 KB, text/plain
Details
about:support-firefox-nightly-buildid-20240117145030-share.txt
38.65 KB, text/plain
Details
log-MOZ_LOG-nsRefreshDriver:5-WidgetPopup:5-buildid-20240117145030.txt
1.63 MB, text/plain
Details
firefox-custom-build-1-crash-output.txt
20.48 KB, text/plain
Details
cnee-events-share.xnr
435.33 KB, application/octet-stream
Details
Tab bar messed up with Nightly 124.0a1 (2024-02-15)
1.03 MB, video/webm
Details

From: https://www.reddit.com/r/firefox/comments/xwv91x/firefox_breaks_when_dragging_tabs_at_the_same/

Sometimes when I switch my current tab to a different tab and I accidentally drag the tab on the bar at the same time, Firefox locks up and begins rendering a gray screen. I am still able to change the open tab, because the uppermost bar will display the correct page name, but I can only resume using Firefox by restarting Firefox all together, or pressing alt+F2 and inputting "r". This normally makes Firefox return to normal, but sometimes I am left being not able to click on the URL bar area at all, including my pinned addons, and cannot close the current tab I am in, only tabs I am not viewing. Minimizing and re-maximizing the open window allows me to resume viewing the page I have opened, but once I swap tabs it returns to a gray page.

mozregression shows:

20:19.85 INFO: Last good revision: 78a0b6b0e8420c82792c9911d24696f2ec5b74ea
20:19.85 INFO: First bad revision: 9648a34ca72f2cf7dc1115b2b8f957e58280bf26
20:19.85 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=78a0b6b0e8420c82792c9911d24696f2ec5b74ea&tochange=9648a34ca72f2cf7dc1115b2b8f957e58280bf26

Has STR: --- → yes
Regressed by: 1782049

Set release status flags based on info from the regressing bug 1782049

:stransky, since you are the author of the regressor, bug 1782049, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

status-firefox106: --- → affected
status-firefox107: --- → affected
status-firefox108: --- → affected
status-firefox-esr102: --- → unaffected
Flags: needinfo?(stransky)

Can you please create a screencast of it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.

Blocks: linuxdad
Flags: needinfo?(stransky) → needinfo?(yoasif)
Priority: -- → P3

I tried to reproduce but without luck. Would be great to see a screencast of it so I can try to reproduce it.
Thanks.

Attached video screencast of issue —

Martin, the user responded with a screencast. See attached.

You can see the page actually open when the issue occurs is Wikipedia, despite Google being rendered.

Flags: needinfo?(yoasif)

Looks like we fail to quit D&D operation.

Flags: needinfo?(stransky)
See Also: → 1802229
Summary: Firefox breaks when dragging tabs at the same time as switching them → Cinnamon+KDE: Firefox breaks when dragging tabs at the same time as switching them
Duplicate of this bug: 1802229
Summary: Cinnamon+KDE: Firefox breaks when dragging tabs at the same time as switching them → Cinnamon+KDE+MATE: Firefox breaks when dragging tabs at the same time as switching them
Flags: needinfo?(stransky)
Duplicate of this bug: 1794455
See Also: 1802229 →
Keywords: hang
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

Raising priority to match the dupe bug 1802229.

Priority: P3 → P2
Duplicate of this bug: 1820433
Duplicate of this bug: 1821421
See Also: → 1820010

I still encounter this issue with firefox 112.0 right now.

Is a fix or workaround available ?

(In reply to dav87legrand from comment #11)
Which desktop environment and Linux distribution are you using?

(In reply to Darkspirit from comment #12)

(In reply to dav87legrand from comment #11)
Which desktop environment and Linux distribution are you using?

Up to date Manjaro with Gnome 43.4.

Duplicate of this bug: 1831761

Just figured out that if I disable tab drag images by setting "nglayout.enable_drag_images" to False it appears to fix the issue for me.

(In reply to Jessica from comment #15)

Just figured out that if I disable tab drag images by setting "nglayout.enable_drag_images" to False it appears to fix the issue for me.

Yes, it fix the issue for me too. Thanks.

(In reply to Jessica from comment #15)

Just figured out that if I disable tab drag images by setting "nglayout.enable_drag_images" to False it appears to fix the issue for me.

+1

Duplicate of this bug: 1692073
No longer duplicate of this bug: 1692073

This bug is still happening to me but it seems to also now be triggered sometimes by typing in the address bar in addition to it triggering when clicking out of the downloads menu while a download is starting (downloads menu rendering freeze has been happening for about a year now).

I can sometimes fix it by rapidly clicking the download buttons or the "View history, saved bookmarks, or more" button until it works. If that doesn't work I'll have to popout a tab to a new window and move all of my tabs to the new window.

Also worth adding I noticed in 1692073 it was mentioned that this bug is X11 only. This has only ever happened to me on Wayland

See Also: → 1862711
See Also: → 1861932
Duplicate of this bug: 1861932
Duplicate of this bug: 1862711
See Also: 1862711 →
See Also: → 1872970

Can Firefox please prioritize this issue? It is marked as P2 (for a year). The issue is even older. It is really annoying. At this point we know how to reproduce it and we know the workaround (nglayout.enable_drag_images).

Yes, we should look at it. IIUC enable_drag_images allows to paint images from webpage to web preview used by D&D widget. The D&D widget may be hidden (but not deleted) while the images are still painted by compositor and that's the regression we see from Bug 1782049 where compositor suspend was reconfigured.

Can please someone test if it affects Wayland too? You don't need to install Gnome for it, nested mutter/kwin session may be enough:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
(because Wayland uses different compositor configuration and terminated compositor operations more aggressively).

Thanks!

Flags: needinfo?(stransky)

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

Yes, we should look at it. IIUC enable_drag_images allows to paint images from webpage to web preview used by D&D widget. The D&D widget may be hidden (but not deleted) while the images are still painted by compositor and that's the regression we see from Bug 1782049 where compositor suspend was reconfigured.

Can please someone test if it affects Wayland too? You don't need to install Gnome for it, nested mutter/kwin session may be enough:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
(because Wayland uses different compositor configuration and terminated compositor operations more aggressively).

Thanks!

I tested it before, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1861932#c2
Let me know if i tested incorrectly. Also in that ticket a somewhat reliable way to reproduce the issue.

So far, I'm not able to reproduce this on Gnome/Wayland.

We should return correct nsWindow::IsMapped state on X11 too to prevent rendering lock to hidden windows with suspended compositor.

Assignee: nobody → stransky
Status: NEW → ASSIGNED

Let's see if the correct mapped state helps here.

Flags: needinfo?(stransky)

I triggered the bug while using an updated firefox nightly. Output of "./firefox --full-version" is "Mozilla Firefox 123.0a1 20240110213539 20240110213539". I believe this includes the above change in comment #27. Let me know if I'm wrong or there is a better way to test changes.

Steps:

  1. create new profile
  2. disable telemetry and studies
  3. open 31 blank tabs (more than enough to cause tabs to overflow)
  4. open one additional tab at right, opened to https://commons.wikimedia.org/wiki/Main_Page#/media/File:Mont_Blanc_from_Les_Arcs_1950.jpg
  5. view the tab of the wikimedia page, which is the tab at the far right
  6. repeatedly drag this tab leftward in quick, very short motions, not enough to make the tab change position. Can be straight left, left-up, or left-down.

Notes:

  • I have managed to trigger this with only 2 tabs opened before but it took a long time. I tried it with one blank and one with the wikimedia image and couldn't do it. It seems that having enough tabs opened to overflow, or some point beyond that makes it much easier.
  • I tried this with 32 blank tabs and couldn't trigger it. Then opened the last tab, the one I'm dragging, to the wikimedia image, and it became fairly easy. It seems that what is opened in the dragged tab matters.
See Also: → 1873896
Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/7f052059f564
[Linux] Return correct nsWindow::IsMapped state on X11 r=emilio

Thanks for testing!

Let's see if the patch here helps, it should be included in nightly tomorrow. Unfortunately I haven't been able to reproduce it locally on XFCE or any other X11 desktop.

If patch D198144 doesn't help I'll add more logging to compositor pause/resume code to get better picture what's going on.

Flags: needinfo?(stransky)

I was able to reproduce this in Mozilla Firefox 123.0a1 20240111095249.

I was also succeeded at recording the mouse events that trigger the bug with cnee so that I can quickly test this, at least currently.

https://hg.mozilla.org/mozilla-central/rev/7f052059f564

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
status-firefox123: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

So can you please re-test with latest nightly?
Thanks.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Flags: needinfo?(stransky)
Flags: needinfo?(stransky)

I can reproduce it in Firefox 123.0a1 20240112045806 on Gnome/X11.

I can also reproduce on KDE/Wayland with the latest nightly

Okay, thanks for testing!

See Also: → 1874527

Please run on terminal with MOZ_LOG="nsRefreshDriver:5 WidgetPopup:5" env variables, reproduce the freeze, terminate firefox (by CTRL+C from terminal) and attach the log here.

For instance run as:

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

and attach the log.txt here.

Thanks.

Flags: needinfo?(jessica)
Attached file log.txt —
Flags: needinfo?(stransky)

Please attach your about:support page.
Thanks.

I can still reproduce it on latest Nightly 123.0a1 (2024-01-16) with X11/XWayland on Ubuntu 23.10 GNOME (fixed by nglayout.enable_drag_images = false). I cannot reproduce it on native Wayland with any version.

@Jessica, please visit about:support and confirm that the Window Protocol value is wayland.

Attached file log.txt —

I can also confirm that my Window Protocol is Wayland

Flags: needinfo?(jessica)

I ran the test again and made a new log because the nightly updated.

I get the following error when I try to run it:

XPCOMGlueLoad error for file /home/user/projects/bugs-firefox-tab-drag-freeze/firefox/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

I run file libmozgtk.so in the nightly directory:

$ file libmozgtk.so
libmozgtk.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=980721a28edcac53cd38090056a049fada3f8d2b, not stripped

I run file libmozgtk.so in the custom build directory:

$ file libmozgtk.so
libmozgtk.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=6e90069197af30922c81796c0f15bdfe59c6faf7, not stripped

Also, are you wanting me to do supply the about:config or debug log output for future tests as I did before?

I'm sorry, I posted wrong link (to 32bit executable).

Correct one is:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/auyVBGd1Q8OPGhqK6gpNZw/runs/0/artifacts/public/build/target.tar.bz2

Thanks.

Flags: needinfo?(yodegaw650)

My bug-triggering script is crashing the custom build. I'm not sure what logs you want, if any.

Flags: needinfo?(yodegaw650)

Bug 1875369 may be related.

See Also: → 1875369

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

I'm sorry, I posted wrong link (to 32bit executable).

Correct one is:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/auyVBGd1Q8OPGhqK6gpNZw/runs/0/artifacts/public/build/target.tar.bz2

Thanks.

This looks like it fixes it for me, as well as fixing bug 1873896

Flags: needinfo?(jessica)

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

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

This one seems to crash more readily than the last build.

I guess I can't edit comments here. The last test refers to gnome/x11. I just noticed that your needinfo refers to someone other than me. Let me know if I don't need to test. I can test wayland too, but I haven't made a script to trigger it and I'm not sure if that's possible on wayland.

(In reply to Flagellum from comment #52)

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

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

This one seems to crash more readily than the last build.

Great. Please provide any info about the crashes you can. For instance can you crash it, submit crash report and post crash ID here?
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_Mozilla_crash_reporter
Thanks!

Flags: needinfo?(yodegaw650)

This is the output on the shell when I crash it. I was getting the crash reporter catching the crash before but it hasn't been catching it lately.

Flags: needinfo?(yodegaw650)

(In reply to Flagellum from comment #55)

Created attachment 9375594 [details]
firefox-custom-build-1-crash-output.txt

This is the output on the shell when I crash it. I was getting the crash reporter catching the crash before but it hasn't been catching it lately.

That's interesting, Thanks. Please run on terminal with G_DEBUG=fatal-warnings env variable - it should crash on the warning. Then please submit crash to Mozilla and attach crash ID here.
Thanks!

Flags: needinfo?(yodegaw650)

Crash ID: bp-b6892c9d-58ca-4d4d-88b1-bde790240120

Flags: needinfo?(yodegaw650)

(In reply to Flagellum from comment #57)

Crash ID: bp-b6892c9d-58ca-4d4d-88b1-bde790240120

Thanks a lot. btw may you share your test script/scenarion so I can use it locally for testing?

Attached file cnee-events-share.xnr —

My environment is Gnome/X11, 3840x2160, scale 200%, firefox maximized.

Command is: 'cnee --keep-autorepeat --replay -f cnee-events-share.xnr --time 2'

After executing the command, you have 2 seconds to switch to the firefox window, then let it run. cnee does give errors but it seems to work and I've not bothered to figure out the cause.

I open 30 blank tabs. I (sometimes) change the last tab at right that will be dragged to https://commons.wikimedia.org/wiki/Main_Page or an image available on that page. You might find that what is loaded in the dragged tab and whether the adjacent tab is loaded makes a difference.

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

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

I can confirm that I'm not getting the bug on these other builds as well, same with the downloads menu bug.

Flags: needinfo?(jessica)

I haven't been able to trigger the bug in Gnome/X11. I've triggered it a few time in Gnome/Wayland with extensions installed. One time crashed it. Another time resulted in menus being blank, but I could still switch tabs. I don't remember if I ever triggered it without extensions enabled. Do we consider the presence of extensions to be out of scope for firefox bugs? Are we to test firefox with no extensions enabled?

Flags: needinfo?(yodegaw650)

Recent Ubuntu 23.10 updates seem to have changed tab dragging behavior. I used to be able to rearrange tabs as quickly as I could physically move the mouse but now they aren't dragged if I do it too fast. This makes it much more difficult to reproduce the issue with any Nightly version.

My apt history log shows the following updates since it was last easily reproducible:

xserver (2:21.1.7-3ubuntu2.4, 2:21.1.7-3ubuntu2.6)
xwayland (2:23.2.0-1ubuntu0.3, 2:23.2.0-1ubuntu0.4)
mutter (45.2-0ubuntu2~really45.0, 45.2-0ubuntu3)

Should be fixed by Bug 1875369.

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?(ke5trel)
Flags: needinfo?(yodegaw650)

I can reproduce a less severe version of this on Release 122 and Beta 123 (XWayland) with fully patched Ubuntu 23.10. The issue is first noticed when the window gets dragged instead of the tab, the toolbar area becomes unresponsive (content still responsive) and can be corrected by dragging the active tab.

On latest Nightly 124.0a1 (2024-02-15) (XWayland) the toolbar area does not become unresponsive but the tab bar can get messed up, with one tab overlapping or missing and leaving an empty space. Once again it can be easily corrected by dragging a tab.

Flags: needinfo?(ke5trel)

(In reply to Kestrel from comment #66)

On latest Nightly 124.0a1 (2024-02-15) (XWayland) the toolbar area does not become unresponsive but the tab bar can get messed up, with one tab overlapping or missing and leaving an empty space. Once again it can be easily corrected by dragging a tab.

That's interesting. Can you confirm it's regression from Bug 1875369? Perhaps by mozregression.
Thanks.

Flags: needinfo?(ke5trel)

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

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

I tried the latest nightly and it seems the bug is still fixed! I can't reproduce it at all anymore

Cool, Thanks.

Status: ASSIGNED → RESOLVED
Closed: 8 months ago → 7 months ago
Duplicate of bug: 1875369
Resolution: --- → DUPLICATE

I'm quite sure I have seen comment 67 way before this bug appeared, so it's probably unrelated.

I can confirm Comment 67 is unrelated, I was able to repro it with a build before Bug 1875369 landed.

Flags: needinfo?(ke5trel)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: