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

NEW
Unassigned

Status

()

defect
P2
normal
9 months ago
a month ago

People

(Reporter: grayshade, Unassigned)

Tracking

({regression})

64 Branch
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 wontfix, firefox65 fix-optional)

Details

(Whiteboard: [STR comment 12])

Attachments

(1 attachment)

Reporter

Description

9 months ago
Posted 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.
Reporter

Updated

9 months ago
Summary: [CSD] Firefox window displayed wrong on startup with → [CSD] Firefox window displayed wrong on startup with wrong size

Updated

9 months ago
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)

Comment 2

8 months ago
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
Reporter

Comment 3

8 months ago
> 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
Reporter

Updated

8 months ago
Flags: needinfo?(grayshade)
Summary: [CSD] Firefox window displayed wrong on startup with wrong size → [CSD] Firefox window displayed on startup with wrong size

Comment 5

8 months ago
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.
Reporter

Comment 6

8 months ago
@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)

Comment 7

8 months ago
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).
Reporter

Comment 8

8 months ago
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
Reporter

Comment 9

8 months ago
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)

Comment 12

6 months ago
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.
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.
Reporter

Comment 15

6 months ago
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.
Reporter

Comment 16

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

Comment 17

6 months ago
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

Comment 19

6 months ago
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)

Updated

5 months ago
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
Product: Core → Core

Comment 24

a month ago

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

Reporter

Comment 25

a month ago

(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

a month ago

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

You need to log in before you can comment on or make changes to this bug.