-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[firefox] GTK popups such as tooltips/context menus flicker on surface commit #4191
Comments
Can you update the Firefox issue to make it clear it's sway specific and likely a sway bug? The WAYLAND_DEBUG trace looks good to me. I believe this is a damage issue. |
Added link to this issue from the Firefox bug report, and mentioned that it only seems to reproduce in Sway out of the 4 compositors I tested. |
The post-bug surface creation is very busy, but so far the only difference I have been able to isolate is that the new code utilizes xdg_popup. Snippet:
|
What do you mean? My bet would be that this is not a protocol issue, but just a sway internal rendering issue. |
I also believe that to be the case. Due to not being very familiar with sway/wlroots codebases, I took a quite generic debugging approach: Attempting to trace sway/wlroots behavior between the working and non-working Firefox revisions to locate what difference there may be between the working and non-working surfaces. The commit/damage part of the two revisions appeared fairly identical to me (including some fprintf debug in sway and wlroots), so my train of thought made me assume that whatever difference there may be, including damage issues on render, would originate from surface configuration. That the broken revision utilizes xdg_popup surfaces could be such a difference. Still digging around, though. |
The problem is subsurfaces of popups. Firefox creates an xdg_popup with an xdg_positioner whose anchor_rect is set to the desired position. The result of this is a view child in sway, whose root coords is correctly calculated by popup_get_root_coords, the get_root_coords implementation assigned to the view child. Then, firefox creates a subsurface on this xdg_popup through view_child_handle_surface_new_subsurface. This subsurface does not end up having a handle to the view child of the parent, and utilizes its own get_root_coords implementation which takes its own view child, and any parent subsurfaces into account. The result is that the subsurface does not take surface->popup->geometry of the parent into account, which is the geometry containing the popup offset, resulting in a 0,0 root for the subsurface. We need to get a hold of get_root_coords of the parent view child. I made a quick test where a view child can optionally store a pointer to its parent, so that subsurface_get_root_coords can call the parents' root coords implementation, and that did indeed solve the issue. It also segfaults like crazy, likely due to the parent being destroyed before a call to subsurface_get_root_coords, but it was a test. |
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes #4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes #4191.
Subsurfaces need access to the parent get_root_coords impl for positioning in popups. To do this, we store a reference to the parent view_child where applicable. Fixes swaywm#4191.
Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1548496
Some Firefox "popup" surfaces (context menus, tooltips, plugin popups) toggle between visible and invisible for every surface commit. The easiest way to reproduce is to open a context menu with right flick a few times, and then move the cursor around, with every pixel moved causing the state to toggle for some surfaces. It can sometimes take a few tries.
The issue was introduced when Firefox changed its popup handling to create windows with GDK_WINDOW_TYPE_HINT_POPUP_MENU on Wayland, calling gtk_window_set_transient_for to assign the popup to its parent. Before, it used for wayland GDK_WINDOW_TYPE_HINT_UTILITY. The change was introduced in response to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1532643, by this patch: https://phabricator.services.mozilla.com/D26112.
Tests:
WAYLAND_DEBUG for firefox, opening a context menu, moving the cursor while observing flicker, and then leaving the window:
The text was updated successfully, but these errors were encountered: