Closed Bug 535212 Opened 15 years ago Closed 11 years ago

Content area briefly disappears during startup but the chrome does not.

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: u88484, Unassigned)

References

Details

(Keywords: regression) 

The content area briefly disappears for approximately a half second during startup but the chrome does not.  This does not happen with a new profile and does still happen with/without plugins enabled.
i *believe* this regressed within http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2eb351cc47d3&tochange=6628da386550 and it's trunk only (i didn't see this in Fx3.6b5).

can you check against that range (builds 11-11/11-12)?
Confirmed that is the regression range.
Flags: blocking-firefox3.6?
Keywords: regressionwindow-wanted
Flags: blocking-firefox3.6?
Ok, my guessing on the cause points to Bug 528002 - all the others in that range either landed on 1.9.2 too, are tests or affect "non-general-layout" (places, svg, ...) components.

somebody can bisect? :)
I'm not quite sure how to even reproduce, given comment 0.  Any hints?  What am I looking for?  What do I need to have in my profile?  Is this Windows-only, or should I be able to see it on Mac, say?
Blocks: 528002
it's a windows 7 & trunk only issue as of yet & happens using a clean profile upon starting Firefox.
it's a bit hard to describe but a "flickering" of the viewport loading the prerelease site, whilst the chrome elements (menus, toolsbars, status bar) are being populated, is noticeable. maybe a slowed down screencast of this could help, let's see ....
Sometimes my startup is very slow (lots of tabs or something else causing startup to be very slow) and I see that the chrome also does not show for a while on top of the content area.  The title bar is instantaneous in both cases; comment 0 and the aforementioned slow startups.
Perhaps this is related: the telephone number in this page is briefly shown, then disappears: http://www.mecenatepalace.com/en/contacts/contacts-e-mail-telephone.htm
This happens on my Windows 7-x64 and FF 3.6 but not with 3.5x or 3.7 nightlies.
OK.  Can someone who can reproduce this try actually bisecting on the checkins in that range?  I suspect bug 259636 is a much more likely "regression" cause than bug 528002 (and in particular is a change that comment 3 seemed to miss).  Also note that there were windows widgetry changes in that range; dunno whether they might be relevant.
Boris, I'm not sure how to bisect.

I can not reproduce this on a new profile but no matter what I do with my existing profile I can always reproduce this.  I've taken every preference out of prefs.js, user.js, reset the toolbars back to the default set.  I don't know what else to try to figure out what exact is causing this.
It happens in safe mode with your old profiles?

With a new profile, does it happen on the second startup?

Bisecting involves compiling the browser locally; probably best saved for after we've sorted out the profile issue.
(In reply to comment #10)
> It happens in safe mode with your old profiles?
> 
I copied my entire profile to another, started in safe mode and one by one used each safe mode options while restarting in between.  Each time I can still reproduce this bug even after resetting everything that safe mode allows me to do.

> With a new profile, does it happen on the second startup?
> 
Yep
Does deleting or moving out of the way XUL.mfasl make the issue go away for one startup?
(In reply to comment #12)
> Does deleting or moving out of the way XUL.mfasl make the issue go away for one
> startup?

Delete that file does indeed fix the issue for only one startup.
OK, so that sounds like a timing issue for cases where we fastload the chrome.

Kurt, if I spun up a try server build from between those two nightlies, would you be willing to try it out to see whether that build shows the problem?
(In reply to comment #14)
> Kurt, if I spun up a try server build from between those two nightlies, would
> you be willing to try it out to see whether that build shows the problem?
Sure thing, not a problem.
(In reply to comment #16)
> Kurt, the builds to try are at
> https://build.mozilla.org/tryserver-builds/bzbarsky@mozilla.com-try-46b03a0112d6/
Nope, still no luck.  Even if I delete xul.mfl I still have the problem even on the first startup.
(In reply to comment #18)
> OK.  What about the builds at
> http://build.mozilla.org/tryserver-builds/bzbarsky@mozilla.com-try-c95eaf5e2a00
> ?

Still the same result before and after deleting the xul.mfl file and subsequent startups.
OK.  That first build was from rev 09df1b07d7f1 (checkin for bug 528002).  The second one was from rev 678e3c57654a (checkin for bug 678e3c57654a).

Let me spin up another build from the changeset before that.
(In reply to comment #21)
> Kurt, what about the build at
> https://build.mozilla.org/tryserver-builds/bzbarsky@mozilla.com-try-49efc4266052/
> ?

I have not been able to reproduce it using this build :)
OK.  What's your homepage, if I might ask?
(In reply to comment #23)
> OK.  What's your homepage, if I might ask?

It is set as http://www.mozilla.org/projects/minefield/ but I have firefox set to show my windows and tabs from last time.
Just tested all three again with: yahoo.com, gmail, facebook.com, neowinnet, and a bugzilla page open (my usual pages that I have open when I close and reopen Firefox) and confirmed that the tryserver build https://build.mozilla.org/tryserver-builds/bzbarsky@mozilla.com-try-49efc4266052/ is the only one that works.

So bug 259636 definitely caused this bug.
Ok, but in the new profile that was also showing the bug, what was it?

And more importantly, does the bug show up no matter what the homepage is?

It sounds like the sync value set on _some_ text control was hiding the bug, since the fix for bug 259636 is what caused it to start happening.
Blocks: 259636
No longer blocks: 528002
And I bet if we made the whole mess with disabling viewmanager refresh during pageload go away this problem would too.
I think Timothy is planning to do that.
Yes, I am working on it.
Here are builds that can be tested to see if comment 27 is right about the problem.
https://build.mozilla.org/tryserver-builds/tnikkel@gmail.com-try-62d9a8393ce9/
for me none of the tryserver builds fixes the issue and i went sure deleting the "XUL.mfl" in my test profile each run.

worth to mention is that when i run the 11-11 build against a profile created by a later build inluding a XUL.mfl created by the later build, the bug occures also in the 11-11 build.
so i presume something new written to and/or read from this file after the 11-11 build causes the issue to happen regardless what builds you run it against.
Interesting.  Very interesting....

Is there someone who can reproduce this locally _and_ build to make it faster to bisect the problem?  The try server builds take approximately forever.
Henrik, can you help out here concerning comment 32?
Keywords: qawanted
Sorry, but I do not have a build setup on Windows. So I can't help in bisecting this problem.
I'd reproduce this problem on Nightly 3.7a1 from (2009-12-16) but it looks to be fixed on both Latest Nightly (2013-01-27) and FF 19b3 on Windows 7 x64. 

Should this be Resolved WFM as long as it's not reproducing anymore on latest verions of Nightly and Beta?
If anyone can reproduce this issue on current builds, please reopen this bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.