[Wayland] Firefox is resized on background
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: stransky, Assigned: stransky)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
Follow up from Bug 1623106.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
It's wayland specific. Firefox is maximized on start:
[2212833.516] xdg_toplevel@47.configure(1920, 1020, array)
[2212833.538] xdg_surface@46.configure(1442)
[2212833.642] -> xdg_surface@46.ack_configure(1442)
but it resized on background then:
[2213074.109] gtk_surface1@48.configure(array)
[2213074.115] gtk_surface1@48.configure_edges(array)
[2213074.121] xdg_toplevel@47.configure(1280, 1057, array)
[2213074.133] xdg_surface@46.configure(1444)
[2213074.147] -> xdg_surface@46.ack_configure(1444)
so it's switched to non-maximized state but we don't know about it because we don't get on state change event.
Assignee | ||
Comment 2•5 years ago
|
||
Robert, any idea why this happens and why? Also why we don't get any info about it? (window state change?)
Assignee | ||
Comment 3•5 years ago
|
||
When this bug does not happen, the log looks like:
[4050349.721] gtk_surface1@48.configure(array)
[4050349.733] gtk_surface1@48.configure_edges(array)
[4050349.743] xdg_toplevel@47.configure(1920, 1020, array)
[4050349.763] xdg_surface@46.configure(1613)
[4050349.806] -> xdg_surface@46.ack_configure(1613)
so looks like configure_edges() detects screen size correctly.
Assignee | ||
Comment 4•5 years ago
|
||
btw. This is Fedora 32 / mutter-3.36.0-1.fc32.x86_64
Comment 5•5 years ago
|
||
Just tested locally and it appears to be similar to what happens in bug 1609538, that is we get a valid config (on my 1920x1080 screen I get 1920x1046), but then we create and commit a buffer smaller than that - of the size we then get on screen:
[181454,493] -> wl_surface@47.frame(new id wl_callback@50)
[181454,580] -> xdg_wm_base@24.get_xdg_surface(new id xdg_surface@51, wl_surface@47)
[181454,599] -> xdg_surface@51.get_toplevel(new id xdg_toplevel@52)
[181454,610] -> xdg_toplevel@52.set_parent(nil)
[181454,619] -> xdg_toplevel@52.set_title("Mozilla Firefox")
[181454,627] -> xdg_toplevel@52.set_maximized()
[181454,652] -> xdg_toplevel@52.set_app_id("firefox")
[181454,661] -> gtk_shell1@15.get_gtk_surface(new id gtk_surface1@53, wl_surface@47)
[181454,677] -> xdg_toplevel@52.set_min_size(511, 67)
[181454,690] -> xdg_toplevel@52.set_max_size(8140, 8140)
[181454,703] -> gtk_surface1@53.unset_modal()
[181454,709] -> wl_surface@47.commit()
[181527,624] wl_display@1.delete_id(42)
[181527,657] wl_display@1.delete_id(46)
[181527,665] xdg_toplevel@52.configure(1920, 1046, array)
[181527,684] xdg_surface@51.configure(366)
[181527,698] -> wl_surface@47.set_buffer_scale(1)
[181527,721] -> xdg_surface@51.ack_configure(366)
[181552,496] -> xdg_toplevel@52.set_min_size(511, 67)
[181552,539] -> xdg_toplevel@52.set_max_size(8140, 8140)
[181552,559] -> wl_surface@47.set_buffer_scale(1)
[181552,633] -> xdg_toplevel@52.set_min_size(563, 119)
[181552,650] -> xdg_toplevel@52.set_max_size(8192, 8192)
[181552,664] -> wl_surface@47.set_buffer_scale(1)
[181606,651] -> wl_shm@5.create_pool(new id wl_shm_pool@46, fd 47, 4016640)
[181606,700] -> wl_shm_pool@46.create_buffer(new id wl_buffer@42, 0, 960, 1046, 3840, 0)
[181608,947] -> wl_surface@47.attach(wl_buffer@42, 0, 0)
[181608,987] -> wl_surface@47.set_buffer_scale(1)
[181608,995] -> wl_surface@47.damage(0, 0, 960, 1046)
[181609,018] -> xdg_toplevel@52.set_min_size(563, 119)
[181609,030] -> xdg_toplevel@52.set_max_size(8192, 8192)
[181609,043] -> xdg_surface@51.set_window_geometry(0, 0, 960, 1046)
[181609,065] -> wl_compositor@4.create_region(new id wl_region@54)
[181609,075] -> wl_region@54.add(-10, -10, 980, 1066)
[181609,096] -> wl_surface@47.set_input_region(wl_region@54)
[181609,105] -> wl_region@54.destroy()
[181609,134] -> wl_surface@47.frame(new id wl_callback@55)
[181609,148] -> wl_surface@47.commit()
Comment 6•5 years ago
|
||
Some thoughts here:
- I can't reproduce this in my local build nor with the official nightly, but I can with FF 74 Fedora version, indicating that it is either fixed (by bug 1623106) or a timing issue.
- as Jonas indicated in bug 1609538, it might be a good idea to make the container subsurface sync on resize - and probably on first commit, too.
- I wonder if Mutter should start letting the app crash if in such situations, just as Weston apparently does now. That would make it easier to catch such issues. Either way we should only do that in 3.38.
Assignee | ||
Comment 7•5 years ago
|
||
Robert, thanks for looking at it. It that's a Firefox bug I'll look at it, perhaps Bug 1623106 isn't enough.
But latest Fedora Firefox 74 builds:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1478931
https://koji.fedoraproject.org/koji/buildinfo?buildID=1478930
do have Bug 1623106 backported and I see the issue there too.
btw. Please do not make Mutter crash, I expect it takes whole gnome-shell session down and it would be very hard to debug it then. Can you for instance put any warning to system/wayland log so it can be diagnosed there?
Thanks.
Comment 8•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #7)
btw. Please do not make Mutter crash, I expect it takes whole gnome-shell session down and it would be very hard to debug it then. Can you for instance put any warning to system/wayland log so it can be diagnosed there?
I meant to kill the app / firefox, not the shell ;)
In case the app did something "illegal" and to make it more clear that it's a client bug.
Comment 9•5 years ago
|
||
P.S.: Just installed the builds you linked above (firefox-74.0-11) and now I can't reproduce the issue any more - I just restarted FF about 30-40 times with different users (my main profile with Webrender enabled and a different user with a fresh profile and basic compositor) and didn't hit it once, while on firefox-74.0-5 it happened ever 2-3 time. So Bug 1623106 apparently at least helped. Also the GS open window animation now works much more often (instead of the window just appearing).
I guess now there's some timing issue left :/
Updated•5 years ago
|
Assignee | ||
Comment 10•5 years ago
|
||
Hi Robert, there's a log from -11 builds (wayland+widget logs). Looks like the surface size isn't still respected, there are the key parts here:
[699834.561] xdg_toplevel@51.configure(1920, 1020, array)
[699834.599] xdg_surface@50.configure(41)
[699834.610] -> wl_surface@46.set_buffer_scale(2)
[699834.628] -> xdg_surface@50.ack_configure(41)
[699918.718] -> wl_shm@5.create_pool(new id wl_shm_pool@62, fd 82, 15667200)
[699918.740] -> wl_shm_pool@62.create_buffer(new id wl_buffer@63, 0, 1920, 2040, 7680, 0)
[Parent 6655: Main Thread]: D/Widget GetScreenBounds [0x7f745f14d800] 0,0 -> 1920 x 2040, unscaled 0,0 -> 960 x 1020
[699927.159] -> wl_surface@46.attach(wl_buffer@63, 0, 0)
[699927.177] -> wl_surface@46.set_buffer_scale(2)
[699927.184] -> wl_surface@46.damage(0, 0, 960, 1020)
[699927.200] -> xdg_toplevel@51.set_min_size(450, 95)
[699927.209] -> xdg_toplevel@51.set_max_size(16383, 16383)
[699927.218] -> xdg_surface@50.set_window_geometry(0, 0, 960, 1020)
[Parent 6655: Main Thread]: D/Widget configure event [0x7f745f14d800] 0 0 960 1020
[Parent 6655: Main Thread]: D/Widget GetScreenBounds [0x7f745f14d800] 0,0 -> 3944 x 2144, unscaled 0,0 -> 1972 x 1072
[Parent 6655: Main Thread]: D/Widget moz_container_size_allocate [0x7f7461008230] 0,0 -> 960 x 1020
[Parent 6655: Main Thread]: D/Widget nsWindow::OnSizeAllocate [0x7f745f14d800] 0,0 -> 960 x 1020
So looks like there's bug with surface size (acked 1920, 1020, set 1920, 2040) and also mixed scale factor settings (1920, 2040 transfered back as 960, 1020).
Not that I use scale factor 2 on my monitor.
Comment 11•5 years ago
|
||
The scale part looks consistent to me (surface size 960x1020, buffer size 1920x2040, buffer scale 2) - it just should be 1920x1020,3840x2040,2
Assignee | ||
Comment 12•5 years ago
|
||
Downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1815127
Assignee | ||
Comment 13•5 years ago
|
||
Robert, is it correct when wl_subsurface has a different size than wl_surface or not?
Thanks.
Comment 14•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #13)
Robert, is it correct when wl_subsurface has a different size than wl_surface or not?
Thanks.
A subsurface can have a different size than its parent, yes.
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subsurface:
A sub-surface's size and position are not limited to that of the parent. Particularly, a sub-surface is not automatically clipped to its parent's area.
To keep in mind though: https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L512-L515
When applied, the effective window geometry will be the set window geometry clamped to the bounding rectangle of the combined geometry of the surface of the xdg_surface and the associated subsurfaces.
Assignee | ||
Comment 15•5 years ago
|
||
Robert, this is a log where Firefox does not do anything with Wayland - wayland related code is not called. All the wl_surface / commit calls come from Gtk.
And I still see the bug - i.e. Window is not maximized after start after it should be and geometry is set to 960 x 1020 although it should be fullscreen.
Can you please check the log if that's a bug in Gtk or Mutter or so?
Thanks.
Assignee | ||
Comment 16•5 years ago
|
||
Looks like mutter/gtk issue, reported as https://gitlab.gnome.org/GNOME/gtk/-/issues/2538
Assignee | ||
Comment 17•5 years ago
|
||
A patch from https://gitlab.gnome.org/GNOME/gtk/-/issues/2538 works for me so moving as Gtk+ issue.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Description
•