[Wayland] Nightly gets into an state where tabs paint correctly, but the parent process doesn't tick
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
This looks somewhat similar to the issue reported by QA in bug 1796534, and seems somewhat hard to reproduce. It seems like a recent regression.
I managed to get my nightly in such state and managed to take a profile by virtue of switching windows: https://share.firefox.dev/3Tg6bzf
FWIW the occlusion / throttling stuff wasn't at play. The profiler markers seem to indicate that we're waiting for a transaction that never finished or so ("RefreshDriverTick waiting for paint")
|
||
Comment 1•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #0)
This looks somewhat similar to the issue reported by QA in bug 1796534, and seems somewhat hard to reproduce. It seems like a recent regression.
I managed to get my nightly in such state and managed to take a profile by virtue of switching windows: https://share.firefox.dev/3Tg6bzf
FWIW the occlusion / throttling stuff wasn't at play. The profiler markers seem to indicate that we're waiting for a transaction that never finished or so ("RefreshDriverTick waiting for paint")
That can be caused by any pending painting of popup created by chrome (UI). From my testing all popups spawned by UI use the same PresShell so they share refresh driver. If any such popup is incorrectly closed (for instance some rendering is pending but we can't paint because missing wl_surface etc.) it blocks shared refresh driver and whole UI is blocked.
This can be easily reproduced by pausing compositor when popup is hidden - any pending transactions will be kept in queue and may block it.
|
Reporter | |
Comment 2•3 years ago
|
||
This particular case was bug 1796392. But we maybe should do a bit better here to prevent getting stuck in this state...
Description
•