Right-clicking on bookmarks folders shows content popup menu on wrong position
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox105 | --- | unaffected |
| firefox106 | --- | unaffected |
| firefox107 | --- | verified |
People
(Reporter: matt.fagnani, Assigned: stransky)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Crash Data
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0
Steps to reproduce:
I started Firefox Nightly 107.0a1 20220922214429 on Wayland with WebRender compositing in Plasma 5.25.5 on Wayland in a Fedora 37 KDE Plasma installation.
I had enabled the Menu bar previously. I selected Bookmarks in the Menu bar. I moved the cursor over various bookmarks folders and right-clicked on the folders. Some of the folders were nested in other folders.
Actual results:
Right-clicking on bookmarks folders showed the popup context menus to the right and down from their normal position around the cursor. The context menus were often about 2-3 folder widths to the right of the cursor. If the bookmarks folder I right-clicked on was low on the screen, the popup menus sometimes didn't appear possibly because their positions would have been off the of screen. The contents of the bookmarks folders I right-clicked on sometimes remained visible after moving the cursor away from them or selecting other folders.
This problem started with Firefox Nightly 107.0a1 20220922214429 on Wayland. 107.0a1 20220922095647 either showed the context menus in the expected position around the cursor particularly with nonnested folders or to the left and up from the cursor possibly related to Bug 1789956. I ran mozregression --good c9041757a18ac481d701af85012d9c7c9720db7a --bad 20220922214429 -p ~/.mozilla/firefox/z8d4nvrc.default-nightly --profile-persistence reuse --persist /tmp/mozregression
c9041757a18ac481d701af85012d9c7c9720db7a is the changeset for 20220922095647 which I used with --good because otherwise mozregression usually would select 20220922214429 for good and bad builds
12:11.47 INFO: No more integration revisions, bisection finished.
12:11.47 INFO: Last good revision: 241153d66020c229d49298af1a7d2b46ad83f143
12:11.47 INFO: First bad revision: 5abef032e22b7ea23e707fc12baf697f2b7bb2a5
12:11.47 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=241153d66020c229d49298af1a7d2b46ad83f143&tochange=5abef032e22b7ea23e707fc12baf697f2b7bb2a5
The bisection finished with the first bad revision as the following from Bug 1789956 for Wayland popups.
5abef032e22b7ea23e707fc12baf697f2b7bb2a5 stransky — Bug 1789956 [Wayland] Don't use move-to-rect offset for non-adjacent popups r=emilio
Expected results:
The context menu popups when right-clicking on bookmarks folders would appear in their normal position around the cursor. The contents of the bookmarks folders that were right-clicked wouldn't sometimes remain on the screen after moving the cursor off of them or selecting other folders.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
:stransky, since you are the author of the regressor, bug 1789956, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
| Assignee | ||
Comment 2•3 years ago
|
||
Can you please create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.
Updated•3 years ago
|
| Reporter | ||
Comment 3•3 years ago
|
||
I'm attaching a recording with 107.0a1 (2022-09-23) on Wayland showing problems when right-clicking on bookmarks folders. In Firefox Nightly Resources folder, I made three test folders with 2 of the default Nightly bookmarks. When I right-clicked on some of the folders, the context menu was shown to the right and down from the cursor. The contents of Testing folder 3 with Nightly Tester Tools in it was also shown down and to the right and remained after moving the cursor away. The Testing folder 1 contents with Mozilla Bug Tracker remained in the normal position after selecting the Testing folder 3 which was shown down and to the right again. Thanks.
I'm experiencing the exact same issue with Firefox Wayland under KDE Plasma.
But I disagree with regression range. Testing with mozregression, what messed up with contextmenu positioning was the patch from bug 1785185.
Despite having confirmed that issue is still present in latest Nightly, I noticed it in Developer Edition 106.0b4 which is my main browser. The bug currently referenced as "regressed by" (bug 1789956) is a patch landed only in v107, so it can't be that.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 5•3 years ago
|
||
This is not a regression. The context menu just didn't work before - it was ignored.
| Assignee | ||
Comment 6•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #5)
This is not a regression. The context menu just didn't work before - it was ignored.
Correction: It worked randomly, at least I see random errors on 105.0.1.
| Assignee | ||
Comment 7•3 years ago
|
||
Wne context menu is positioned by plain move, we need relative popup coordinates. So calculate them according to context menu parent popup.
Updated•3 years ago
|
| Assignee | ||
Comment 8•3 years ago
|
||
There are two bugs here - context menu is opened on wrong position and another (not related) menu is opened on top of it.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 9•3 years ago
|
||
Another incarnation of this bug - missing child popup of content menu.
| Assignee | ||
Comment 10•3 years ago
|
||
We can't use move-to-rect if there are more parents of wl_subsurface popups types.
It's because wl_subsurface is ignored by xgd_popup (created by move-to-rect) so our popup scenario:
toplevel -> xgd_popup(1) -> wl_subsurface(2) -> xgd_popup(3)
looks for Wayland compositor as:
toplevel -> xgd_popup(1) -> xgd_popup(3)
If xgd_popup(1) and xgd_popup(3) are not adjacent then move-to-rect applied to xgd_popup(3) fails and we get missing popup.
Depends on D158120
| Reporter | ||
Comment 11•3 years ago
|
||
Thanks for the patches and explanation. The bisection I did was just for the context menus appearing down and to the right of the cursor which started for me with Firefox Nightly 107.0a1 20220922214429 on Wayland and what was I bisected to 5abef032e22b7ea23e707fc12baf697f2b7bb2a5 stransky — Bug 1789956 [Wayland] Don't use move-to-rect offset for non-adjacent popups, and it wasn't for the context menus being in the wrong position in general. The context menus before that were sometimes in the correct position or were up and to the left of the cursor as I explained in my report in the line: 107.0a1 20220922095647 either showed the context menus in the expected position around the cursor particularly with nonnested folders or to the left and up from the cursor possibly related to Bug 1789956. Bug 1789956 which I first saw with 106.0a1 (2022-9-8) 20220908213354 sometimes making the context menus for bookmarks folders being shown up and to the left of the cursor might be why 106.0b4 was noted to be affected in comment 4.
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/62f18f6188d2
https://hg.mozilla.org/mozilla-central/rev/92dd32e7297d
Updated•3 years ago
|
| Reporter | ||
Comment 16•3 years ago
|
||
These problems are happening for me with 106.0.1 on Wayland in Plasma 5.26.1 in a Fedora 37 KDE Plasma installation. Right-clicking on a bookmark folder showed the context menus down and to the right or not at all. The contents of a bookmark folder sometimes remained on the screen after right-clicking on a bookmark folder then moving the cursor over another folder. Should the patches be backported to the 106 branch? Thanks.
| Assignee | ||
Comment 17•3 years ago
|
||
(In reply to Matt Fagnani from comment #16)
screen after right-clicking on a bookmark folder then moving the cursor over another folder. Should the patches be backported to the 106 branch?
Too late for backport, we uplift patches to Beta. Already released versions get only critical fixes like crashes/major breakages.
Comment 18•3 years ago
|
||
Setting Regressed by field after analyzing regression range found by mozregression in comment #0.
Comment 19•3 years ago
|
||
I was able to reproduce the issue from description on Ubuntu 20.04(using Wayland)/Fedora Linux 36 using build 107.0a1(20220922214429).
Verified as fixed on Ubuntu 20.04/Fedora Linux 36 using Beta 107.0 (20221110173214). Also verified as fixed on Win10x64 using beta 107.0 (20221110173214).
Description
•