[wayland] Contents of folders in Bookmarks Toolbar which require scrolling don't appear
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox87 | --- | fixed |
People
(Reporter: kevin, Assigned: jhorak)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
On Wayland (with MOZ_ENABLE_WAYLAND=1 in the environment) since Firefox 77, the contents of a folder in the Bookmarks Toolbar do not appear if the folder contains enough items that it would require scrolling. Clicking the folder darkens it (to indicate it is active), but no items appear below it.
The issue is present in 79.0a1 (2020-06-07) (64-bit) and was not present in 76.0.1. mozregression narrowed it down to:
Last good revision: 109871b2551e8e28dfa311bced65057542c91388
First bad revision: 69ca1d06f46ad976113938e6dfccfeb7315ee7a6
Pushlog: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=109871b2551e8e28dfa311bced65057542c91388&tochange=69ca1d06f46ad976113938e6dfccfeb7315ee7a6
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Can you please check latest nightly if you see the problem?
Thanks.
Reporter | ||
Comment 3•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #2)
Can you please check latest nightly if you see the problem?
In addition to 79.0a1 (2020-06-07) (64-bit) from the original post, I can confirm that the issue is still present in 79.0a1 (2020-06-09) (64-bit) downloaded a few minutes ago.
Assignee | ||
Comment 4•4 years ago
|
||
We need to trigger popupFrame->SetPopupPosition when we get size change from the Wayland popup
positioner - ie. window does not fit the screen. That will ensure that the
popup is cropped to fit the screen.
This patch also keeps the NativeMoveResizeWaylandPopupCallback connected to make sure
that the subsequent nsWindow::Show calls places the window correctly (when for
example the main window is moved to the screen edge - the menus can be flipped - and
we need to update the nsView for that to ensure the submenus are correctly placed.
We also use anchorRectAppUnits.ToNearestPixels to partially mirror behaviour of
nsView::CalcWidgetBounds.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
bugherder |
Reporter | ||
Comment 7•4 years ago
|
||
Many thanks for working on this issue! Unfortunately, I am still able to reproduce the issue using 88.0a1 (2021-03-02) (64-bit). Can you confirm that it is fixed?
Perhaps the remaining issue is window manager-specific? I'm using sway, but could test with GNOME or KDE if it may be relevant.
Comment 8•4 years ago
|
||
(In reply to Kevin Locke from comment #7)
Many thanks for working on this issue! Unfortunately, I am still able to reproduce the issue using 88.0a1 (2021-03-02) (64-bit). Can you confirm that it is fixed?
Perhaps the remaining issue is window manager-specific? I'm using sway, but could test with GNOME or KDE if it may be relevant.
Please test with Gnome too. We need to check if it's Sway specific or not.
Thanks.
Reporter | ||
Comment 9•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #8)
Please test with Gnome too. We need to check if it's Sway specific or not.
I am not able to reproduce the issue using GNOME (from the Debian 10.8 Live CD). It appears to be sway-specific.
While testing, I came across Bug 1644968, which appears to describe the same issue. Unless there is reason to reopen this bug, I'll plan to watch that one. Thanks again.
Assignee | ||
Comment 10•4 years ago
|
||
Thanks for letting us know. Seems that the bug 1644968 is resolved now on the sway part.
Description
•