Closed Bug 1789956 Opened 2 years ago Closed 2 years ago

The contents of bookmarks folders within folders are moved to the left overtop of the folder menu and the folders' contents stopped being shown with Firefox Nightly 106.0a1 (2022-9-8) on Wayland

Categories

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

Firefox 106
defect

Tracking

()

VERIFIED FIXED
107 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- unaffected
firefox104 --- unaffected
firefox105 --- unaffected
firefox106 --- disabled
firefox107 --- verified

People

(Reporter: matt.fagnani, Assigned: stransky)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression)

Attachments

(4 files)

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

Steps to reproduce:

I started Firefox Nightly 106.0a1 (2022-9-8) 20220908213354 on Wayland with WebRender compositing in Plasma 5.25.5 in a Fedora 37 KDE Plasma installation. I clicked on Bookmarks in the Menu bar. I moved the cursor over various bookmarks folders some of which had folders within them.

Actual results:

The contents of bookmarks folders within folders were moved to the left by about the width of a bookmark folder menu, and so they were shown over top of the folder with Firefox Nightly 106.0a1 (2022-9-8) 20220908213354. The bookmarks folders' contents stopped being shown after moving the cursor over a few folders within folders. The contents of different tabs stopped being shown correctly sometimes when trying to switch between tabs in the tab bar after the bookmarks folder's contents stopped appearing.

This problem didn't happen with 106.0a1 (2022-9-8) 20220908092810 or earlier. I ran
mozregression --good 2022-09-07 --bad 20220908213354 -p ~/.mozilla/firefox/z8d4nvrc.default-nightly --profile-persistence reuse

8:41.26 INFO: No more integration revisions, bisection finished.
8:41.26 INFO: Last good revision: 2134d24b6f1685be245cf37db75736e1b78da481 8:41.26 INFO: First bad revision: 34c74cef1af0f07a45178923456153544ca4621e
8:41.26 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2134d24b6f1685be245cf37db75736e1b78da481&tochange=34c74cef1af0f07a45178923456153544ca4621e

The bisection gave the first bad change as that for Bug 1788910 involving Wayland tooltips and popups.
34c74cef1af0f07a45178923456153544ca4621e stransky — Bug 1788910 [Wayland] Look for parents recursively at nsWindow::WaylandGetParentPosition() r=emilio

Expected results:

The contents of bookmarks folders within folders would appear normally to the right of the folders they're in. The contents of bookmarks folders would continue being shown normally. Switching between tabs would show the correct tab's screen normally after the contents of some bookmarks folders in folders were shown.

Regressed by: 1788910

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(stransky)

The contents of the bookmarks folders within folders were shown lower than they usually were that is they were moved downwards. Folders with about 20 or more bookmarks were sometimes cut off by the bottom of the screen as a result. Parts of Firefox's interface including the menu bar, tab bar, address bar, and toolbar became unresponsive for around 30-60 seconds after showing the contents of 3-5 bookmarks folders within folders. So the freezing of the tab bar I initially reported wasn't limited to it. The change in Bug 1788910 might have led to excessive resource usage after showing the contents of at least 3 bookmarks folders in folders possibly related to it being recursive.

This problem happened with 106.0a1 (2022-9-8) 20220908213354 on Wayland in GNOME 43.rc on Wayland. This problem didn't happen with 106.0a1 (2022-9-8) 20220908213354 on XWayland in Plasma. The problem seems to be Wayland-specific.

Flags: needinfo?(stransky) → needinfo?(matt.fagnani)

I'm attaching a screen recording of 106.0a1 (2022-09-09) 20220909093917 made with OBS Studio. I used a new profile with 3 test bookmarks folders within a folder in which I put 2 of the default Nightly bookmarks. I clicked on the Bookmarks menu then moved the cursor over the bookmarks folders. The contents of a folder was shown to the left of where it would normally be and it covered the folder menu. I moved the cursor over the other folders, and their contents weren't shown. The interface didn't respond when I clicked on Tools and Help in the menu bar, tried to create a new tab by clicking the + button, clicked on the address bar, and clicked on the Pocket button in the toolbar. The about:performance output was frozen when this happened. Thanks.

