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

Steps to reproduce:

Existing bookmark toolbar folders working fine in Arch Linux (most current) up to 94.0.2.

Upgrade to 95.0 via pacman. Folders with more than a page of entries will not open when cursor hover/clicked. On folders with larger entry quantities, holding the cursor over the folder will eventually crash the browser, requiring restart.

Upgrading to 95.0.1 exhibits same issues.

Actual results:

Bookmark folder entries does not display. Folders with larger entry quantities will crash the browser version 95+.

Expected results:

Folder entries should display in new menu list.

Will stay with version 94.0.2 until resolved.

Problem still unresolved with 95.0.2.

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

(In reply to scruffidog from comment #0)

Upgrade to 95.0 via pacman. Folders with more than a page of entries will not open when cursor hover/clicked. On folders with larger entry quantities, holding the cursor over the folder will eventually crash the browser, requiring restart.

Do you see crash reports in about:crashes? Pasting some of those crash ids may be useful to debug the problem.
Can you tell us more about your Linux environment, the window manager and so on?
Also attaching a .txt log from about:support to the bug may provide useful information.

Environment is:
firefox-95.0.2
wayland-1.20
gtk-3.24.31
pipewire-0.3.42
wlroots-0.14.1

just did some more poking around; it seems to be related to quantities of entries needing to be displayed vertically (submenu, folder, etc).
Bad things seem to happen when the number of entries and its allocated spacings exceed the screen height/vertical resolution.
Enabling compact mode seems to allow for more entries due to smaller spacing requirements.

Hello!
I have tried to reproduce the issue using Firefox 97.0a1(2021-12-23) on Ubuntu 20.04 but unfortunately I wasn't able to reproduce the issue.

Could you please answer the following questions in order to further investigate this issue:

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed if so can you list them?

(In reply to Negritas Sergiu from comment #8)

Hello!
I have tried to reproduce the issue using Firefox 97.0a1(2021-12-23) on Ubuntu 20.04 but unfortunately I wasn't able to reproduce the issue.

Could you please answer the following questions in order to further investigate this issue:

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Crashes on any profiles, including new. Have noticed that the bigger the list, the quicker it crashes.

2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

Have not tried nightly. Will need some time to do this.

3. Do you have any addons installed if so can you list them?
   see attached screenshot. Also ran it in safe mode with all extension/etc disabled; still crashes.

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

For more information, please visit auto_nag documentation.

Bug 1745553 contains a similar case related to the overflow menu on the bookmarks toolbar, that also contains a WebRender crash.

Jim, could someone from WebRender please check these bugs and crash reports, and see if anything obvious points to a graphics bug, or if it's more like a widget one?

still crashes under 96.0

(In reply to scruffidog from comment #5)

about:crashes
bp-73b5ea27-93cd-4107-91db-7e2880211220 12/19/21, 20:04
bp-6440142c-8931-4cbe-ba25-da1c60211221 12/21/21, 12:37
bp-832977a5-858e-453f-ac39-ee8de0211221 12/21/21, 12:38
bp-86ecfbf8-b436-4edc-b826-8e53e0211221 12/21/21, 12:38

about:support

Glenn, mind taking a look a these? Marco is curious if this is webrender related or something happening higher up in layout and display list generation code.

It looks like it's likely to be something higher up, perhaps in the widget level, I think.

The crash messages are:

Attempting to create a 460x980536 window/document
Attempting to create a 460x31688 window/document
Attempting to create a 460x17476 window/document

So it looks like Gecko is trying to create a top-level window that is much too large to display. It's possible that we might be able to handle this better in some cases in WR, but there's potential issues with DirectComposition surface sizes etc.

Nical, Jeff, does this seem like a higher up level we can fix in Gecko?

Some more testing where the menu list is shortened some that it does not go pass the borders of the display; the entries near the borders have their context menu cut off by the border. The past behavior is that the context menus always relocates so the whole menu is displayed. Don't know if this helps in tracking the culprit down...

Given comment 15 this problem looks similar to bug 1695591 which is caused by overly large widgets (for example a tooltip that contains a very long string and does not attempt to truncate it).

bug 1736601 seems to have the regression range when either the height became unrestricted/too large or when it became a problem.

My bug https://bugzilla.mozilla.org/show_bug.cgi?id=1747641 is different, on my FF 98.0a1 (2022-01-26) i have bookmark folders extending on more than 2 pages without problems.

The bug is still present for me on ff100.

Can anyone confirm that crash on Gnome/KDE? I see such reports from Sway only.
Thanks.

I can no longer reproduce this with Firefox 100 on sway. AFAIK, I was also fixed on Firefox 99 (at least for me).

Maybe someone else can comment if they can still repro?

I'm still able to reproduce this issue on Sway using mozregression with build 20220517212638 using the steps to reproduce from Bug 1736601 (a dup of this one). I'm unable to reproduce the issue on mutter or weston.

Indeed, this seems a bug of wlroots-based compositors,
as it does not happen with Gnome.
It's still present on the former though (I use river).

For reference, I believe this is swaywm/sway#6786 which was fixed by wlroots/wlroots!3446 in wlroots/wlroots@511f137f (bisected using swaywm/sway@85d1c984).

I'm unable to reproduce the issue with sway and wlroots built from master branches (swaywm/sway@956b689d and wlroots/wlroots@d57d2e0e) confirming this should be fixed in the next release.