1489463 - Maximized windows sometimes get stuck in their initial small creation size when restoring previous session

Status: VERIFIED FIXED

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

Description

[Laurențiu Nicola]

Attachment: firefox-window.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
Build ID: 20180904220134

Steps to reproduce:

I'm on Arch Linux / GNOME Shell / XWayland with browser.startup.blankWindow and browser.tabs.drawInTitlebar enabled. I use session restore and keep the Firefox window maximized.

When opening Firefox, it starts maximized. However, often times, the browser gets drawn as if the window would be smaller (not maximized), with the rest of the window black. I also noticed this in Thunderbird 60 with CSD enabled.

I can maximize the window by clicking on the maximize button, but its hit box is placed wrongly (see screenshot).

Another thing: even when the browser does start up properly, it first draws as a white rectangle on a black background, then fills up the window. On "bad" start-ups, the white rectangle gets redrawn as the browser later, without changing its size. On "good" start-ups, it gets resized to the window size.

See screenshot. The red smudge is the hit box for the maximize button. The button even changes when hovering that region. I didn't include the rest of the window (the part under the address bar), but that's displayed fine.

Comment 1

[Justin Dolske [:Dolske]]

I'm not sure what I'm looking at in this screenshot. The black area is part of what should be a full-screen Firefox, but it's only drawing a subset? What's the little red squiggle at the top?

Gijs, I think you were just looking at some async-sizing bug on Linux?

Comment 2

[:Gijs (out for now; he/him)]

This seems very similar to bug 1454156.

Reporter, did this start happening recently? Any chance you could find a regression window?

Comment 3

[Laurențiu Nicola]

> The black area is part of what should be a full-screen Firefox, but it's only drawing a subset?

It's a maximized (not-full screen like when you press F11) Firefox window, but Firefox draws as if the window was smaller.

> What's the little red squiggle at the top?

It's where I have to click to maximize the window.

> Reporter, did this start happening recently? Any chance you could find a regression window?

No, I think it's been doing it since CSD was implemented.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Laurentiu Nicola from comment #3)
> No, I think it's been doing it since CSD was implemented.

And only with browser.startup.blankWindow = true?

Comment 5

[Helder]

I remember seen something like this without enabling any of the options (browser.startup.blankWindow or browser.tabs.drawInTitlebar), although I believe the rest of the window was white instead of black.

Comment 6

[Laurențiu Nicola]

@Helder I think black is the default background on Wayland. Other platforms sometimes show white or parts of a window instead.

I'm trying to test this without browser.startup.blankWindow, but it's very hard to reproduce (it usually happens after boot). I'll post when I find something new.

Having thought more about this, it might also be a regression, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1454156#c21. But it's hard to tell.

Comment 7

[Anass Ahmed]

Happened to me long before CSD, but always on Wayland (with XWayland Firefox): https://bugzilla.redhat.com/show_bug.cgi?id=1481375

The mouse hovers over the black area as if it hovers over the real button placements (as you can see in my RHBZ report, the tooltip appears in the real place of the button).

Comment 8

[Laurențiu Nicola]

Ahmed might be right. Or Helder might be right.

But I've had browser.startup.blankWindow disabled for a while, and couldn't reproduce the issue. I even thought it got fixed in the meantime. But I enabled browser.startup.blankWindow again, and it happened again on the next day.

One difference I noticed is that this time, the background wasn't black, but transparent.

Comment 9

[Laurențiu Nicola]

Just some additional remarks: this happens on a slower computer, where I have some pinned tabs and session restore enabled, with quite a couple of open tabs. I'll try to narrow it down further, but it's probably a race condition and toggling these settings might influence the start-up timing.

Comment 10

[Pascal Chevrel:pascalc]

Martin, I think this bug falls into your bucket (CSD + wayland)

Comment 11

[Martin Stránský [:stransky] (ni? me)]

