1251217 - Grey bar at the bottom of initially maximized window

Status: REOPENED

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

Description

[Marco Castelluccio [:marco]]

Attachment: Schermata del 2016-02-25 13-37-49.png

Lately, I've been seeing this grey bar at the bottom of every page. I can't reproduce it easily.

Comment 1

[Marco Castelluccio [:marco]]

Sorry, bottom of only one window. The second window doesn't have it.

Comment 2

[Marco Castelluccio [:marco]]

I've tried disabling all addons, still happening.

Comment 3

[Marco Castelluccio [:marco]]

If I resize the window, the grey bar disappears.

Comment 4

[Marco Castelluccio [:marco]]

Attachment: Schermata del 2016-02-25 13-47-55.png

If I open another application while Firefox is starting up, instead of the grey bar I see the bottom part of the window of the other application.

Comment 5

[Marco Castelluccio [:marco]]

It doesn't happen if I run Firefox via mozregression, even if I use my profile...

Comment 6

[Karl Tomlinson (:karlt)]

Does this ever happen when gfx.xrender.enabled is true?

Comment 7

[Marco Castelluccio [:marco]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #6)
> Does this ever happen when gfx.xrender.enabled is true?

Yes, it happens no matter what the value of the pref is.

Comment 8

[Marco Castelluccio [:marco]]

This doesn't happen if I set display scaling to a value below 1.5 (like Jonathan described in bug 1248427 comment 7).

Comment 9

[Marco Castelluccio [:marco]]

Looks like this was fixed by the patch from bug 1240749, so this was likely a regression from bug 890156.

Comment 10

[Jonathan Kew [:jfkthame]]

Great! Thanks for checking. Bug 1240749 aimed to substantially clean up DPI handling in widget/gtk, so it makes sense for it to have fixed this at the same time.

Comment 11

[Marco Castelluccio [:marco]]

Unfortunately, it's still happening and it isn't related to DPI. It's a sneaky bug.

I have another observation.

If I open Firefox, minimize and maximize the first window and then restart, it doesn't happen.

If I restart without minimizing and maximizing the window (which is the normal situation when you launch Firefox for the first time in a session), it happens.

I'll try to find a regression range with mozregression tomorrow (I already tried and failed before, because I couldn't reproduce in builds downloaded via mozregression, but now I have this additional observation which could help).

Comment 12

[Marco Castelluccio [:marco]]

Still unable to reproduce with mozregression.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks for chasing this Marco; having the regression range will help, as you say, it's a sneaky bug.

Comment 14

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Platform triage decision: We don't believe this is critical for Fx47 release.

Comment 15

[Peter Chang[:pchang]]

I couldn't reproduce this with FF 47 on linux based on comment 11. Marco, are you still able to reproduce it?

Comment 16

[Marco Castelluccio [:marco]]

