Closed Bug 1623658 Opened 4 years ago Closed 4 years ago

[Wayland] Firefox is resized on background

Categories

(Core :: Widget: Gtk, defect, P2)

defect

Tracking

()

RESOLVED MOVED

People

(Reporter: stransky, Assigned: stransky)

References

(Blocks 1 open bug, )

Details

Attachments

(2 files)

Follow up from Bug 1623106.

Summary: [Linux/Gtk] Firefox sometimes starts in normal mode instead of maximized one → [Linux/Gtk] Firefox sometimes starts in normal mode instead of maximized one - follow up bug
Priority: -- → P2

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.

Blocks: wayland
Summary: [Linux/Gtk] Firefox sometimes starts in normal mode instead of maximized one - follow up bug → [Wayland] Firefox is resized on background

Robert, any idea why this happens and why? Also why we don't get any info about it? (window state change?)

Flags: needinfo?(robert.mader)

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.

btw. This is Fedora 32 / mutter-3.36.0-1.fc32.x86_64

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()
Flags: needinfo?(robert.mader)

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.

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.

(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.

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 :/

See Also: → 1624199

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.

The scale part looks consistent to me (surface size 960x1020, buffer size 1920x2040, buffer scale 2) - it just should be 1920x1020,3840x2040,2

Robert, is it correct when wl_subsurface has a different size than wl_surface or not?
Thanks.

Flags: needinfo?(robert.mader)

(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.

Flags: needinfo?(robert.mader)
Attached file run-gtk-only.txt

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.

Flags: needinfo?(robert.mader)

Looks like mutter/gtk issue, reported as https://gitlab.gnome.org/GNOME/gtk/-/issues/2538

A patch from https://gitlab.gnome.org/GNOME/gtk/-/issues/2538 works for me so moving as Gtk+ issue.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Resolution: INVALID → MOVED
Flags: needinfo?(robert.mader)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: