[Wayland] Hamburger menu is sometimes cropped at the bottom
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox89 | --- | unaffected |
| firefox90 | --- | unaffected |
| firefox91 | --- | fixed |
| firefox92 | --- | fixed |
People
(Reporter: viktor_jaegerskuepper, Assigned: rmader)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
cropped hamburger menu
OS: Arch Linux
Graphics: AMD Caicos with Mesa 21.1.2 (r600 driver)
Compositing: WebRender (with default settings)
When I click on the hamburger menu button, the menu is sometimes cropped so that a part at the bottom is not displayed. When I move the mouse pointer around, the missing part is displayed after some time (not sure what triggers this). When I hover the mouse pointer to the area where the menu part is missing, the missing part is displayed immediately.
To reproduce the bug, I often have to click on the menu button repeatedly or I even have to close Firefox and start it again (sometimes several times in a row) if I can't reproduce the bug by repeated clicking on the menu button. I did this when I used mozregression.
Mozregression gave the following result:
Last good revision: e3ed4267a8743011e49b79fd56eefe6405b192d3
First bad revision: d39eb2d0e9d8683356d71b7c2d19fbeda54c3616
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e3ed4267a8743011e49b79fd56eefe6405b192d3&tochange=d39eb2d0e9d8683356d71b7c2d19fbeda54c3616
This points to bug 1713686.
If you want to use mozregression to confirm this, be aware that I got several crashing builds after I had reached the following regression window:
Newest known good integration revision: 1fb3d75a2240e9f22bb082de76620ce4919e8efd
Oldest known bad integration revision: d70c3d846c395717c429cd3f3433457f5f92dced
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1fb3d75a2240e9f22bb082de76620ce4919e8efd&tochange=d70c3d846c395717c429cd3f3433457f5f92dced
Interestingly, with XWayland (with and without EGL) I often see a kind of "flashing" for a tiny fraction of a second at the same area (where the part of the menu is missing with Wayland) when I click on the hamburger menu button. I don't see this with X11. I didn't report this because it's hardly visible, but now I wonder if both issues are related. Maybe on XWayland the menu is cropped at the beginning and some milliseconds later the missing part is displayed?
|
Reporter | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 1•3 years ago
|
||
Bug 1713686 reduced overdraw that in theory should not be necessary on Wayland. Assuming it does so correctly, it may uncover other bugs. Can you check if you can reproduce the issue when enabling widget.wayland.multi-buffer-software-backend.enabled?
|
|
Reporter | |
Comment 2•3 years ago
|
||
I can't reproduce the issue with widget.wayland.multi-buffer-software-backend.enabled enabled.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 3•3 years ago
|
||
I can also reproduce the bug with Software-WebRender and with llvmpipe (using LIBGL_ALWAYS_SOFTWARE=1), in which case I get Software-WebRender by default.
|
||
Comment 4•3 years ago
|
||
Robert what's the next step given the extra info from Viktor?
|
|
Assignee | |
Comment 5•3 years ago
|
||
(In reply to Viktor Jägersküpper from comment #3)
I can also reproduce the bug with Software-WebRender and with llvmpipe (using
LIBGL_ALWAYS_SOFTWARE=1), in which case I get Software-WebRender by default.
Yeah, the menu always uses SW-WR. It's apparently faster for such cases.
(In reply to Julien Cristau [:jcristau] from comment #4)
Robert what's the next step given the extra info from Viktor?
If we don't find another solution, I'd suggest to wait for branching and then bail out bug 1713686 from beta/91. Because once the 92 cycle begins we want to enable widget.wayland.multi-buffer-software-backend.enabled by default. Alternatively, we can bail out bug 1713686 now and reland it in 92.
|
|
Assignee | |
Comment 6•3 years ago
|
||
As it gives us better guarantees about correctness, it allows us to enable
performance optimizations such as D118192, which reduces redraws.
Another advantage is that it does not need any extra knowledge about
compositors as it does not make any assumptions about buffer holding
behaviour.
|
||
Updated•3 years ago
|
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/3685f5b1d3f6 Enable Wayland multi-buffer software backend by default, r=stransky
|
||
Comment 8•3 years ago
|
||
| bugherder | ||
|
||
Comment 9•3 years ago
|
||
Fixed in 91 with the backout of bug 1713686 on the beta branch.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 11•3 years ago
|
||
This has just happened again (only once), but I can't reproduce it.
Robert, are there any recent changes (during the last weeks) that could have caused this? I'm using Wayland+WebRender, DE is Gnome Shell 40.4 with Mesa 21.2.1 (r600 driver, AMD Caicos) on Arch Linux. I am not using the WebRender-Compositor for Wayland (yet).
(In reply to Robert Mader [:rmader] from comment #1)
Bug 1713686 reduced overdraw that in theory should not be necessary on Wayland. Assuming it does so correctly, it may uncover other bugs.
What kind of bugs were you thinking of? If this gets worse, I can try to investigate further if I have some hints.
Can you check if you can reproduce the issue when enabling
widget.wayland.multi-buffer-software-backend.enabled?
I saw that the old backend was removed last week, so I suppose it can't be that.
Anyways, if this doesn't get worse, don't worry about it.
|
|
Assignee | |
Comment 12•3 years ago
•
|
||
Robert, are there any recent changes (during the last weeks) that could have caused this? I'm using Wayland+WebRender, DE is Gnome Shell 40.4 with Mesa 21.2.1 (r600 driver, AMD Caicos) on Arch Linux. I am not using the WebRender-Compositor for Wayland (yet).
Not anything I'm aware of, but the popup code on Wayland unfortunately is quite complex and there were a lot of changes to it lately that are potential candidates.
What kind of bugs were you thinking of? If this gets worse, I can try to investigate further if I have some hints.
Any glitches in places where we use RenderCompositorSWGL. I.e. everywhere if you enable gfx.webrender.software but not the compositor backend. All that the patch in that bug did was that we do way less theoretically unnecessary redraws. But these redraws might have papered over unrelated bugs. The usual trajectory of optimizations :(
I saw that the old backend was removed last week, so I suppose it can't be that.
Yeah, by now it's the default (again as long as the compositor backend is not used).
Anyways, if this doesn't get worse, don't worry about it.
Ok, thanks for the update!
|
|
Reporter | |
Comment 13•3 years ago
|
||
I investigated a bit further and it seems to me that the hamburger menu can be cropped only when it is opened for the first time during a session. Furthermore I managed to keep the menu cropped two times by "insanely" repeatedly clicking on the menu button without moving the mouse. But the good news is that the menu was cropped in only 1 out of 20 tries at most.
Using the multi-buffer backend, I tested the "first bad" autoland build with the patch that uncovered this bug (changeset d39eb2d0e9d8683356d71b7c2d19fbeda54c3616) and found that it behaves the same way as the current Nightly. So the underlying bug was just hidden by the former unoptimized behaviour as Robert suspected.
Description
•