sway: Popups in firefox >= 92.0b2 are broken with scale != 1

Firefox 93 will fix that for old Gtk versions.

Resolved by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3941.

It would probably work.

Here’s a revived patch w/ Carlos’s NULL buffer approach, since for some reason just cherry-picking it caused conflicts.

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3898

and with this I can no longer reproduce.

Feel free to test. I’m waiting for logs from #6147 folks to understand how this manifests on multi-output setups, cause I’m pretty sure they’re the same.

EDIT: patch -> link

Do you object to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3898 ? That is my proposed solution.

It looks fine to me.

@stransky sway doesn’t respond to the callback because the surface is destroyed.

Here is logging typical of a failed popup on scale != 1:

[Parent 43945: Main Thread]: D/WidgetWayland moz_container_wayland_map_event [7facfc555f50]
[Parent 43945: Main Thread]: D/WidgetWayland moz_container_wayland_surface_create_locked [7facfc555f50]
[Parent 43945: Main Thread]: D/WidgetWayland     gtk wl_surface 7facf3f6f600 ID 120
[882711.198]  -> wl_compositor@35.create_surface(new id wl_surface@123)
[882711.222]  -> wl_subcompositor@36.get_subsurface(new id wl_subsurface@124, wl_surface@123, wl_surface@120)
[882711.235]  -> wl_subsurface@124.set_desync()
[882711.247]  -> wl_surface@120.frame(new id wl_callback@125)
[Parent 43945: Main Thread]: D/WidgetWayland     created frame callback ID 125
[882711.264]  -> wl_surface@123.commit()
[Parent 43945: Main Thread]: D/WidgetWayland     created surface 7facf2c84330 ID 123
[Parent 43945: Main Thread]: D/WidgetWayland moz_container_wayland_set_scale_factor_locked [7facfc555f50] scale 2
[882711.335]  -> wl_surface@123.set_buffer_scale(2)
[882711.346]  -> wl_compositor@35.create_region(new id wl_region@126)
[882711.356]  -> wl_surface@123.set_input_region(wl_region@126)
[882711.365]  -> wl_region@126.destroy()
[Parent 43945: Main Thread]: D/WidgetWayland moz_container_wayland_invalidate [7facfc555f50]
[Parent 43945: Main Thread]: D/WidgetPopup nsWindow::OnWindowStateEvent [7facf3fa6800] for 7facf3fa5660 changed 0x1 new_window_state 0x80
[Parent 43945: Main Thread]: D/WidgetPopup 	early return because no interesting bits changed
[Parent 43945: Main Thread]: D/WidgetPopup nsWindow::OnWindowStateEvent [7facf3fa6800] for 7facfc555f50 changed 0x1 new_window_state 0x80
[Parent 43945: Main Thread]: D/WidgetPopup 	quick return because IS_MOZ_CONTAINER(aWidget) is true
[882711.796] wl_surface@120.enter(wl_output@31)
Gdk-Message: 12:53:29.589: surface enter, window 0x7facf6917640 output 0x7fad19cd1150
[882711.885] wl_surface@120.enter(wl_output@17)
Gdk-Message: 12:53:29.589: surface enter, window 0x7facf6917640 output 0x7fad2c6f5830
[882711.960]  -> xdg_popup@118.destroy()
[882711.972]  -> xdg_surface@101.destroy()
[882711.989]  -> wl_surface@120.destroy()
[...]
[882713.773] wl_display@1.delete_id(125) # callback is destroyed b/c the surface for this callback has been destroyed
[...]
[Parent 43945: Renderer]: D/WidgetWayland WindowSurfaceWaylandMB::Commit [7facf2c94c10] frame queued: can't lock wl_surface

In this case the popup was atually killed before the frame event was even commited (is this a typo? FF immediately commits the subsurface & flushes the display after requesting a callback on the parent). At the time firefox complains about not being able to obtain the container lock, the frame handler that’s supposed to unlock it is waiting for a callback that doesn’t exist.

The frame is requested here: https://searchfox.org/mozilla-central/source/widget/gtk/MozContainerWayland.cpp#527

The surface is destroyed by gtk in gdk_wayland_window_hide_surface here: https://gitlab.gnome.org/GNOME/gtk/-/blob/d4e2d05cd9518ba04d6fbe1cbcec27142788ac95/gdk/wayland/gdkwindow-wayland.c#L3396

The enter event triggers it in gtk via surface_enter -> window_update_scale -> gdk_wayland_window_maybe_configure -> gdk_window_hide: https://gitlab.gnome.org/GNOME/gtk/-/blob/d4e2d05cd9518ba04d6fbe1cbcec27142788ac95/gdk/wayland/gdkwindow-wayland.c#L1227

is this related to my issue with bitwarden’s folder selection breaking the parent popup?

demo: https://user-images.githubusercontent.com/82718618/189556171-bc2c2961-76aa-4f65-946a-1724397cc89c.mp4

There’s another scale ‘fix’ for scale & popups which landed in Nightly (FF95): https://bugzilla.mozilla.org/show_bug.cgi?id=1735095

@stransky since gtk!3898 is rejected, I created https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3941 to fix the gdk bug with handling firefox’s duplicate wl_outputs so that it doesn’t loop. That should make it possible in principle to correct this behavior by doing as jadahl suggests.

I’d still like gdk to be capable of handling pre-map enter events correctly, but it will require a different approach.

I have either this issue or one very close on Firefox 91.0 and Sway 1.6.1-1 (Arch Linux).

No scaling on Sway, but in Firefox with layout.css.devPixelsPerPx set to 1.4 menus from the navigation bar (addons &c.) are invisible but flicker as i move the mouse over them. Setting the property to 1.39 instead leads to stable addon menus, but the bookmarks menu remaining unusable. If i then set the Sway scale to something other than 1, the bookmark menu works, but not the addon menus (the Firefox scale shrinks too for some reason).

Firefox Nightly 92.0a1.20210718212857+ha95d4908bc83-1 behaves the same, as does sway-git r6607.28cadf55-1 (Arch Linux).

Not fixed on freshly-built AUR packages on scale 1.5:

• sway-hidpi-git r6741.f67ed677-1
• wlroots-hidpi-git 0.14.0.r143.gad7651a3-1
• firefox-nightly-en-gb 93.0a1.20210812.092607-1

(hidpi is for hidpi xwayland support.)

Symptoms are identical. Returning once again to firefox-nightly-en-gb 92.0a1.20210719.215029-1, probably the last version which works properly.