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)
Tracking
()
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)
5.77 MB,
video/mp4
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
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.
Updated•2 years ago
|
Comment 1•2 years ago
|
||
: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.
Reporter | ||
Comment 2•2 years ago
|
||
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.
Assignee | ||
Comment 3•2 years ago
|
||
Can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 4•2 years ago
|
||
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.
Comment 5•2 years ago
|
||
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.
Comment 6•2 years ago
|
||
Set release status flags based on info from the regressing bug 1788910
Reporter | ||
Comment 7•2 years ago
|
||
(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.
Assignee | ||
Comment 8•2 years ago
|
||
Thanks, will look at it. I suspect Bug 1789581 handles it but let's check it.
Reporter | ||
Comment 9•2 years ago
|
||
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.
Comment 10•2 years ago
|
||
(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. :-(
Comment 11•2 years ago
|
||
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.
Reporter | ||
Comment 12•2 years ago
|
||
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.
Comment 13•2 years ago
|
||
Set release status flags based on info from the regressing bug 1788910
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 14•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Patch from Bug 1788910 which causes this regression is wrong, we need to choose different approach.
Assignee | ||
Comment 16•2 years ago
|
||
We need to backport it to 106 line in order to show popups on Wayland.
Updated•2 years ago
|
Assignee | ||
Comment 18•2 years ago
|
||
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.
Comment 19•2 years ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/0f7147ac9b32 [Wayland] Use mBounds to get parent popup position r=emilio
Comment 20•2 years ago
|
||
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
Comment 21•2 years ago
|
||
bugherder |
Reporter | ||
Comment 22•2 years ago
|
||
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
Reporter | ||
Comment 23•2 years ago
|
||
I reported the new problem with context menus when right-clicking on bookmarks folders and their contents sometimes remaining visible at Bug 1792125
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 24•2 years ago
|
||
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
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 26•2 years ago
|
||
Updated https://gitlab.gnome.org/GNOME/mutter/-/issues/2408 for it.
Comment 27•2 years ago
|
||
I wondered if any of these were dupes:
1787788
1749552
1725525
Comment 28•2 years ago
|
||
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
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 29•2 years ago
|
||
Assignee | ||
Comment 30•2 years ago
|
||
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
Assignee | ||
Updated•2 years ago
|
Comment 31•2 years ago
|
||
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.
Comment 32•2 years ago
|
||
bugherder uplift |
Updated•2 years ago
|
Comment 34•2 years ago
|
||
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.
Description
•