Open Bug 1251217 Opened 8 years ago Updated 2 years ago

Grey bar at the bottom of initially maximized window

Categories

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

Unspecified
Linux
defect

Tracking

()

REOPENED
Tracking Status
firefox47 - wontfix

People

(Reporter: marco, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted][tpi:+])

Attachments

(6 files)

Lately, I've been seeing this grey bar at the bottom of every page. I can't reproduce it easily.
Sorry, bottom of only one window. The second window doesn't have it.
Summary: Grey bar at the bottom of all windows → Grey bar at the bottom of a window
I've tried disabling all addons, still happening.
If I resize the window, the grey bar disappears.
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.
OS: Unspecified → Linux
It doesn't happen if I run Firefox via mozregression, even if I use my profile...
Does this ever happen when gfx.xrender.enabled is true?
(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.
Component: Untriaged → Graphics
Product: Firefox → Core
This doesn't happen if I set display scaling to a value below 1.5 (like Jonathan described in bug 1248427 comment 7).
Whiteboard: [gfx-noted]
Keywords: regression
Summary: Grey bar at the bottom of a window → Grey bar at the bottom of a window with dpi scaling
Looks like this was fixed by the patch from bug 1240749, so this was likely a regression from bug 890156.
Blocks: 890156
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
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.
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).
No longer blocks: 890156
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Still unable to reproduce with mozregression.
Summary: Grey bar at the bottom of a window with dpi scaling → Grey bar at the bottom of a window
Thanks for chasing this Marco; having the regression range will help, as you say, it's a sneaky bug.
Assignee: nobody → milan
Flags: needinfo?(howareyou322)
Assignee: milan → nobody
Platform triage decision: We don't believe this is critical for Fx47 release.
I couldn't reproduce this with FF 47 on linux based on comment 11. Marco, are you still able to reproduce it?
Flags: needinfo?(howareyou322) → needinfo?(mcastelluccio)
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.
Flags: needinfo?(mcastelluccio)
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.
Flags: needinfo?(mcastelluccio)
Does the window always open in maximized mode, even when it was not maximized in the previous session?
See Also: → 1274620
(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.
Flags: needinfo?(mcastelluccio)
(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).
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.
(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.
(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.
Attached file 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.
(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.
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 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.
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.
Summary: Grey bar at the bottom of a window → Grey bar at the bottom of initially maximized window
Component: Graphics → Widget: Gtk
See Also: 1274620
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.
Priority: -- → P3
Whiteboard: [gfx-noted] → [gfx-noted][tpi:+]
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: