Closed Bug 1489463 Opened 2 years ago Closed 1 year ago

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

Categories

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

64 Branch
Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla73
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- fixed

People

(Reporter: grayshade, Assigned: stransky)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [STR comment 12])

Attachments

(9 files)

Attached image 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.
Summary: [CSD] Firefox window displayed wrong on startup with → [CSD] Firefox window displayed wrong on startup with wrong size
Component: Untriaged → General
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
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?
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(grayshade)
This seems very similar to bug 1454156.

Reporter, did this start happening recently? Any chance you could find a regression window?
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 1454156
> 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.
Flags: needinfo?(grayshade)
(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?
Blocks: gtktitlebar
Component: General → Widget: Gtk
Flags: needinfo?(grayshade)
Product: Firefox → Core
Flags: needinfo?(grayshade)
Summary: [CSD] Firefox window displayed wrong on startup with wrong size → [CSD] Firefox window displayed on startup with wrong size
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.
@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.
Flags: needinfo?(grayshade)
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).
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.
Flags: needinfo?(grayshade)
Blocks: 1336227
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.
Martin, I think this bug falls into your bucket (CSD + wayland)
Flags: needinfo?(stransky)
(In reply to Pascal Chevrel:pascalc from comment #10)
> Martin, I think this bug falls into your bucket (CSD + wayland)

Yes.
Flags: needinfo?(stransky)
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).
Blocks: 1364355
No longer blocks: 1336227
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(stransky)
Summary: [CSD] Firefox window displayed on startup with wrong size → Maximized windows sometimes get stuck in their initial small creation size when restoring previous session
Whiteboard: [STR comment 12]
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.
Flags: needinfo?(stransky) → needinfo?(ke5trel)
Also I'm interested to fix that for X11 first, please leave Wayland/OpenGL behind for now.
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.
PS: That was on XWayland.
PPS: Sorry, I didn't realize you weren't asking me to test this.
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).
Flags: needinfo?(ke5trel)
Duplicate of this bug: 1458860
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.
Blocks: 1363829
No longer blocks: gtktitlebar, 1364355
Component: Widget: Gtk → DOM
See Also: → 1366642
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?
Flags: needinfo?(afarre)
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.
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.

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.

Flags: needinfo?(afarre)
Priority: -- → P2
Component: DOM → DOM: Core & HTML

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

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

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

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.

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

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

See Also: → 1521175
Duplicate of this bug: 1521175
Duplicate of this bug: 1458860
Duplicate of this bug: 1561616
See Also: → 1502519
Hardware: x86_64 → Desktop
See Also: → 1567583
Duplicate of this bug: 1553338
See Also: → 1572995
See Also: → 1535565
See Also: → 1427663

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.

Flags: needinfo?(htsai)
Flags: needinfo?(afarre)

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.

Component: DOM: Core & HTML → Widget: Gtk
Flags: needinfo?(stransky)
Flags: needinfo?(htsai)
Flags: needinfo?(afarre)

I'll look at it.

Flags: needinfo?(stransky)

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?

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.

Flags: needinfo?(grayshade)

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.

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

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.

Flags: needinfo?(ke5trel)
Flags: needinfo?(gsvelto)

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

Flags: needinfo?(gsvelto)

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

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

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?

Flags: needinfo?(grayshade)
Attached video 2019-10-02_16-01-17.mp4

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

Attached file log.txt

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

Attached file 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

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.

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

Thanks for the logs and video!

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.

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

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

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.

No longer blocks: 1363829
Flags: needinfo?(ke5trel)
Regressed by: 1363829

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

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

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?

Priority: P2 → P5

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

Flags: needinfo?(jmathies)
Attached video 2019-11-27_15-13-40.mp4

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.

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

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.

Flags: needinfo?(ke5trel)
Assignee: nobody → stransky
Priority: P5 → P2

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

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

Flags: needinfo?(ke5trel)
Status: NEW → ASSIGNED
Flags: needinfo?(jmathies)

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?

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

Flags: needinfo?(karlt)

(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

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

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.

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.

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

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 query
receiveMessage@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 - async
run/<@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

Flags: needinfo?(stransky)
Attachment #9113738 - Attachment description: Bug 1489463 - [Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r?karlt → Bug 1489463 - [Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r?jhorak
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/26a680dd5f44
[Linux/Gtk] Call OnSizeAllocate() explicitly also from OnConfigureEvent(), r=jhorak
Flags: needinfo?(stransky)
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73

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

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.

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

Thanks.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

  • 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.
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7b38387950db
[Linux] Invalidate mBounds by state event changes, r=jhorak
Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED

Comment 12 STR is no longer reproducible on latest Nightly.

(In reply to Kestrel from comment #90)

Comment 12 STR is no longer reproducible on latest Nightly.

\o/ This is awesome

Status: RESOLVED → VERIFIED

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)

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?

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

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

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

(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

Duplicate of this bug: 1502519
Regressions: 1623106

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

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

See Also: → 1630251
You need to log in before you can comment on or make changes to this bug.