(In reply to Pascal Chevrel:pascalc from comment #10)
> Martin, I think this bug falls into your bucket (CSD + wayland)

Yes.

Comment 12

[Kestrel]

This can often be seen briefly when restoring a session but usually corrects itself. Getting stuck in this state can be easily reproduced with a large number of windows:

STR:
1. Press Ctrl+N to create 30 non-maximized windows.
2. Go back to the first window and maximize it.
3. With the first window still focused, quit with Ctrl+Q.
4. Start browser and Restore Previous Session.

Results vary with the compositor, the undersized rendered window is top left and clickable for Basic compositor and bottom left with offset click zones for OpenGL/WebRender. The rest of the screen can be rendered as a maximized window (X11), black (Basic on XWayland), transparent (WebRender on XWayland) or white (Wayland).

It happens with CSD disabled and browser.startup.blankWindow = false. If the maximized window is restored in the foreground, pressing F11 will fullscreen a different window.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2017-06-01&enddate=2017-06-02

Likely regressed by Bug 1364355 (EDIT: Incorrect, see Comment 17).

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Can you please try run firefox as 

$MOZ_GTK_TITLEBAR_DECORATION=client firefox

(i.e. set MOZ_GTK_TITLEBAR_DECORATION env variable to client). It forces CSD mode instead of WM decorations. I tried some tests and it looks like only WM mode (system) is broken and client works fine for me.

Thanks.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Also I'm interested to fix that for X11 first, please leave Wayland/OpenGL behind for now.

Comment 15

[Laurențiu Nicola]

I had trouble reproducing this on X11 before, but I just tried starting Firefox a couple of times with MOZ_GTK_TITLEBAR_DECORATION=client, and it had much less jank. It's not perfect (a maximized black window gets shown, then a window maximize animation, then Firefox appears), but it's no longer getting stuck with the wrong size.

I then tried starting it without that env variable, and it ended up with the wrong size again. So MOZ_GTK_TITLEBAR_DECORATION=client seems to fix this. Note that I already have CSD enabled via browser.tabs.drawInTitlebar.

Comment 16

[Laurențiu Nicola]

PS: That was on XWayland.
PPS: Sorry, I didn't realize you weren't asking me to test this.

Comment 17

[Kestrel]

I can still reliably reproduce it with MOZ_GTK_TITLEBAR_DECORATION=client in X11 (and XWayland) and also with mozilla.widget.use-argb-visuals = false. I made a test build with most of Bug 1364355 changes removed and it still happens so it looks like a different bug in the regression window (which I retested and is quite solid).

Comment 19

[Kestrel]

The next most likely bug in the regression range is Bug 1363829 which relates to windows, timing, focus and paint. One of its regressing bugs, Bug 1366642 sounds very similar to this one.

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I wonder if Andreas has ideas of what happened and the relation with bug 1366642, as he worked on timeout throttling before. Also, speaking with session restore, would Fission have impact on the timing of this issue?

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

FWIW, I've seen this or a variant of this for ages, but only very randomly, and possibly only on one linux machine: The OS level window is maximized but Firefox UI isn't.

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 64. Marking this issue as fix-optional for 65; if you land a patch in nightly and think it's low-risk for beta, please request uplift.

Comment 23

[Andreas Farre [:farre]]

Answering Hsin-Yi's question:

If it's correct that this is due to bug 1363829, then this isn't really about throttling. What Bug 1363829 accomplished was to change setTimeout to use one nsITimer per call to setTimeout to one nsITimer per all calls to setTimeout for one Window (as in nsGlobalWindowInner). What Ben is reasoning about in Bug 1366642 is if this change to how setTimeout uses nsITimers have made setTimeout(f, 0) so much faster that it more frequently wins races against other events having a weak dependence on 'f' coming after where there should be a strong dependence.

Given the nature of the bug this actually feels quite plausible. We can hypothesise that painting the Firefox hangs off a setTimeout and the OS level window maximize waits on a callback from an event on the event queue and the setTimeout wins the race. We could possibly verify this by trying to reproduce this in a setting where we instrument setTimeout to be "slower" but we will probably not find it by scrutinizing Bug 1363829.

Comment 24

[arcooke]

I'm experiencing this as well for months, somewhat frequently yet randomly.

I noticed both the reporter and myself have pinned tabs and CSD. I wonder if it's a problem that only surfaces under these certain conditions? Maybe some kind of bug initializing a pinned tab on session restore with CSD enabled

Screen recording:

https://www.youtube.com/watch?v=FobotXWC-bU

Watch carefully when I minimize and maximize the window. You'll see a faint rectangle on the outside edges animating outward into fullscreen mode.

I get this issue on both of my systems, Firefox Stable 66.0.2 on Solus 4 Budgie and Nightly on KDE Neon

Comment 25

[Laurențiu Nicola]

(In reply to arcooke from comment #24)

I'm experiencing this as well for months, somewhat frequently yet randomly.

I noticed both the reporter and myself have pinned tabs and CSD. I wonder if it's a problem that only surfaces under these certain conditions? Maybe some kind of bug initializing a pinned tab on session restore with CSD enabled

Screen recording:

https://www.youtube.com/watch?v=FobotXWC-bU

Watch carefully when I minimize and maximize the window. You'll see a faint rectangle on the outside edges animating outward into fullscreen mode.

I get this issue on both of my systems, Firefox Stable 66.0.2 on Solus 4 Budgie and Nightly on KDE Neon

Somebody else reported here that it didn't work, but I found the Firefox startup to be much cleaner with MOZ_GTK_TITLEBAR_DECORATION=client. Instead of starting with a smaller size, then maximizing, the browser window starts directly maximized for me. I'm not really sure what the option does (compared to the browser.tabs.drawInTitlebar preference).

Note that you'll have to make sure this is set, so adding it to .profile probably won't work. You can put it in /etc/environment, ~/.pam_environment, or maybe in a .desktop file.

Comment 26

[arcooke]

(In reply to Laurentiu Nicola from comment #25)

Thanks, I'll give it a shot for a while and see if it helps. I just used menulibre to modify the launch command to $MOZ_GTK_TITLEBAR_DECORATION=client firefox %u. So far in the first test, it opened maximized just fine but causes some weird flickering issues in Firefox if I right click on any of my "taskbar" icons in Budgie. Not a big deal though, I don't do that often.

Hopefully this gets looked at further, I'd rather not have to remember to do this on every new installation. Thanks for the reply.

Comment 27

[Laurențiu Nicola]

Does this still happen? I've been running with MOZ_GTK_TITLEBAR_DECORATION=client which fixed the issue for me, but I can't seem to reproduce it even without. I switched to Wayland in the meantime, so that environment variable doesn't seem to be used there: https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6701-6718, but it seems fixed now, even on X11.

Comment 28

[Kestrel]

I can still reliably reproduce this with latest Nightly 69.0a1 on XWayland (Ubuntu 19.04) using Comment 12 STR.

Comment 29

[Gabriele Svelto [:gsvelto]]

It's still happening for me too both under nightly and release, so it's not always reproducible.

Comment 34

[User Dderss]

Also, picture-in-picture feature is sometimes glitchy: it can come up as a tiny stamp all of a sudden.

Comment 35

[Liz Henry (:lizzard) (relman/hg->git project)]

Hsin-Yi, Andreas, can you help find someone to tackle this issue?
From the number of duplicates and possible dupes/related issues, it seems like this issue might be hitting a lot of users.

Comment 36

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Looking at the reports, I feel like it's more likely a Widget:Gtk issue.
I wonder if Martin may know better to suggest the next step.

Comment 37

[Martin Stránský [:stransky] (ni? me)]

I'll look at it.

Comment 38

[User Dderss]

Martin, did you hear about picture-in-picture video window becoming super tiny after Windows wakes up after hibernation?

It happens to me regularly. Is this the same issue as this bug?

Comment 39

[Martin Stránský [:stransky] (ni? me)]

Can you try to create a log of that situation? Just run nightly as

$MOZ_LOG="Widget:5" ./firefox > log.txt 2>&1

close it when you see the bug and attach the log.txt here.

Thanks.

Comment 40

[Laurențiu Nicola]

I mentioned this before, I haven't been able to reproduce the issue for a while now, but other commenters said it still happens. I'll remove my MOZ_GTK_TITLEBAR_DECORATION=client environment variable and keep an eye out for it in the next few days.

I'm running Firefox on Gnome Wayland with the title bar hidden. I don't know why setting MOZ_GTK_TITLEBAR_DECORATION used to have an effect.

Comment 41

[Martin Stránský [:stransky] (ni? me)]

Wayland backend always use MOZ_GTK_TITLEBAR_DECORATION=client as it's running in CSD mode due to Wayland architecture.

Comment 42

[Laurențiu Nicola]

https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6905 suggests that MOZ_GTK_TITLEBAR_DECORATION is set to client on Wayland, but that has been the case since bug 1514828 from last December. Before that it used system on Gnome.

I thought that client meant CSD and system meant non-CSD, but Gnome doesn't support system decorations, so I'm even more confused now.

Anyway, this WORKSFORME. If anyone in this thread still has the issue on non-Wayland, please mention your DE and try the test :stransky suggested.

Comment 43

[Gabriele Svelto [:gsvelto]]

I haven't tried on Wayland, but on non-Wayland I haven't encountered the issue recently.

Comment 44

[Martin Stránský [:stransky] (ni? me)]

(In reply to Laurentiu Nicola from comment #42)

https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6905 suggests that MOZ_GTK_TITLEBAR_DECORATION is set to client on Wayland, but that has been the case since bug 1514828 from last December. Before that it used system on Gnome.

I thought that client meant CSD and system meant non-CSD, but Gnome doesn't support system decorations, so I'm even more confused now.

Client means CSD created/managed by Firefox, system means whatever is system default and it's managed by Gtk. System may mean CSD or non-CSD which depends on actual DE.

Comment 45

[Ludovic Hirlimann [:Usul]]

I reproduce on update. Just started lagging need to wait for the next nightly to show up.

Comment 46

[Laurențiu Nicola]

I still can't reproduce this on Xorg and without MOZ_GTK_TITLEBAR_DECORATION or MOZ_ENABLE_WAYLAND set.

:Usul did you mean to post in this bug?

Comment 47

[Ludovic Hirlimann [:Usul]]

yes

Comment 48

[Darkspirit]

Attachment: 2019-10-02_16-01-17.mp4

20191002033852, Debian Testing, KDE, X11, Macbook Pro A1502, 2560x1600

Comment 49

[Darkspirit]

Attachment: log.txt

MOZ_LOG="Widget:5" ./firefox > log.txt 2>&1

Comment 50

[Ludovic Hirlimann [:Usul]]

Attachment: logforbugzilla.txt.gz

[ludovic@saraan ~]$ tail logforbugzilla.txt
[Parent 85544: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [0x7f53b2933400] for 0x7f53b2933a60 changed 0x80 new_window_state 0xab04
[Parent 85544: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 85544: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [0x7f53b2933400] for 0x7f53b5ec4050 changed 0x80 new_window_state 0xab04
[Parent 85544: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 85544: Main Thread]: D/Widget OnEnterNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnLeaveNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnEnterNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnLeaveNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget GetScreenBounds 0,27 | 1600x843
[Parent 85544: Main Thread]: D/Widget GetScreenBounds 0,27 | 1600x843

Comment 51

[arcooke]

I mentioned in my comment above (#24) that I suspect this may be related to pinned tabs, CSD, or a combination of the two.

Pinned tabs seem to be the one common denominator in all of the reports I've seen. This is evidenced again in comment #48. I am able to reproduce on both of my systems (Solus and KDE Neon) and all Firefox versions (Stable, beta, and nightly). If anyone is trying to reproduce and cannot.. please try pinning tabs and enabling CSD.

Comment 52

[Clément Lefèvre]

(In reply to arcooke from comment #51)

I mentioned in my comment above (#24) that I suspect this may be related to pinned tabs, CSD, or a combination of the two.

Not sure what CSD is, but I also ran into the issue without pinned tabs.

Comment 53

[Martin Stránský [:stransky] (ni? me)]

Thanks for the logs and video!

Comment 54

[Martin Stránský [:stransky] (ni? me)]

This seems to be relevant:

quick return because IS_MOZ_CONTAINER(aWidget) is true

also this line makes sense as we draw to moz_container in CSD mode (not mShell). Looks like we need to listen on mContainer state events in CSD mode.

Comment 55

[Emilio Cobos Álvarez (:emilio)]

FWIW, people that can or cannot reproduce may depend on whether the fix for https://gitlab.gnome.org/GNOME/gtk/issues/1044 is in their system or not (though I haven't verified that).

Comment 56

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #55)

FWIW, people that can or cannot reproduce may depend on whether the fix for https://gitlab.gnome.org/GNOME/gtk/issues/1044 is in their system or not (though I haven't verified that).

Thanks Emilio.

I see in the log/video from comment 49 that Firefox is created maximized, then it's set to normal state but underlying mShell toplevel window remains maximized which seems to be bit different bug. Looks like resize event issued by Firefox itself (by session restore - last window size is saved) is not applied to toplevel mShell window.

Comment 57

[Kestrel]

I can still easily and reliably reproduce this with Comment 12 STR regardless of CSD being enabled or disabled on Ubuntu 19.04 (XWayland). I see the same thing as Comment 48 video (except that the blank area and window position differs based on the compositor). It is most likely a timing issue based on the regression window (Comment 19), that just happens to manifest with GTK.

Comment 58

[Darkspirit]

(In reply to Martin Stránský [:stransky] from comment #56)

Looks like resize event issued by Firefox itself (by session restore - last window size is saved) is not applied to toplevel mShell window.

The (small) window size you see would occur if I unmaximized Nightly. But my Nightly is always maximized because I'm still unable to resize in CSD mode (bug 1453386). The only special thing I do is enforcing DPI=180 in KDE font settings.

Comment 59

[Gabriele Svelto [:gsvelto]]

Scratch my previous comment. I've just hit this on my non-Wayland setup with nightly 20191009213914.

Comment 60

[Asif Youssuff]

I haven't seen this on Wayland recently using Firefox nightly.

This bug is making the rounds on reddit - https://www.reddit.com/r/firefox/comments/dy12wk/for_some_reason_firefox_often_doesnt_open/ - 73 points.

Is there any additional information that could be gathered to help resolve this bug?

Comment 61

[Darkspirit]

Jim, your decision in this component without contribution to this issue is surprising. Please try KDE and restore sessions while having some app tabs pinned. This all started with client side decorations. This is both the most annoying and most user-visible Linux bug. I am sad that a broken Firefox window on a default KDE desktop is considered as wontfix - without any comment about what is going on and how one could further help. 9 days ago I marked 72 as affected as I saw this issue that day (and afterwards) - like all those affected Reddit users across all desktop environments. Yes, this severe regression is really shipped for over a year and nothing was done about it yet. :/

Comment 62

[Darkspirit]

Attachment: 2019-11-27_15-13-40.mp4

Comment 63

[Gabriele Svelto [:gsvelto]]

This morning I just run into this on Xfce (Fedora 31) and it seems reproducible. I'll see if I can get a log out of it.

Comment 64

[Clément Lefèvre]

The same bug can happen on Gnome too. I don't think it depends on the Desktop Environment/Window Manager (excepted maybe tilling WM whose behavior is a bit different).

Comment 65

[Martin Stránský [:stransky] (ni? me)]

I can still reliably reproduce it with MOZ_GTK_TITLEBAR_DECORATION=client in
X11 (and XWayland) and also with mozilla.widget.use-argb-visuals = false. I
made a test build with most of Bug 1364355 changes removed and it still
happens so it looks like a different bug in the regression window (which I
retested and is quite solid).

Can you please try to reproduce with MOZ_GTK_TITLEBAR_DECORATION=system ?
If MOZ_GTK_TITLEBAR_DECORATION=system works (and MOZ_GTK_TITLEBAR_DECORATION=client fails) it's a variant of Bug 1587008 when mozcontainer has it's own window which fails to change the size.
Thanks.

Comment 66

[Martin Stránský [:stransky] (ni? me)]

From what I see now it looks like Firefox resizes itself but GdkWindow size allocation does not change.

Comment 67

[Martin Stránský [:stransky] (ni? me)]

I can reproduce it so I don't need any other info.

Comment 68

[Martin Stránský [:stransky] (ni? me)]

There's the bug description:

step 1
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 2 (maximized)
[(null) 10355: Main Thread]: D/Widget nsWindow::OnSizeAllocate [0x7f8da5976800] 0,0 -> 3892 x 2092
[(null) 10355: Main Thread]: D/Widget configure event [0x7f8da5976800] 0 54 3840 2040
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 3892 x 2092, unscaled 0,54 -> 3892 x 2092

mShell/mContainer is at maximized state, GetScreenBounds returns correct values (3892 x 2092)

step 2
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 0 (normal)
[(null) 10355: Main Thread]: D/Widget nsWindow::Resize [0x7f8da5976800] 1446.000000 945.000000
[(null) 10355: Main Thread]: D/Widget nsWindow::NativeResize [0x7f8da5976800] 1446 945 maximized state 1
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 1446 x 945, unscaled 0,54 -> 1446 x 945

mShell/mContainer is requested to have a normal state but mContainer was not resized yet - we're missing OnSizeAllocate() call on it.
GetScreenBounds was set to new size (1446 x 945) by Resize() without actual mContainer size update.

https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/widget/gtk/nsWindow.cpp#1079
https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/widget/gtk/nsWindow.cpp#1108

step 3
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 2 (maximized)
[(null) 10355: Main Thread]: D/Widget configure event [0x7f8da5976800] 0 54 3840 2040
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 1446 x 945, unscaled 0,54 -> 1446 x 945

mShell/mContainer was asked to be maximized again. GetScreenBounds are set to old size (1446 x 945) by Resize() from step 2
but we don't get another OnSizeAllocate() call as mShell/mContainer didn't change their actual sizes at step 2.

Karl,do you think we can remove the mBounds set from nsWindow::Resize() and wait for mContainer change?

Comment 69

[Karl Tomlinson (:karlt)]

Thank you for the analysis, Martin.

From GTK's perspective, it doesn't need to send a size-allocate for 3892 x 2092 because it hasn't ever sent a size-allocate for 1446 x 945.

(In reply to Martin Stránský [:stransky] from comment #68)

Karl,do you think we can remove the mBounds set from nsWindow::Resize() and wait for mContainer change?

So yes, removing the mBounds.SizeTo() code from Resize() is the right thing to do from GTK's perspective.

If doing that, then it would also make sense to remove the DispatchedResized() call, which would send the wrong size. OnSizeAllocate() will ensure that DispatchedResized() is called eventually.

I don't know how much Gecko depends on mBounds being updated synchronously.
I suspect some tests may make assumptions.

Given that the correct size is eventually notified, any issues should be transient. If the mochitests pass, or can be adjusted to wait for the right size, then I like your approach.

Comment 70

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #69)

Given that the correct size is eventually notified, any issues should be transient. If the mochitests pass, or can be adjusted to wait for the right size, then I like your approach.

You're right, mochitest is all orange. I may find a different solution for it.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=726f2112f3bc12b96892a99f051583d1f7e81484

Comment 71

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1489463 - [Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r?jhorak

Usually we update mBounds from OnSizeAllocate() which is called
by Gtk when mContainer changes its actual size.

However we need to set mBounds in advance at Resize() as JS
code expect immediate window size change. When Resize() is called between
SetSizeMode() calls (which maximize/unmaximize the window) we can miss
OnSizeAllocate() Gtk call as actual mContainer size may not change
from Gtk perspective and we end up with incorrect mBounds.

To compensate it call OnSizeAllocate() explicitly also
from OnConfigureEvent().

Comment 72

[Martin Stránský [:stransky] (ni? me)]

Karl, I can't find any better solution as the delayed mBounds update breaks our test ans I also think JS code expect the window resize is immediate.

A more complicated solution may be to detect the actual scenario (SetSizeMode() -> Resize() ->SetSizeMode() -> OnWindowStateEvent() -> OnWindowStateEvent()) but I think it's too much complicated and it's better to just early return from OnSizeAllocate() when mBounds are already set from configure.

Also it may not break nested mContainers as those were AFAIK used for windowed NPAPI plugins only which are not supported now.

Comment 73

[Martin Stránský [:stransky] (ni? me)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1cbc4b4a585440d4b40936bf4c1914708c79a525

Comment 74

[Karl Tomlinson (:karlt)]

Using OnConfigureEvent() should be fine, I assume, if it works.
If gtk_window_maximize() is called after gtk_window_resize() on a window at maximum size, then it looks like GTK will not send a ConfigureRequest.
I don't know of any guarantee that unmaximize followed by maximize will generate a ConfigureNotify, but it would seem reasonably likely that a window manager would generate a ConfigureNotify.

There will be more resize events if the window is being resized by the user, so there may be a little more lag in keeping up. Hopefully the browser responds somewhat asynchronously to the resize events so as not to repeat layout.

I considered some other approaches, but didn't come up with anything good:

A gtk_container_check_resize() call after gtk_window_resize() would force a ConfigureRequest with the size passed to resize. However, when configure_notify_received is set, gtk_window_move_resize() size_allocate()s with current width/height, which I assume may have the new maximized size by the time the queued resize event runs. Another gtk_container_check_resize() call in OnConfigureEvent() might ensure a gtk_widget_size_allocate() call with the size of the ConfigureNotify response, but all the forced resizes don't seem appealing.

It would be hard to gtk_widget_size_allocate() appropriately immediately after gtk_window_resize() because the allocation for the window needs to include CSD.

I agree that an approach detecting a specific sequence of resize/maximize events is not appealing.

Comment 75

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c9c256a84d8d
[Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r=jhorak

Comment 76

[Natalia Csoregi [:nataliaCs]]

Backed out for failures on browser_roundedWindow_windowSetting_max_inner.js

backout: https://hg.mozilla.org/integration/autoland/rev/c105b062c29812190c074cbd24f97c6306017321

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=linux%2Cx64%2Cshippable%2Copt%2Cmochitests%2Ctest-linux64-shippable%2Fopt-mochitest-browser-chrome-e10s-3%2Cm%28bc3%29&revision=c9c256a84d8de828e6af4f04183ee8d0eb039a20&selectedJob=281355202

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=281355202&repo=autoland&lineNumber=3110

[task 2019-12-16T13:28:43.547Z] 13:28:43 INFO - TEST-PASS | browser/components/resistfingerprinting/test/browser/browser_roundedWindow_windowSetting_max_inner.js | The window.innerWidth has a correct rounded value - 1000 == 1000 -
[task 2019-12-16T13:28:43.547Z] 13:28:43 INFO - Buffered messages finished
[task 2019-12-16T13:28:43.548Z] 13:28:43 INFO - TEST-UNEXPECTED-FAIL | browser/components/resistfingerprinting/test/browser/browser_roundedWindow_windowSetting_max_inner.js | The screen.height has a correct rounded value - 100 == 1000 - got 100, expected 1000 (operator ==)
[task 2019-12-16T13:28:43.548Z] 13:28:43 INFO - Stack trace:
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - is@resource://specialpowers/SpecialPowersSandbox.jsm:89:21
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - @chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:278:13
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - EventListener.handleEvent*@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:275:11
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - @chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:274:11
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - asyncexecute@resource://specialpowers/SpecialPowersSandbox.jsm:140:12
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - _spawnTask@resource://specialpowers/SpecialPowersChild.jsm:1724:15
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - receiveMessage@resource://specialpowers/SpecialPowersChild.jsm:286:21
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - JSWindowActor queryreceiveMessage@resource://specialpowers/SpecialPowersParent.jsm:1055:12
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - JSWindowActor queryspawn@resource://specialpowers/SpecialPowersChild.jsm:1679:17
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - testWindowSizeSetting@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:221:23
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - doTest@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:372:11
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - doTests@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:359:18
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - asyncrun/<@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:317:20
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - Tester_execTest/<@chrome://mochikit/content/browser-test.js:1062:34
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - async*Tester_execTest@chrome://mochikit/content/browser-test.js:1097:11
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - nextTest/<@chrome://mochikit/content/browser-test.js:925:14
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:808:67
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - Not taking screenshot here: see the one that was previously logged

Comment 77

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/26a680dd5f44
[Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r=jhorak

Comment 78

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/26a680dd5f44

Comment 79

[Kestrel]

Attachment: Maximized window from previous session still not fully rendering

I can still reliably reproduce this on latest Nightly with STR from Comment 12.

Comment 80

[Laurențiu Nicola]

I'm the original reporter but I no longer had this problem. I upgraded today to check up on this patch, and on the first startup the window size was wrong. One difference is that the window buttons are now aligned correctly, while the window extends downwards, under my panel. Clicking maximize (or restore?) once brought the window height to the screen height, while a second click maximized it properly.

Comment 81

[Martin Stránský [:stransky] (ni? me)]

(In reply to Kestrel from comment #79)

Created attachment 9116640 [details]
Maximized window from previous session still not fully rendering

I can still reliably reproduce this on latest Nightly with STR from Comment 12.

Can you please run with MOZ_LOG="Widget:5" and attach the output here?
Thanks.

Comment 82

[Kestrel]

Attachment: Log of a session being restored with 31 windows, first window is maximized and not fully rendered

As requested.

Comment 83

[Martin Stránský [:stransky] (ni? me)]

Thanks.

Comment 84

[Martin Stránský [:stransky] (ni? me)]

I'm afraid there's no workaround so just need to fix the tests.

Comment 85

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1489463 [Linux] Invalidate mBounds by state event changes, r?jhorak

• Invalidate mBounds when window state is changed. That ensures we get new window size from configure event.
• Join Resize() routines and use ResizeInt() for the actual resize work.
• Add more logging to nsWindow file.

Comment 86

[Martin Stránský [:stransky] (ni? me)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ec6a0f92ba60223080ef5a68974169f2e21dad97

Comment 87

[Martin Stránský [:stransky] (ni? me)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0bfebc0956c19fa12f38e1898c05f5b894456fa5

Comment 88

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b38387950db
[Linux] Invalidate mBounds by state event changes, r=jhorak

Comment 89

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/7b38387950db

Comment 90

[Kestrel]

Comment 12 STR is no longer reproducible on latest Nightly.

Comment 91

[Gabriele Svelto [:gsvelto]]

(In reply to Kestrel from comment #90)

Comment 12 STR is no longer reproducible on latest Nightly.

\o/ This is awesome

Comment 92

[arcooke]

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Solus w/ Budgie (Mutter)

Comment 93

[Asif Youssuff]

arcooke, I have a feeling that your issue might be the same as the issue I reported in Bug 1604948, which I have been informed is a mutter/gnome-shell bug. Since you use mutter, maybe the same issue?

Comment 94

[arcooke]

That could have something to do with the black part I suppose.. but I'm still having the original reported issue with the firefox window rendering in the wrong spot. You can see in my video that my mouse cursor is hovering over an invisible browser window at the top of the screen, while highlighting tabs and buttons in the visible firefox window below.

I posted about it in this thread 9 months ago and I've been encountering it almost every day since, so I'm intimately familiar with the bug. No fix yet on my end, unfortunately :(

Comment 95

[Julien Cristau [:jcristau]]

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

This bug is marked as fixed in 73 (current nightly), not 72 (current beta).

Comment 96

[Martin Stránský [:stransky] (ni? me)]

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Yes, I understand you. I saw that too with WebRender/GL compositor enabled. This one is a bug when underlying mozcontainer which is holding GL window is not resized/positioned properly. This bug happens with WebRender/GL compositor only.

If you see it please file a new bug against widget:gtk for it and CC me there.

Thanks.

Comment 97

[arcooke]

(In reply to Julien Cristau [:jcristau] from comment #95)

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

This bug is marked as fixed in 73 (current nightly), not 72 (current beta).

Touché... you're right. I bamboozled myself. I use Beta on some of my machines and use Nightly on others.. but I always manually change to the purple nightly icon because I like how it looks.. ha. I'll switch to nightly on that machine and see if that resolves it (I expect it will now). Thanks

(In reply to Martin Stránský [:stransky] from comment #96)

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Yes, I understand you. I saw that too with WebRender/GL compositor enabled. This one is a bug when underlying mozcontainer which is holding GL window is not resized/positioned properly. This bug happens with WebRender/GL compositor only.

If you see it please file a new bug against widget:gtk for it and CC me there.

Thanks.

Will do! Thanks. And you're correct, I'm using webrender/gl.

This can probably be re-closed now.. apologies for the mixup

Comment 99

[Darkspirit]

This intermittent bug (comment 62) came back four or five weeks ago. It was present before and during bug 1624199. (KDE, X11, Debian Testing)

Comment 100

[Laurențiu Nicola]

I can confirm. I think it started showing up again around bug 1609538.