Yes, I can still reproduce it. The grey bar (which actually isn't a gray bar but a portion of the screen with stale content, so it is gray if the background was gray when I started Firefox) is sometimes at the bottom, sometimes on the right side.

Comment 17

[Peter Chang[:pchang]]

Marco, are you still able to reproduce this with latest firefox nightly? If yes, can you go to about:config page and enable nglayout.debug.paint_flashing/layers.draw-borders? Please also update the captured screen and about:support page for further debugging.

Comment 18

[Karl Tomlinson (:karlt)]

Does the window always open in maximized mode, even when it was not maximized in the previous session?

Comment 19

[Marco Castelluccio [:marco]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #18)
> Does the window always open in maximized mode, even when it was not
> maximized in the previous session?

I think it opens maximized and quickly gets resized.

I can't reproduce the bug if I restart Firefox after resizing the window (see comment 11), probably because the window gets resized.

Bug 1274620 looks like a duplicate of this bug.

Comment 20

[Marco Castelluccio [:marco]]

Attachment: Schermata del 2016-05-26 11-49-18.png

(In reply to Peter Chang[:pchang] from comment #17)
> Marco, are you still able to reproduce this with latest firefox nightly? If
> yes, can you go to about:config page and enable
> nglayout.debug.paint_flashing/layers.draw-borders? Please also update the
> captured screen and about:support page for further debugging.

Yes, I'm still able to reproduce.

Here's a first screenshot (without those options enabled).

You can see that there's a rectangle at the bottom that contains stale content from the window that was focused before Firefox (a gedit window).

Comment 21

[Marco Castelluccio [:marco]]

Attachment: Schermata del 2016-05-26 11-59-19.png

Here's a second screenshot with the options enabled.

Now for some reason the window is in a weird state. It's maximized (because the window manager is not showing the title bar) and at the same time it isn't.

Comment 22

[Karl Tomlinson (:karlt)]

(In reply to Marco Castelluccio [:marco] from comment #19)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #18)
> > Does the window always open in maximized mode, even when it was not
> > maximized in the previous session?
> 
> I think it opens maximized and quickly gets resized.

I'm not understanding.  The windows look maximized in the screenshots.
Are they?

> I can't reproduce the bug if I restart Firefox after resizing the window
> (see comment 11), probably because the window gets resized.

Comment 11 says it doesn't reproduce when the window is explicitly maximized before restarting.

It sounds like this bug happens when the window manager chooses to maximize?

NSPR_LOG_MODULES=Widget:5 may provide some clues.

In Preferences -> General, what is "When Nightly starts"?
I wonder whether "Show my windows and tabs from last time" is involved.

Comment 23

[Peter Chang[:pchang]]

(In reply to Marco Castelluccio [:marco] from comment #21)
> Created attachment 8756801 [details]
> Schermata del 2016-05-26 11-59-19.png
> 
> Here's a second screenshot with the options enabled.
> 
> Now for some reason the window is in a weird state. It's maximized (because
> the window manager is not showing the title bar) and at the same time it
> isn't.

Each green border is represented one layer(buffer) to display the content. I noticed the layer of xul with ABP button was very small(not fullscreen) but the FF windows was maximized.

Comment 24

[Marco Castelluccio [:marco]]

Attachment: widget_log.txt

(In reply to Karl Tomlinson (ni?:karlt) from comment #22)
> (In reply to Marco Castelluccio [:marco] from comment #19)
> > (In reply to Karl Tomlinson (ni?:karlt) from comment #18)
> > > Does the window always open in maximized mode, even when it was not
> > > maximized in the previous session?
> > 
> > I think it opens maximized and quickly gets resized.
> 
> I'm not understanding.  The windows look maximized in the screenshots.
> Are they?

Sorry, let me clarify.

- I have multiple windows open, the bug is always related to the first one.
- If I resize this window and restart Firefox, I can't reproduce the bug and the window is opened with the right dimensions (and not maximized).
- If I resize and then maximize this window and restart Firefox, I can't reproduce the bug and the window is maximized.
- If I never resize the window during the session, I can reproduce the bug the next time I start Firefox.

> 
> > I can't reproduce the bug if I restart Firefox after resizing the window
> > (see comment 11), probably because the window gets resized.
> 
> Comment 11 says it doesn't reproduce when the window is explicitly maximized
> before restarting.
> 
> It sounds like this bug happens when the window manager chooses to maximize?
> 
> NSPR_LOG_MODULES=Widget:5 may provide some clues.
> 
> In Preferences -> General, what is "When Nightly starts"?
> I wonder whether "Show my windows and tabs from last time" is involved.

I'm attaching the log.

Yes, I set up Nightly to restore the session.

Comment 25

[Marco Castelluccio [:marco]]

(In reply to Peter Chang[:pchang] from comment #23)
> (In reply to Marco Castelluccio [:marco] from comment #21)
> > Created attachment 8756801 [details]
> > Schermata del 2016-05-26 11-59-19.png
> > 
> > Here's a second screenshot with the options enabled.
> > 
> > Now for some reason the window is in a weird state. It's maximized (because
> > the window manager is not showing the title bar) and at the same time it
> > isn't.
> 
> Each green border is represented one layer(buffer) to display the content. I
> noticed the layer of xul with ABP button was very small(not fullscreen) but
> the FF windows was maximized.

Indeed, that's the problem in the last screenshot.

Comment 26

[Marco Castelluccio [:marco]]

Attachment: Schermata del 2016-05-27 09-55-51.png

Here's another screenshot. The first window is actually maximized, the area around the window is stale content (that is, I can't interact with it in any way).

Comment 27

[Karl Tomlinson (:karlt)]

Comment on attachment 8757231 [details]
widget_log.txt

Thanks.

It looks like there is initially a small 770x470 window at 1112,596.   A button
click causes that to close.

Then it looks like a new process starts, requests maximized mode for a window
[7ff17a4f0c00] before showing.  It is notified of dimensions 2766x1578 at
114,42, which is consistent with maximized mode on a 2880x1620 monitor.

A new 1982x854 window [7ff16d7ae000] is shown at 898,766, not maximized.

Another new 1982x854 window [7ff16e4ec800] is shown at 898,766, not maximized.

The window [7ff17a4f0c00] that was maximized requests normal size mode (but I
can't tell from the log whether the request was actually sent to the window
manager).  Then it requests maximized mode again.

Configure events indicate that the window is resized and repositioned, but
then returns to 2766x1578 at 114,42.

No size_allocate nor OnWindowStateEvent maximized status change notifications
are received for these resizes.

Another new 1982x854 window [7ff16e4f0800] is shown at 898,766, not maximized.

Window [7ff16d7ae000] requests maximized mode, then normal mode, then
maximized mode, then normal mode, then maximized mode.  It is resized to
2766x1578 at 114,42 and receives a size-allocate notification.

Window [7ff16e4f0800] requests maximized mode.  It is resized to
2766x1578 at 114,42 and receives a size-allocate notification.

Comment 28

[Karl Tomlinson (:karlt)]

I don't know why session restore is indecisive on the window modes.

What goes wrong with [7ff17a4f0c00] seems to be that the bounds are recorded
on size request when resized to unmaximized size, but are not updated for the
later maximized size because the multiple changes in state are effectively
coalesced into a no-op and so no size-allocate is received.

Probably mBounds should not be set on the resize request in general, because
we don't know that the size will be changed.  We do know that a configure
notify event will be received, but there are many of them.

The disadvantage of waiting for the size-allocate to update mBounds is that
layout can't prospectively begin resize reflow until the size allocate is
received.  That would however be much less a problem than ending up with the
wrong size.

I think the next step here is to try not setting mBounds until size-allocate
on (toplevel) managed windows, and see what is depending on this being set
synchronously.

Comment 30

[Clemens Eisserer]

Just experienced this issue with FF 48.0b7 on fedora-24 with latest updates running xfce4/xfwn.
At startup firefox restored 4 Tabs but content was only 2/3 of the window size.

Comment 31

[Clemens Eisserer]

What I saw recently quite often is that firefox needs a few seconds to actually resize its content to the main window: https://youtu.be/oSZDrSV_O9c

so while the content resize does happen, it is performed very delayed and leads to horrible user experience.