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

RESOLVED FIXED

Status

()

Core
Widget: Win32
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Assigned: jimm)

Tracking

({regression, relnote})

Trunk
x86
Windows 7
regression, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(7 attachments, 2 obsolete attachments)

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

Comment 4

7 years ago
(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
Is this fixed now?

Comment 6

7 years ago
(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.
(Assignee)

Comment 8

7 years ago
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...

Comment 10

7 years ago
Created attachment 455007 [details]
Screenshot of Minefield startup issue
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! :)
Created attachment 455035 [details]
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.
Created attachment 455047 [details]
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

Updated

7 years ago
Component: Layout → Widget: Win32
QA Contact: layout → win32
(Assignee)

Updated

7 years ago
Blocks: 576096
No longer blocks: 513162

Comment 17

7 years ago
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.

Comment 18

7 years ago
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.

Updated

7 years ago
Depends on: 577208
blocking2.0: final+ → beta2+
(Assignee)

Updated

7 years ago
Blocks: 513162
No longer blocks: 576096
blocking2.0: beta2+ → betaN+

Comment 19

7 years ago
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.

Comment 20

7 years ago
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

Comment 21

7 years ago
Created attachment 460820 [details]
Firefox 4 Beta loading image

Comment 22

7 years ago
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.

Comment 23

7 years ago
(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.
(Assignee)

Comment 24

7 years ago
This may be addressed by the patch in bug 579421. Will have to wait to see once it lands.

Comment 25

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

Comment 27

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

Comment 29

7 years ago
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.

Comment 33

7 years ago
I get a mass of grey and a white bit on every start. The size of the white bit differs.
(Assignee)

Comment 34

7 years ago
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?
(Assignee)

Comment 35

7 years ago
(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.
(Assignee)

Comment 37

7 years ago
(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.
(Assignee)

Updated

7 years ago
Summary: UI is gray on startup of browser → Browser client area is doesn't paint when restoring to maximized state

Comment 38

7 years ago
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.

Comment 39

7 years ago
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

Comment 40

7 years ago
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
(Assignee)

Updated

7 years ago
Summary: Browser client area is doesn't paint when restoring to maximized state → Browser client area doesn't paint when restoring to maximized state
(Assignee)

Comment 41

7 years ago
We recently landed bug 130078, which removed sub widgets from the main view. Curious if that work affected this bug?
(Assignee)

Comment 42

7 years ago
(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?

Comment 43

7 years ago
(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
(Assignee)

Comment 44

7 years ago
(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?

Comment 45

7 years ago
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.

Comment 46

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

Comment 47

7 years ago
Created attachment 470501 [details]
Grey/white UI flashes briefly as Firefox starts up with one blank tab being restored

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

Comment 48

7 years ago
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.

Comment 50

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

Comment 51

7 years ago
(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.
(Assignee)

Comment 52

7 years ago
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.

Comment 53

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

Comment 55

7 years ago
So, with 0, it was ~2 seconds of grey/white UI, and with 10000, it might have been slightly longer (maybe ~3 seconds?).
(Assignee)

Comment 56

7 years ago
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.
(Assignee)

Comment 57

7 years ago
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.

Comment 59

7 years ago
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?
(Assignee)

Comment 60

7 years ago
(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.
(Assignee)

Comment 61

7 years ago
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.
(Assignee)

Comment 62

7 years ago
Created attachment 471625 [details] [diff] [review]
nix gray patch v.1
(Assignee)

Comment 63

7 years ago
Created attachment 471626 [details] [diff] [review]
nix gray patch v.1

w/o the rtl code from another patch.
(Assignee)

Updated

7 years ago
Attachment #471625 - Attachment is obsolete: true
(Assignee)

Comment 64

7 years ago
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!
try build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-8292376a5d27/
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.
(Assignee)

Comment 69

7 years ago
(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.
(Assignee)

Comment 70

7 years ago
(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.
(Assignee)

Comment 72

7 years ago
Created attachment 472640 [details] [diff] [review]
nix gray patch

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+
(Assignee)

Comment 74

7 years ago
(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.
(Assignee)

Comment 75

7 years ago
http://hg.mozilla.org/mozilla-central/rev/b96de58efb5d
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 76

7 years ago
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).
(Assignee)

Comment 77

7 years ago
(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.
(Assignee)

Comment 79

7 years ago
(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.
(Assignee)

Comment 81

7 years ago
(In reply to comment #80)
> Yes, it covers everything from status bar to menu bar.

How does the behavior compare with 3.6?
(Assignee)

Comment 82

7 years ago
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?
(Assignee)

Comment 84

7 years ago
(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.
(Assignee)

Updated

7 years ago
Blocks: 594821
Jim, Did you file a bug for comment 74?
(Assignee)

Comment 86

7 years ago
(In reply to comment #85)
> Jim, Did you file a bug for comment 74?

bug 594821
(Assignee)

Comment 87

7 years ago
(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.
(Assignee)

Comment 88

7 years ago
(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

Comment 89

7 years ago
While this has fixed the grey. I'm seeing a long (duration) white screen.

Comment 90

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

same here
(Assignee)

Comment 91

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