Flags: needinfo?(matt.fagnani)

I'm going to go ahead and confirm since I can reproduce this as well on Fedora 36 and bisected the change to the same checkin. Note that setting the preference widget.wayland.use-move-to-rect to false is a partial work around.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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

(In reply to Bob Clary [:bc] (inactive) from comment #5)

I'm going to go ahead and confirm since I can reproduce this as well on Fedora 36 and bisected the change to the same checkin. Note that setting the preference widget.wayland.use-move-to-rect to false is a partial work around.

Thanks. I set widget.wayland.use-move-to-rect to false in 106.0a1 (2022-09-11) on Wayland in Plasma, and the contents of the bookmarks folders in folders are to the right of the folder again instead of to the left. The top of the contents are at the same level as the folder the cursor is over, so sometimes the contents are cut off by the bottom of the screen depending on their position and the number of bookmarks. Firefox has remained responsive when I moved the cursor over several folders in folders. The bookmarks menu flickered sometimes when I moved the cursor over another folder with widget.wayland.use-move-to-rect = false which didn't happen with widget.wayland.use-move-to-rect = true.

The contents of bookmarks folders in folders in folders haven't appeared at all since 106.0a1 (2022-9-8) 20220908213354 with widget.wayland.use-move-to-rect = true. The highlighting of bookmarks under the cursor only lasted up to about a second for folders in folders since that build as well which still seemed to happen when I set widget.wayland.use-move-to-rect to false. Bookmarks used to remain highlighted as long as they were under the cursor.

Summary: The contents of bookmarks folders within folders are moved to the left over top of the folder menu and the folders' contents stopped being shown with Firefox Nightly 106.0a1 (2022-9-8) → The contents of bookmarks folders within folders are moved to the left overtop of the folder menu and the folders' contents stopped being shown with Firefox Nightly 106.0a1 (2022-9-8) on Wayland

Thanks, will look at it. I suspect Bug 1789581 handles it but let's check it.

Flags: needinfo?(stransky)

Tooltips didn't appear when I had the cursor over bookmarks in folders within folders in 106.0a1 20220916213956 and 20220908213354 on Wayland, but they did appear for them in 106.0a1 20220908092810. Tooltips were shown to the left of where they usually were when the cursor was over bookmarks in folders which weren't in other folders with 106.0a1 20220916213956 on Wayland. I guess this tooltip problem is related to those I reported here before. The patches for Bug 1789581 haven't been pushed yet, but I'll note here if they fixed this problem when they are.

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

Thanks, will look at it. I suspect Bug 1789581 handles it but let's check it.

Doesn't fix the problems with nested subfolders of the bookmark toolbar for me. :-(

Matt: Bug 1789581 caused a crash if you have widget.wayland.use-move-to-rect set to false. If you get stuck in a startup crash, you can edit the prefs.js in the profile directory to change the value to true to stop crashing.

The contents of bookmarks folders in folders still appeared to the left of their normal positions with 107.0a1 20220919155806 on Wayland in Plasma 5.25.5 which has the patches for patches for Bug 1789581. However, such contents are shown higher on the screen than they had been since 106.0a1 20220908213354, so that they aren't cut off by the bottom of the screen any longer as I reported in comment 2. The contents of bookmarks folders in folders have kept appearing and Firefox hasn't become unresponsive when I've moved the cursor over multiple folders in folders many times as in comment 2, so that problem appears to be fixed. The bookmarks in folders in folders in folders have appeared each time I've moved the cursor over them with 107.0a1 20220919155806 though their position is to the left of normal and sometimes higher than normal.

Tooltips are only shown for about a second with the cursor over bookmarks which aren't in other folders so it's hard to read them, and such bookmarks only remained highlighted for that long which is new with 107.0a1 20220919155806. Tooltips didn't appear when the cursor was over bookmarks in folders in folders (in folders), and such bookmarks only remained highlighted for about a second with 107.0a1 20220919155806 (as in comment 9). I did this testing with widget.wayland.use-move-to-rect = true, so I didn't see the crash that Bob mentioned in comment 11. Thanks.

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

See Also: → 1791933
See Also: → 1791492
Flags: needinfo?(stransky)
Keywords: leave-open
Priority: -- → P2
Assignee: nobody → stransky
Status: NEW → ASSIGNED

Patch from Bug 1788910 which causes this regression is wrong, we need to choose different approach.

We need to backport it to 106 line in order to show popups on Wayland.

Attachment #9295760 - Attachment description: Bug 1789956 [Wayland] Place popup according of first popup parent r?emilio → Bug 1789956 [Wayland] Use mBounds to get parent popup position r?emilio

move-to-rect offset does not work realibly in mutter and can lead to invisible window.
It's used mainly for tooltips so let's skip it for now.

Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/0f7147ac9b32
[Wayland] Use mBounds to get parent popup position r=emilio
Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/5abef032e22b
[Wayland] Don't use move-to-rect offset for non-adjacent popups r=emilio
Regressions: 1792125

Contents of bookmarks folders appeared in their correct positions to the right of their folders popups again with 107.0a1 20220922214429. Tooltips were shown normally below the cursor and remained visible and bookmarks were highlighted as long as the cursor was over the bookmark in 107.0a1 20220922214429. The contents of nested folders were all shown properly and Firefox remained responsive in 107.0a1 20220922214429. Right-clicking on bookmarks folders showed the popup menus to the right and down from their normal position and the contents of bookmarks folders sometimes remained visible after moving the cursor away from them. I bisected this problem to the following patch for this bug.
5abef032e22b7ea23e707fc12baf697f2b7bb2a5 stransky — Bug 1789956 [Wayland] Don't use move-to-rect offset for non-adjacent popups r=emilio

I reported the new problem with context menus when right-clicking on bookmarks folders and their contents sometimes remaining visible at Bug 1792125

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(stransky)
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch

Comment on attachment 9295760 [details]
Bug 1789956 [Wayland] Use mBounds to get parent popup position r?emilio

Beta/Release Uplift Approval Request

  • User impact if declined: Broken popups on Wayland.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): We're reverting recursive popup position lookup and use only parent popup position as we have before.
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(stransky)
Attachment #9295760 - Flags: approval-mozilla-beta?
Attachment #9295783 - Flags: approval-mozilla-beta?
No longer regressions: 1792125

I wondered if any of these were dupes:
1787788
1749552
1725525

Comment on attachment 9295783 [details]
Bug 1789956 [Wayland] Don't use move-to-rect offset for non-adjacent popups r?emilio

Martin, this revision does not graft cleanly to the beta branch, could you provide an updated patch please? Thanks

Flags: needinfo?(stransky)
Attachment #9295783 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Flags: needinfo?(stransky)
Attachment #9295760 - Flags: approval-mozilla-beta?

Comment on attachment 9296970 [details]
Bug 1789956 [Wayland] Use mBounds to get parent popup position (for 106.0) r?emilio

Beta/Release Uplift Approval Request

  • User impact if declined: Missing popups on Wayland.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Run on Wayland, open various menus & context menus.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Revert broken commit.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9296970 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9296970 [details]
Bug 1789956 [Wayland] Use mBounds to get parent popup position (for 106.0) r?emilio

Approved for 106.0b8, thanks.

Attachment #9296970 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Reproduced the issue on Firefox 106.0a1 (2022-09-09) by following the info from Comment 4 under Ubuntu 22.04 Wayland session.

The issue is fixed on 107.0a1 (2022-10-05) and looked over 106.0b8 to make sure it behaves as expected under the same system as above.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: