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?
This seems very similar to bug 1454156. Reporter, did this start happening recently? Any chance you could find a regression window?
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.
(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?
Component: General → Widget: Gtk
Product: Firefox → Core
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.
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.
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)
(In reply to Pascal Chevrel:pascalc from comment #10) > Martin, I think this bug falls into your bucket (CSD + wayland) Yes.
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.
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
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).
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.
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?
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.
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.