1778349 - [Sway] Popup from clicking a bookmark folder in the bookmark toolbar (having more bookmarks then what fits on the screen) gives no popup or flickers for one frame and sometimes crashes the browser

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Gergő Sályi]

Attachment: firefox-bookmark-folder.png

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

Steps to reproduce:

OS: Linux, Wayland (wl-roots based) Sway window manager
Firefox: Firefox Developer Edition 103.0b4 (Arch Linux package)

0. This bug is Linux / Wayland specific

1. Create a new browser profile named 'debug-profile'

2. Open a terminal

3. $ export MOZ_ENABLE_WAYLAND=1 # Make sure Firefox Wayland backend is enabled

4. $ firefox-developer-edition -P debug-profile # or 'firefox' for you - as I have the developer edition. Launch a window with our 'debug-profile'

5. maximize the browser window

6. Open a new empty tab

7. Right click on the Bookmark Toolbar (below the address bar) -> Add folder... (eg. name it New Folder)

8. Go to a website where you can make a lot of bookmarks in a short time (eg. Wikipedia)

9. Press Ctrl+D to add the first bookmark, select Bookmark Toolbar -> [New Folder] as the location of the bookmark

10. Open a new empty tab, verify that left-clicking [New Folder] in the Bookmark Toolbar brings up a healthy popup
    (see the attached picture)

11. Keep opening new webpages (eg. Wikipedia links) and hitting Ctrl+D (a new bookmark will be automatically placed in the [New Folder] folder)

12. Repeat step 11. until the [New Folder] contains so many bookmarks, that the popup (from step 10.) would not fit in the screen

13. Now try step 10.: Open a new empty tab and left-click [New Folder] in the Bookmark Toolbar.

Actual results:

No popup apperars or a popup just flickers for one frame.
Trying to click on the bookmark folder repeatedly will sometimes crash the whole browser (may need ca. 20-50 attempts)

Captured stdout+stderr from a crash:
$ firefox-developer-edition -P debug-profile
Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
[GFX1-]: Invalid mBounds in PopupCallback Rect(x=303, y=109, w=422, h=20367) size state 0
(firefoxdeveloperedition:36765): Gdk-CRITICAL **: 16:52:41.076: ../gtk/gdk/wayland/gdkdisplay-wayland.c:1399: Unable to create Cairo image surface: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
ExceptionHandler::GenerateDump cloned child 37539
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
[GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.

Hint: I tried to trace the issue a bit with:
$ export MOZ_LOG="WidgetPopup:5"
Looking at the log shows a possible trace in ./widget/gtk/nsWindow.cpp
When executing nsWindow::UpdateWaylandPopupHierarchy()

1. nsWindow::WaylandPopupFitsToplevelWindow() being called and correctly logs: "fits 0" or "fits 1" depending on if the bookmark-folder popup would fit the screen
2. but whatever actions are being taken in the subsequent nsWindow::WaylandPopupMove() call for the non-fitting popup are maybe incorrect
   As for the non-fitting popup, the log shows an infinite loop of these calls, likely failing to constrain the popup window size inside the screen area.

Expected results:

A scrollable popup constrained by the screen bounds should appear.

You can test the desired behavior by:

• closing the browser window
• on the terminal:
  $ export MOZ_ENABLE_WAYLAND=0
  $ firefox-developer-edition -P debug-profile
• If you have Xwayland installed now Firefox will fall back to XWayland X11 backend
• Bookmark folder popup works correctly

Comment 1

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

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.

Comment 2

[Eugene Popov]

Does the layout.css.devPixelsPerPx (in about:config) have a fractional value?

Comment 3

[Gergő Sályi]

(In reply to Eugene Popov from comment #2)

Does the layout.css.devPixelsPerPx (in about:config) have a fractional value?

That value is -1.0 (not changed from the default value)

Comment 4

[Eugene Popov]

I have the same issue, but only if layout.css.devPixelsPerPx has a fractional value.

Comment 5

[Erik Reider]

I'm experiencing the same issue and my "Layout.css.devPixelsPerPx" is set to -1.0 (default value)

Comment 6

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

Please test latest nightly under Wayland with layout.css.devPixelsPerPx set to -1.0 (the default one):
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 7

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

Also please try different compositor (mutter):
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Thanks.

Comment 8

[Erik Reider]

Seems to be working in nightly but the popups extend beyond the screen but that's a separate issue... :)

Comment 9

[Gergő Sályi]

Attachment: moz_log_mutter.txt

Comment 10

[Gergő Sályi]

Attachment: moz_log_sway.txt

Comment 11

[Gergő Sályi]

Okay, so I tested this on latest nightly (2022-09-09-09-39-17-mozilla-central) with both Mutter and Kwin wayland (both as nested wm and as launched from tty), and on both of them popups are working fine.
Also with current Firefox beta normal Firefox it is working fine on both Mutter and Kwin wayland.

So this is issue is Sway-specific. (Apologies for not noticing that first).

Seems to be working in nightly but the popups extend beyond the screen but that's a separate issue... :)

No, sadly on sway it is still not working just the malformed popup now displays instead of flickering / not displaying. It has the same issue. And still crashes the whole browser after opening the popup a couple dozens of times.

$ MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote
[GFX1-]: Invalid mBounds in PopupCallback Rect(x=284, y=109, w=344, h=27535) size state 0
(firefox-nightly:29214): Gdk-CRITICAL **: 15:09:10.011: ../gtk/gdk/wayland/gdkdisplay-wayland.c:1399: Unable to create Cairo image surface: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
ExceptionHandler::GenerateDump cloned child 29851
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error. 

I found out that one can also trigger this in the about:preferences#general font selection popup which also tends to be large.

I can attach a log from both sway and mutter tested as similar as possible with.
$ MOZ_ENABLE_WAYLAND=1 MOZ_LOG="WidgetPopup:5" firefox -ProfileManager -no-remote >moz_log_vm.txt 2>&1

Attached files: moz_log_mutter.txt , moz_log_sway.txt
On line 54 : both on mutter and on sway "parent window size" is determined correctly
On line 86 : on mutter popup size is seemingly set correctly, while on sway popup size is seemingly set too large (larger than the whole screen) and continues to grow up to 60000 px height with repeated resize calls that eventually results in the crash

Anyway I could understand if Firefox devs decide not to deal with this as it turned out as a sway specific issue.
ps. What are your impressions, is this a sway bug?

Comment 12

[Gergő Sályi]

I just compiled myself both my Sway and wlroots from git master branch replacing the current Arch Linux provided packages .

This fully resolved the issue on all (normal, beta, nightly) current Firefox releases.

Thank you for the help. It seems Firefox is innocent here (as far as a bugged window manager is allowed to cause breakage) and the issue will be resolved for everyone ones the fixes in Sway and wlroots packages will make their way to the Arch Linux and other distro's repository.

Please feel free close this issue.

Comment 13

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

Thanks, closing then.