Closed Bug 574638 Opened 14 years ago Closed 14 years ago

Browser client area doesn't paint when restoring to maximized state

Categories

(Core :: Widget: Win32, defect)

x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: jmjjeffery, Assigned: jimm)

References

Details

(Keywords: regression, relnote)

Attachments

(7 files, 2 obsolete files)

With the landing of bug 513162, when the browser is started up, the entire area at the top of the browser window is gray displaying no Chrome UI at all, until after the browser, and any tabs are loaded from say sessionstore.
Confirmed. Happens to me too.
Only with D2D/DW.
(In reply to comment #2)
> Only with D2D/DW.

No, it happens whether dw/d2d is on or off..
(In reply to comment #3)
> (In reply to comment #2)
> > Only with D2D/DW.
> 
> No, it happens whether dw/d2d is on or off..

Correct, it's happening on WinXP classic as well.

~B
(In reply to comment #5)
> Is this fixed now?

I'm still seeing this issue on Windows XP Classic but to be clear in my case I see all black where the tabbar, address bar, toolbar and file menu would normally be until after the browser, and any tabs are loaded from say sessionstore.

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre ( .NET CLR 3.5.30729; .NET4.0C) ID:20100629135842

~B
(In reply to comment #5)
> Is this fixed now?

No..I still see it, and I don't use d2d stuff at the moment. It looks really ugly when the browser starts up, a large gray border, with a white middle, and no UI at all till the tabs from the previous session are almost all loaded.
any chance you guys could grab a print screen screen shot of what this looks like and post?
Yeah I can try when I get home from work, about 3 hrs...
Do we know what set of users this affects?
Is this on a clean profile? 

Juan, can we get someone to help us get a clear STR? Sounds like we should be testing WinXP in Classic Mode - Dao usually tests that, though! :)
Attached image Screenshot on Windows 7
This is the issue I assumed this bug was about. It sits like this for about a second or two on my Windows 7 x64 laptop with Intel GMA4500 graphics.
Attached image Gray UI on Startup Win7
Screen shot Win7 x64 ATI on-board HD3200 video chip, AMD Phenom II Quad

The gray border can last from a few seconds to several.  I have a set of 11 tabs I usually start with the browser.
New profile, no tabs,bookmarks - shows a quick splash of gray border on start, so I don't think its a profile issue.
Not a beta 1 blocker, but we'll relnote it and try to get it for an early beta.
Assignee: nobody → jmathies
blocking2.0: ? → final+
Keywords: relnote
Component: Layout → Widget: Win32
QA Contact: layout → win32
Blocks: 576096
No longer blocks: 513162
Is anyone else experiencing slower than normal loading time for the browser chrome? When it's all grey, clicking anywhere within the window or title bar makes it unresponsive.
Not really a major issue but on the release notes it says this bug only happens with Windows classic theme but it happens with any theme actually.
Depends on: 577208
blocking2.0: final+ → beta2+
Blocks: 513162
No longer blocks: 576096
blocking2.0: beta2+ → betaN+
It might be worth mentioning that on Word 2010, the glasses areas load as grey too, while the content areas load as white. At times when Word 2010 just works, you don't notice this at all due to the loading panel. So I'm not confident of how much we can do to eradicate this completely.
Since running the Firefox 4 Betas (both 1 and 2) I have experienced the same problem, with the whole interface appearing grey/white for several seconds until the UI loads fully. It doesn't look good! 

OS is Windows 7 64Bit
This minor annoyance at first seems to be getting worse as builds go on. At first I only saw the grey/white boxes after a Windows restart, now it happens at every Minefield restart. I am running Windows 7 64 Bit.
(In reply to comment #22)

I've noticed that also. This regression also really slows down startup time. It ranges from 3-30 seconds. Clicking anywhere in the gray space makes FF unresponsive.
This may be addressed by the patch in bug 579421. Will have to wait to see once it lands.
(In reply to comment #24)
> This may be addressed by the patch in bug 579421. Will have to wait to see once
> it lands.

What's the relationship between the two bugs?
(In reply to comment #25)
> What's the relationship between the two bugs?

Both deal with early rendering of the browser window.

Bug 5679421 just landed, btw.
(In reply to comment #26)

Apparently they weren't connected since this still happens.
Was the regression window ever found?
I know we've seen the white area in bug about resizing a window always revealed the same white rectangle, so correlate that with another example i just saw was if I had a window open long and skinny, it showed up in the grey area as white rectangle in the same area.

The white area seems to still be related to previous or prior windows dimension paints being open before the main window displays.
I think you're onto something Dennis, as occasionally I get a "URL cannot be loaded" dialogue box before the GUI has even loaded properly.I think this bug may be fixed by loading the GUI first and then loading the content/accessing the session store. But my amateur analysis isn't worth much.
Well, Jim, Mike, I might have found some steps to reproduce the white area on grey at least with session restore (which may or may not matter)

As I said a moment ago:

I had window of normal mode dimensions in a previous session of a long and skinny window and have session restore running.

1. Run the browser in Maximized mode (only 1 window open).  
2. Close the browser from the X Maximized window.
3. Choose Save and Quit.  
4. It restarts (to restore my session).  But its not being restore as Normal window but Maximized, this is expected. 
5. Watch the window first paints the normal window mode as white on grey background as it starts up and then it loads the window as Maximized and paints chrome/content.
I know it needs to be refined a bit.. my window in normal mode is long and skinny before I run the browser in Maximized mode, step 1.

Also, I just tested Step 3 using only Quit - to not restore tabs, and it still does it.  My start up option is set to show my homepage, and remember history - not that either matter per say.
The grey UI areas looks relative to changing the normal mode dimensions.  

(In reply to comment #29)
> I think you're onto something Dennis, as occasionally I get a "URL cannot be
> loaded" dialogue box before the GUI has even loaded properly.I think this bug
> may be fixed by loading the GUI first and then loading the content/accessing
> the session store. But my amateur analysis isn't worth much.

Could be, I guess we'll let Jim take a look. The other thing I've seen related to random transparent-ness, I thought we had bug on that too already, as sometimes I get chrome paints over my windows 7 gadget, and content paints under the other gadget. ie a Z-order bug.
I get a mass of grey and a white bit on every start. The size of the white bit differs.
So, based on the comments here and all the screenshots, I'm correct is assuming  this is a restore session w/ a maximized window specific bug?
(In reply to comment #34)
> So, based on the comments here and all the screenshots, I'm correct is assuming
>  this is a restore session w/ a maximized window specific bug?

* "am I correct in assuming"
Well, I'm thinking its related at least to Maximized, I didn't see Normal Mode do it since it came up ok then.  Session Restore I'm not sure yet it may or may not be related.   

I also noticed Grey and White UI doing another type of activity:

Again, start with the long and skinny vertical normal window.  Place it on the left size of the monitor.  Then use the resize on the right border and drag it across your screen really fast, and drag it back, repeat that.  You see the Content area is painting grey first, and the chrome is painting white first.
(In reply to comment #36)
> I also noticed Grey and White UI doing another type of activity:
> 
> Again, start with the long and skinny vertical normal window.  Place it on the
> left size of the monitor.  Then use the resize on the right border and drag it
> across your screen really fast, and drag it back, repeat that.  You see the
> Content area is painting grey first, and the chrome is painting white first.

I've noticed this as well, it's new in 4.0. File a bug with a screen cap maybe? This was present before the titlebar code landed. Might have something to do with 3d accel or layers.
Summary: UI is gray on startup of browser → Browser client area is doesn't paint when restoring to maximized state
I get a gray and white folder looking image on start up of Minefield. This has been going on for weeks. After I restart my PC, I have to stare at this for upwards of 40 seconds before Minefield finally starts. This is really annoying and should be fixed as soon as possible.
To comment 38, below is what I see after I restart my windows 7 8GB ram X64 PC.


file:///D:/Documents/Camtasia%20Studio/Minefield%20Startup/Minefield%20Startup.html
Sorry but this is to comments 38 and 39. You should be able to view this start up video:

http://s20.photobucket.com/albums/b243/TK-1913/?action=view&current=MinefieldStartup.mp4
Summary: Browser client area is doesn't paint when restoring to maximized state → Browser client area doesn't paint when restoring to maximized state
We recently landed bug 130078, which removed sub widgets from the main view. Curious if that work affected this bug?
(In reply to comment #40)
> Sorry but this is to comments 38 and 39. You should be able to view this start
> up video:
> 
> http://s20.photobucket.com/albums/b243/TK-1913/?action=view&current=MinefieldStartup.mp4

What version of fx 4.0 was this Gary? Have you tried a latest nightly?
(In reply to comment #41)
> We recently landed bug 130078, which removed sub widgets from the main view.
> Curious if that work affected this bug?

I still see this problem in the latest nightlies.  I'm currently using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre
(In reply to comment #43)
> (In reply to comment #41)
> > We recently landed bug 130078, which removed sub widgets from the main view.
> > Curious if that work affected this bug?
> 
> I still see this problem in the latest nightlies.  I'm currently using
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100830
> Firefox/4.0b5pre

On an win7 aero desktop you see this? Can you describe what you're seeing?
This is what I'm seeing every time I startup Firefox.  I'm using Win7 x64 with Aero on.
(In reply to comment #45)
> Created attachment 470492 [details]
> Grey UI on FF startup using Win7 Aero
> 
> This is what I'm seeing every time I startup Firefox.  I'm using Win7 x64 with
> Aero on.

I would clarify that the length of time this white/grey pattern shows up seems to be directly proportional to how many tabs/app-tabs FF is restoring on startup.  But, even on a fresh profile with only one blank tab open, it still appears for a brief amount of time.
Sorry for the bugspam, but I thought this was important to capture:

This is what I see when Firefox starts up and is restoring a single blank tab with a brand-new fresh profile with no extensions on the latest nightly.  As you can see, getting the screenshot was hard, as the grey/white UI only shows up briefly as Firefox opens to maximized mode (that's the reason for the strange transparency and trapezoidal shape of the window - I captured this in mid-maximization).  But, the problem gets much, much worse as more tabs have to be restored, to the extent that the grey/white UI sits on screen in maximized mode for a second or two before the normal Firefox UI and content appears.
I wonder if this is triggered by session restore somehow. If I open fx, maximize it, close it, and launch again, the window opens in the maximized state. I don't see a window transition from normal to maximized.
Comment on attachment 470492 [details]
Grey UI on FF startup using Win7 Aero

I see something like this when starting up on win7 with aero and firefox maximized using nightlies that have 130078.
(In reply to comment #48)
> I wonder if this is triggered by session restore somehow. If I open fx,
> maximize it, close it, and launch again, the window opens in the maximized
> state. I don't see a window transition from normal to maximized.

I'm not sure that the window is transitioning from normal to maximized, I think that the effect that I captured is simply Windows 7 animating the window opening.  If I turn off the animation (Control Panel > System > Advanced System Settings > Advanced > Performance > Settings > Visual Effects > Animate windows when minimizing and maximizing), the grey UI appears instantly in maximized mode without the animation.
(In reply to comment #28)
> I know we've seen the white area in bug about resizing a window always revealed
> the same white rectangle, so correlate that with another example i just saw was
> if I had a window open long and skinny, it showed up in the grey area as white
> rectangle in the same area.
> 
> The white area seems to still be related to previous or prior windows dimension
> paints being open before the main window displays.

Actually, this seems to hit the nail on the head for me.  The white area is exactly the size/position of the Firefox window if it is in normal (non-maximized) mode.  So, Jim, you may be right that it has something to do with the window being maximized upon startup.
Has anyone tried tweaking the initial paint refresh timer? In about:config, search for paint. (nglayout.initialpaint.delay) I think the default is around 250 msec.
(In reply to comment #52)
> Has anyone tried tweaking the initial paint refresh timer? In about:config,
> search for paint. (nglayout.initialpaint.delay) I think the default is around
> 250 msec.

I just tried values from 0 to 500, and it made no difference.
You might also want to try a very large value like 10000 to see if it makes the problem appear for longer maybe.
So, with 0, it was ~2 seconds of grey/white UI, and with 10000, it might have been slightly longer (maybe ~3 seconds?).
I think Dale mentioned this as well. If you shrink your window up into a small rect, then maximize, close, and launch, the white block is the size of the small normalized window.

So we are definitely sizing the content area to some default, then resizing the window and content to maximized. But for some reason the two are out of sync, and we get the weird gray outer area with the white inner block. 

I'm pretty sure the second resize comes from nsXULWindow's OnChromeLoaded handler.
Another interesting question - if we delay our own painting using the refresh timer, where is this gray and white background getting painted?
Is there a place defined somewhere that should be grey?  If could somehow change the color to white that would even make it less noticeable.
I always thought this bug was for the grey/white start-up issue. I apologise for my ignorance regarding that. Will that stuff now be handled by this bug or will a new one be filed?
(In reply to comment #59)
> I always thought this bug was for the grey/white start-up issue. I apologise
> for my ignorance regarding that. Will that stuff now be handled by this bug or
> will a new one be filed?

That's what this bug is about, we've just had some other slow startup issues mixed in a bit. But this bug is about exactly what you mention - gray/white blocks and the fact that they show up initially instead of chrome/content.
SetSizeMode(0)
SetSizeMode(0)
SetSizeMode(0)
SetSizeMode(0)
Move(604, 248)
SetSizeMode(0)
SetSizeMode(0) -> normal
Resize(374, 430, 1)
ResizeClient(0, 0, 358, 422, 0)
ResizeClient(0, 0, 358, 422, 0)
Show(1)
SetSizeMode(2) -> maximized
ResizeClient(0, 0, 2560, 1568, 0)
Show(1)

Hmm, we do get a resize while visible before setting the size mode. I'll have to track down who is making these calls.
Attached patch nix gray patch v.1 (obsolete) — Splinter Review
Attached patch nix gray patch v.1 (obsolete) — Splinter Review
w/o the rtl code from another patch.
Attachment #471625 - Attachment is obsolete: true
I'll have try builds here in a bit if anyone would care to test.
I'll be happy to test whenever you have the win builds!
Well, this resizes faster, still gray background, but this looks like it regresses several bugs, it would be a return to the little white box rectangle on startup bug where the firefox menu is and the paint isn't updated so cursor shows up while editing a textbox as I can type faster than the cursor paints.
(In reply to comment #67)
> the paint isn't updated so cursor
> shows up while editing a textbox as I can type faster than the cursor paints.

You can probably just ignore this, as this actually looks like fallout from initial landing of bug 240933 based on comments there.
(In reply to comment #67)
> Well, this resizes faster, still gray background, but this looks like it
> regresses several bugs, it would be a return to the little white box rectangle
> on startup bug where the firefox menu is and the paint isn't updated so cursor
> shows up while editing a textbox as I can type faster than the cursor paints.

Hmm, I see the little white box in the initial paint too. :( It's basically the same thing, but since I'm not resizing the window to persisted size the white block is smaller, but still there.
(In reply to comment #69)
> (In reply to comment #67)
> > Well, this resizes faster, still gray background, but this looks like it
> > regresses several bugs, it would be a return to the little white box rectangle
> > on startup bug where the firefox menu is and the paint isn't updated so cursor
> > shows up while editing a textbox as I can type faster than the cursor paints.
> 
> Hmm, I see the little white box in the initial paint too. :( It's basically the
> same thing, but since I'm not resizing the window to persisted size the white
> block is smaller, but still there.

Pushed another patch to try that gets rid of the gray.
(In reply to comment #70)
> (In reply to comment #69)
> > (In reply to comment #67)
> > > Well, this resizes faster, still gray background, but this looks like it
> > > regresses several bugs, it would be a return to the little white box rectangle
> > > on startup bug where the firefox menu is and the paint isn't updated so cursor
> > > shows up while editing a textbox as I can type faster than the cursor paints.
> > 
> > Hmm, I see the little white box in the initial paint too. :( It's basically the
> > same thing, but since I'm not resizing the window to persisted size the white
> > block is smaller, but still there.
> 
> Pushed another patch to try that gets rid of the gray.

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-ce5092626834/

This new build is better, I don't see gray at all.  Though I'm not sure if resizing is slower or maybe choppy, probably need a few eyes to test it.
Attached patch nix gray patchSplinter Review
Simple fix. The first child widget we removed had a default background of white. With that gone, we see much more of our default background color, which was gray.
Attachment #471626 - Attachment is obsolete: true
Attachment #472640 - Flags: review?(neil)
Comment on attachment 472640 [details] [diff] [review]
nix gray patch

This line dates back to the original version on 1998-12-03, so I have no idea why those particular values were used. Nor do I see why this needs to be special-cased on Windows. I suggest just changing the values and adding a comment to explain why you want to specify a white background.

By the way, I'm still noticing on my builds that maximised windows open at restored size and then maximise themselves. I thought there was a bug on that?
Attachment #472640 - Flags: review?(neil) → review+
(In reply to comment #73)
> Comment on attachment 472640 [details] [diff] [review]
> nix gray patch
> 
> This line dates back to the original version on 1998-12-03, so I have no idea
> why those particular values were used. Nor do I see why this needs to be
> special-cased on Windows. I suggest just changing the values and adding a
> comment to explain why you want to specify a white background.
> 
> By the way, I'm still noticing on my builds that maximised windows open at
> restored size and then maximise themselves. I thought there was a bug on that?

One of the obsolete patches here tried to address that. In xul window, the code positions and resizes the window, then sets persisted attribs which include size mode. I would still like to land that but I'll file it in another bug.
http://hg.mozilla.org/mozilla-central/rev/b96de58efb5d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
OK...with the latest hourly (with this patch), the grey is gone (yay!), but now I get a completely white screen for 1-2 seconds when I open Firefox.  It seems that the basic problem still hasn't been resolved (regardless of color).
(In reply to comment #76)
> OK...with the latest hourly (with this patch), the grey is gone (yay!), but now
> I get a completely white screen for 1-2 seconds when I open Firefox.  It seems
> that the basic problem still hasn't been resolved (regardless of color).

This related to opening to the maximized state, or in general?
In general.
(In reply to comment #78)
> In general.

Do you see it with the menu bar enabled?
Yes, it covers everything from status bar to menu bar.
(In reply to comment #80)
> Yes, it covers everything from status bar to menu bar.

How does the behavior compare with 3.6?
I think I see what you're talking about. In 3.6, the initial paint seems to happen before the window fades in, but in 4.0, it seems to be delayed until after, so I see the white background briefly before content fills in.
Isn't this causing slow cold start?
(In reply to comment #83)
> Isn't this causing slow cold start?

We don't have ts cold for 3.6 on winnt 6.1, but as far as ts is concerned, the two branches match up. So this seems to have something to do with initial painting.

I went back and tested a few older builds. I see the delayed initial paint all the way back to an alpha in feb.. Having the titlebar enabled seems to make this easier to notice, since the white area stretches all the way to the top of the window.

I'll file this in a new bug.
Blocks: 594821
Jim, Did you file a bug for comment 74?
(In reply to comment #85)
> Jim, Did you file a bug for comment 74?

bug 594821
(In reply to comment #86)
> (In reply to comment #85)
> > Jim, Did you file a bug for comment 74?
> 
> bug 594821

ah, sorry. no not yet. will file and post back.
(In reply to comment #87)
> (In reply to comment #86)
> > (In reply to comment #85)
> > > Jim, Did you file a bug for comment 74?
> > 
> > bug 594821
> 
> ah, sorry. no not yet. will file and post back.

bug 594881
While this has fixed the grey. I'm seeing a long (duration) white screen.
(In reply to comment #89)
> While this has fixed the grey. I'm seeing a long (duration) white screen.

same here
(In reply to comment #90)
> (In reply to comment #89)
> > While this has fixed the grey. I'm seeing a long (duration) white screen.
> 
> same here

Possibly a dupe of bug 594821? Can you try disabling jump list updates to see if it helps. (browser.taskbar.lists.enabled -> false)

If that doesn't help, we also isolated a delayed paint issue in bug 594821. Maybe you could test a few older builds to see if this is the same regression I'm seeing?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/05/

May 23 was when this showed up.
(In reply to comment #61)
> SetSizeMode(0)
> SetSizeMode(0)
> SetSizeMode(0)
> SetSizeMode(0)
> Move(604, 248)
> SetSizeMode(0)
> SetSizeMode(0) -> normal
> Resize(374, 430, 1)
> ResizeClient(0, 0, 358, 422, 0)
> ResizeClient(0, 0, 358, 422, 0)
> Show(1)
> SetSizeMode(2) -> maximized
> ResizeClient(0, 0, 2560, 1568, 0)
> Show(1)
> 
> Hmm, we do get a resize while visible before setting the size mode. I'll have
> to track down who is making these calls.

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

Attachment

General

Creator:
Created:
Updated:
Size: