Closed Bug 181293 Opened 21 years ago Closed 21 years ago

Browser draws gray instead of toolbars if new window is opened with focus in an outliner


(Core Graveyard :: GFX, defect)

Not set


(Not tracked)



(Reporter: mikepinkerton, Assigned: sfraser_bugs)



(Keywords: qawanted, testcase, Whiteboard: [adt1] fixed1.3)


(8 files, 1 obsolete file)

2002112103 build, osx 10.2.2

- lauch moz
- open mail
- open mail compose window
- close window
- open browser, maybe two

you'll see gray where the toolbars should be. sometimes closing and reopening
will cause it to be ok, usually not. browser basically useless from now on.
I've seen this too. It must be a compositor issue.
Component: Browser-General → GFX Compositor
i just tried it, it doesn't matter what screen the window opens on. it happens
on both.
reassign for real, even
Assignee: asa → kmcclusk
QA Contact: asa → ian
tracy, are you able to duplicate this bug? thx.
There haven't been any changes checked into nsViewManager.cpp, nsView.cpp, or
mac/widget/nsWindow.cpp recently.
I can not reproduce this
it's 100% repro for me.
on kin's suggestion, i tossed my chrome dir, and it made no difference. note
that you may have to open more than one browser window after opening and closing
mail compose.

i'm also in the classic skin, not sure if that would make a difference.
here's an image of what i get opening a browser after i open mail compose.
Using 20002112108 release build, I dont see this issue.
Pinkerton, are you seeing this only in debug?
mozilla opt bits off sweetlou. i don't even have a recent trunk debug build.
this does happen with a brand new profile.
Dcone, can you please look inot this? 
Assignee: kmcclusk → dcone
I can reproduce in the 2002112108 Mozilla CFM build found on sweetlou anytime I
give focus to a window with a tree widget/outliner. For example, if I give focus
to the folder pane in mail/news and hit apple+N the toolbar is gone in the new
browser window however if I do the same while focus is in the message preview
window, the toolbar shows. The same happens if I do apple+N while I give the
history tree widget in the sidebar focus. This seems like a tree/outliner widget
focus problem to me.
Yep, I see the issue with Peter's test case. With focus being in the outliner, I
can reproduce this consistently.
(possibly related?)  The last few days I have occassionally seen big grey updates 
to composer windows when I am shortening a document via editing.  Instead of 
scrolling the bottom of the document down to the bottom of the window, I 
sometimes get no scroll and a gray area in the "dead" region of the document.

I don't have a reproducible case yet, but I have seen this several times.
cc:ing suspicious checkins owners from hook (bryner, timeless, bz, heikki): 
please take a look at your checkins

petersen says he may have seen this before today too....
RE: Comment #16 - I've seen similar cases of this in the content area of the
browser window in both Mozilla 1.2b and Chimera 0.6. The browser window is drawn
correctly, but instead of document content, the content area shows up solid
grey. I've even seen this happen to a couple of dialogs (Mozilla only). No solid
method to reproduce; this did not occur before 10.2.2 update (I wrote it off as
a bug from Apple's fix for web browser rendering issues).
happens in 2002112008 too
QA: can you pull builds to narrow down when this first starting happening. Thanks!

I think this should be downgraded as it only happens if an outliner has focus.

I'm using Mac OSX 10.2.2
My changes only affect serialization, and the instructions on reproducing this
don't call into the code that I changed yesterday (tested by placing
breakpoints, on Windows only but it shouldn't matter).
(bryner, timeless, bz, heikki) peterl determined that this bug exists in
yesterdays build, so this bug probably has nothing to do with your recent checkins.

I'm downgrading this bug to critical.
Severity: blocker → critical
Keywords: qawanted
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
This has been happening for more than just a few days. Dup of bug 175939?
Bug 175939 says this was happening in 2002101612. sweetlou has OSX daily Mozilla
builds since May. Can someone pull builds to narrow when this happened:
Severity: critical → blocker
Priority: P1 → --
Summary: Browser draws gray instead of toolbars → Browser draws gray instead of toolbars if new window is opened with focus in an outliner
Target Milestone: mozilla1.3alpha → ---
This doesn't sound like gfx, --->punting to XP Toolkit: Trees
Assignee: dcone → varga
Severity: blocker → critical
Component: GFX Compositor → XP Toolkit/Widgets: Trees
Priority: -- → P1
QA Contact: ian → shrir
Target Milestone: --- → mozilla1.3alpha
Re: comment 16, I think that could be bug 155013, jfrancis.
Severity: critical → blocker
Component: XP Toolkit/Widgets: Trees → GFX Compositor
Priority: P1 → --
Target Milestone: mozilla1.3alpha → ---
FWIW, WFM under Mac OS 9.2.2 running trunk build 2002112008.

Apparently a Mac OS X issue.
Is this bug still a smoketest blocker? Comment #21 suggests not, however I see
it still is marked as such (maybe a mid-air collision changed things back again?).
well, it makes the app unusable. i'd say it's a smoketest blocker.

fwiw, I have been seeing the gray like jfrancis says for well over a month in
composer windows. i think it's related, but not directly to this issue.
The main reason I asked about this bugs blocker status is that the tree was
opened yesterday without this bug being fixed. I thought that a Smoketest
Blocker is meant to keep the treee closed?
okay, the reason this is not beiong seen at all in smoketests is because I test
the commercial tree. It is not reproducable on the commercial tree. 

It's reproducable on Mozilla using steps in comment #14
workaround by not using apple-N to open new window....use the File | New |
Navigator Window

I haven't been able to get the greyed out window using the menu; only seeing
this using the keyboard shortcut.
there are plenty of workarounds, but this seems pretty lame (even if most people
aren't hitting it, probably because of different usage patterns than pink ;).

I'm going to hold the tree today until someone takes it. How many people have
debug OSX trees to work on these days?
Could someone try to narrow it down to a specific build when it started to happen ?
I would try by myself, but my connection is not so speedy, it would take ages
for me.
Could this be related to bug 180814 ?
Ok, I can reproduce it with build 2002112103 build, Mac OS X 10.2.2
Both Modern and Classic are affected.

I found another steps to reproduce it:
- unset "Check for new messages at startup" for you account
- launch mail again, account central shows.
- folder pane doesn't have a focus ring
- command+N
2002111903 is affected too
trying 2002111703, nsTreeBodyFrame was modified that day (bug 147887)
since this doesn't *technically* block smoketests, and there are workarounds,
and there is someone tracking this down now, removing smoketest keyword.
Keywords: smoketest
Mach-O builds seem to work fine.
2002111703 is affected too
Could it be 10.2.2 update ? I've seen similar problem with native Mac apps
Could someone try on Mac OS X prior to 10.2.2 ?
2002111503 is fine
Ok, I narrowed it down to 2002111503-2002111703.
There is no such build 2002111603 :(
Could some Mac guy take a look now ? I don't have access to a CFM build
environment, only Mach-O
I've seen this in Macho builds, on 10.2.2.
So, is this a different problem than bug 175939?
I'm not able to reproduce it with disabled XUL cache and fastload

bug 177401 looks suspicious:

Boris, Alec any ideas ?
any update on this? it makes the trunk close to impossible to use.
*** Bug 175939 has been marked as a duplicate of this bug. ***
Something mentioned in Bug 175939 that I don't see anywhere in the comments here:

This shows up for me sometimes as an apparent failure to load a new page. If I
click on a link, Mozilla simply doesn't redraw the content area and it looks
like the new page hasn't loaded. However, the new page actually has loaded
because links on the old page don't work anymore and the scrolling distances are
those of the new page. In this case, the grey doesn't show up until I somehow
make Mozilla redraw the content area. I can do this by switching to a different
tab and back, or by scrolling down (in which case the newly-appearing portions
of the window show up as grey and the content from the previous page continues
to show above).
correct, i see both behaviors, including standalone mail windows failing to
render their content areas. for that reason i'm not certain if they are 100%
dupes, but perhaps close enough.
nominating to block 1.3a. 
Flags: blocking1.3a?
Is this reproducable after removing the fastload file?
I'm not able to reproduce it with disabled XUL cache.
Disabling just XUL fast load doesn't help.
Flags: blocking1.3a? → blocking1.3a-
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b+
I wonder if bug 181987 may also be related.
* Give focus to the folder pane in mail/news
* Hit apple+N 

Result: the toolbar is gone in the new browser window

Alternate Way:
- unset "Check for new messages at startup" for your account
- launch mail again, account central shows.
- folder pane doesn't have a focus ring
- command+N

Keywords: testcase
I can't get this to happen in any reproducible manner, but it almost always happens at 
least once during long-term use.

The content area of the browser, mail/news, dialogs, etc. goes gray.  In the case of the 
content area of the browser, I've seen cases where the window does not redraw (as 
reported in comment #48), and an explict invalidate has to happen to show gray, as well 
as the window simply rendering in gray (as with a new page load).  In these cases, a 
Reload of the browser will almost always cause the problem to clear up.

Today I saw it in the mail compose window, where the toolbars (including the addressing 
pane) were gray.  In this case, closing and reopening the window did not solve the 
problem (the XUL caching, as described above), but opening a new compose window 
(while the problematic window was on screen), did render properly.  Subsequent mail 
compose windows then were fine.

The most problematic time is if it occurs when dialogs are brought up; particularly 
security dialogs.  In many cases, these can not be dismissed and therefore render that 
window unusable.  Closing the window with the close box doesn't have any effect, and 
quitting the browser will close all windows, and Mozilla will then terminate abnormally.

I don't recall seeing this behavior before moving to Jaguar, but I know I was seeing it in 
Mozilla 1.1, 1.2, and it still happens in 1.2.1.
May be related to <a href="show_bug.cgi?id=#184972" title="Alert box is plain
grey w/no text.">Bug #184972</a>.
Forgot to mention my system specs: Mac OSx 12/16 trunk build
Attached image Yet Another Screenshot
This might be getting worse - I got this immediately after downloading
2002122708. As you can see from the screenshot, the entire browser window is
gray with the exception of the scrollbars on the selection lists. I'm using the
"Pinstripe" theme. This is the first time I've seen this particular behavior
with only some elements of the page drawn. 

My exact steps were this:
1. Delete old mozilla 1.3a including folder
2. Copy over new build to Applications folder
3. Start up Mozilla ( is home page)
4. Start to type but choose it from the autocomplete list
5. Click the link to see what bugs were reported today
6. Click the link to log in, and allow the security device to fill in the
7. Submit the form.

I have not yet tried to reproduce it by following those exact steps, but my
guess is that it will NOT happen again.
What is needed in order to make progress on this? Do the users who are seeing
this need to provide more information or work further to reproduce it? This is
an extremely annoying bug and has occasionally caused very serious problems for
me. In a few cases, the behavior I described in Comment #48 occurred after
submitting a form. I had no way to see what the result of the form was, and the
only way to try again would be to reload, which would repost the form. Not a
viable solution with many/most forms. 

I want to help this get solved. What needs to be done?
ccing jrgm at brendan's request.
QA Contact: shrir → petersen
Nav triage team: nsbeta1+/adt1
Whiteboard: [adt1]
A new observation, and I have been able to reproduce it, this time using
2003012003. This may be a completely different bug however.

1. Open a new mail message (command-shift-m)
2. Paste in or type in some text, more than long enough to create a vertical
scroll bar
3. Delete some text from the very bottom of the message (leave enough to still
have a scroll bar)

The result is a gray band of non-existent space at the bottom of the message.
Clicking it or scrolling immediately causes the message window to adjust, so
it's not dead space like we get at other times, but it is the same gray. 
The same thing happens in Composer.
Thanks for the steps. Can you still repro if you quit and restart Mozilla, and
do the steps again?
The problem described in comment 62 is different, and is already filed as bug
It does seem something like that bug, and yet different. The chrome is not
changing at all using my steps, but the amount of content in the window is
changing which makes it somewhat more like this bug. 

Yes, it does persist over a restart, and is happening in 2003012103 and
2003012213. However I tried it on a different machine running 2003012103 and
could not reproduce it there. Both machines are Mac OS X 10.2.3. Oddly, after
trying to reproduce this on the second machine and failing, that machine had a
case of gray windows like I've never seen before sometime later the same day
(and in the same session of running Mozilla), affecting both the Navigator
window and the new mail compose windows to the point where I could not create a
new mail message prior to quitting and restarting Mozilla. I run Mozilla all day
without break there.
I doubt that this is fixed.
earlier today I opened the find window and it was completely gray (osx/macho
debug build from today).  I might have been testing a commercial tree or
mozilla; I'm not sure.  I don't see it at the moment.

The find window is particularly bad because it has no close box and I couldn't
get rid of the window until I quit.
I also saw a mostly-grey Prefs window yesterday using FizzillaMach/2003012503.
*** Bug 184972 has been marked as a duplicate of this bug. ***
Could someone confirm that he/she saw it with a clean profile ?
I'm not sure but I suspect you can have corrupted fastload file.
I just checked brendan's patch which has been chacked in and it seems he didn't
increase xul fast load version number, so fastload files are not invalidated in
newer builds. Brendan, can you confirm that ?
I can be completely wrong, but it's really hard to reproduce this bug.
Is it ok to just delete the XUL Fastload file and try it after that? I can make
a clean profile, but I'd prefer just moving the suspect piece out of the way and
keeping all my prefs and cookies and bookmarks and stuff. (I don't mind browsing
without them for a while, but it may take an entire evening of browsing to hit
on the bug and it would be a pain to go that long without all my settings).
Yeah, just remove 'XUL Fastload file' or 'XUL.mfasl' or both
> I just checked brendan's patch which has been chacked in and it seems he 
> didn't increase xul fast load version number, so fastload files are not 
> invalidated in newer builds. Brendan, can you confirm that ?

Brendan is away doing the honeymoon thing.

But to answer your question... a fastload file will be invalidated on any
of the following conditions:
1) the timestamps of and paths to the jar files that were used to generate
   a fastload file do not match exactly the timestamps and paths recorded
   in that fastload file.
2) the checksum recorded in the fastload file does not match the checksum
   computed for that fastload file.
3) the version number (either the fastload-file or the xul-fastload version
   number) embedded in the binary does not match the version number embedded
   in the fastload file.

Basically, condition #1 means that if you run a new daily build, or update
any of the jar files in your own hand build, you will blow away the fastload
file at next startup. condition #2 protects against random disk corruption
(although not against logical corruption). condition #3 protects against 
changes in the format of the file, but in this case, brendan's changes did 
not alter the format of the file, so a change in version number was not 
warranted. [In fact, given #1, the version number test is unlikely to ever 
be invoked, since #1 will destroy the file based on timestamps alone].


But back to comment #12 by pink "this does happen with a brand new profile."
That would basically point away from a fastload issue, no? [Unless pink 
actually meant "doesn't" not "does"].
I really don't think this is a fastload issue. It doesn't hang, it just doesn't
draw correctly. And it's not as if entire UI elements are missing; the dreaded
gray box can cover half of the content area, for example.
I just tested CFM builds 2003011703 and 2003011903
I can't reproduce this bug with build 20030119 (that's after brendan's checkin)
I got a hang with 20030117. It happened multiple times in mailnews when I
clicked on my Inbox.
I found out one thing, the fastload file is invalidated between these builds.
So my previous theory is probably wrong.
On the chance that it's an uninitialized memory bug, has anyone ever run these
builds under a memory debugger like Purify?
I finally was able to reproduce it with my own Mach-o build pulled with
Unfortunately, I couln't reproduce it again.
This bug drives me crazy.
Can some of the Mac developers cc'ed on this bug help ?
I can only repro this in an opt build. Doing an opt-with-symbols build now.
Assignee: varga → sfraser
OK, I've been pushing opt builds around for several hours now, and I haven't
seen this once.  :-\
Ah, that's why I didn't get any bugmail :)
So, you're not able to reproduce it, I still think it may be related to the
fastload problems. John Morrison has checked in another patch which should fix
the fastload problems for good.
Now I recall that I usually saw it when my laptop was quite loaded (by building
mozilla, for example)
1) I'm seeing this intermittedly
2) I'm unable to give a testcase due to the complete randomness of the phenomenom
3) I've seen this behaviour in every type of window and dialogue box:
-- normal browser window
-- select profile at startup dialogue
-- javascpipt messages
-- modal dialog boxes
-- page loads but the old contents is still displayed
-- new window opened through javascript
-- opening a link in a new tab

1) for dialogue boxes either pressing [return] or [esc] usually disposes of the
dialogue box
2) for normal browser windows, reloading the page displayes the contents

I must say, that it's been worse that it is at present.
Actually, I can't remenber having seen this phenomenom in the builds from at
least the last week or so.
Has anybody seen this in builds from the last few days?  If not, should it be
marked worksforme?
I do see it often in 2003012213 (CFM) which is the latest that is available in
the latest builds directory (that seems odd in itself, doesn't it?)
I stopped using Mozilla on my Mac because of this problem. I'll download a new build and try it for a few days.
Re Comment #85, focus seems to have shifted now to the MachO version.
I found out it the hard way a few days ago.  The MachO version is
MUCH faster (at least on my machine) than CFM, but it has some of its
own quircks, too.
The readme with that version says:"This is an experimental Mach-O build of Mozilla for Mac OS X.  This version still has many bugs.  If you are looking for the officially supported Mozilla build for OS X, please download the file mozilla-macosX-trunk.smi.bin.  For more information about the Mach-O build, see"mozilla-macosX-trunk.smi.bin is what I've been using for a long time, but it doesn't seem to exist on the ftp server anymore.
I've just reported the confusion between which build to use and test as Bug 191889
I've been seeing this random grey window on mac osx for weeks; including todays
AM build.  Use the browser long enough, eventually some window/dialog (points to
comment #83) will come up grey.  Close the window and perform the same action
again and the window appears fine.  

I don't recall seeing this on machO.  But don't hold me to that. :-)
Mozilla/5.0   Gecko/20030203
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b; MultiZilla v1.1.33 (a))

I've just had the issue in a bad way :-(((
It reared it's ugly head in 'Select a User Profile' dialogue upon starting
Mozilla. The first time, it went away again when I hit [esc] and restarted
Mozilla. I then went to read my email and saw this last batch, and cliked on the
link to get to this page. Then, Mozilla chrashed. Upon subsequent restarts I got
the grey 'Select a User Profile' dialogue box each and every time. At first I
aborted the startup of Mozilla, but the issue didn't disappear, so I eventually
had to select a profile blindly.
Attached file crash log
this is the chrash log of the chrash that occured between my two session that
started with a gray 'Select a User Profile' dialogue
More grey here with today's build, Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.3b) Gecko/20030204. (Screenshot available on request.)

Sending a form at, the resulting page came grey. (More
precisely, it didn't alter the content area at all; then, scrolling up and down
then filled everything in grey.) Reloading restored some content (as usual), but
also re-sent the form. Not really a good workaround option, if the form is to
transfer $1,000,000...
Using Mach-O build 20030206 I found this bug. But I also discover something :
When I pushed the back button, half of my page gone grey, the other half
remained unchanged. And as soon I move a window over the unchanged part, the
part masked by the window became gray. Also, if I scroll the window up and down,
the unchanged and non-gray part remain unchanged until being masked by another
html frame by scrolling to the very bottom of the page, thus making it gray like
the rest.
It is a redraw buffer failure ? Don't know, but hope this will help !
Yeah, I saw this a couple of times yesterday (never in debuggable builds, grrr).
bumping to final. 
Flags: blocking1.3b-
Flags: blocking1.3b+
Flags: blocking1.3+
Simon, do the debug builds include extra code that makes them run slower than
the regular builds? Could this be a timing problem, where something is happening
too faster than non-debug Mozilla expects?
This could be timing, it could be an optimizer bug or uninitalized variable, or
it could be "fixed" by some debug-only code in debug builds.
*** Bug 192630 has been marked as a duplicate of this bug. ***
FWIW, I just had this happen looking at a bug in Bugzilla, and everything in the
content area was grey *except* the (inactive) scrollbar on the CC SELECT element.
Not sure if this helps any... but when a page "shrinks" on me and I'm already at
the end of the document the void that is created is this same evil gray.

Steps to reproduce: scroll down to the bottom of a long page, then then shrink
your text size.
That's similar to what I observed above, and is really bug 155013

I bet it only happens when using a theme with Aqua scrollbars (i.e., classic).
It seems to be a scrolling issue.
Nope, I see it with modern on 2 machines.
You might want to try commenting out the call to
"AddCoveringWidgetsToOpaqueRegion" in nsViewManager::RenderViews and see if it
makes this problem go away. That's not a fix, just something that might narrow
it down.
*** Bug 184438 has been marked as a duplicate of this bug. ***
*** Bug 175214 has been marked as a duplicate of this bug. ***
*** Bug 184375 has been marked as a duplicate of this bug. ***
Simon, can you test roc's suggestion in comment 104 ? This is the only horrible
mac-specific problem left for 1.3 I believe. 
I've been looking at this some more. I think the issue with gray areas in
composer windows when deleting text are different to the main focus of this bug.
Those problems seem to only occur with the classic skin, and are, I suspect, a
bug in the native scrollbar impl.

Commenting out AddCoveringWidgetsToOpaqueRegion doesn't help anything.
I'm moving discussion of the native scrollbars (classic theme) issues into bug
155013. This bug remains for the random blank window issue.
*** Bug 188918 has been marked as a duplicate of this bug. ***
Here's some more info on this that happened today (Moz 1.2.1 on MacOSX 10.2.4).
 Go to any CNN story page (one with the vertical ad on the right).

Today, I saw the browser give me the gray behavior in the content region -
however, the vertical ad on the right and the Netflix ad on the left was visible
(and active).  Looking at the source, it seems that those ads appear in their
own IFRAMES, so the error appears to be at the per-document layout level.
My javascript console doesn't show any toolbars. Maybe it's related to this
problem. See bug 175517.
*** Bug 195181 has been marked as a duplicate of this bug. ***
I really don't want to ship this in 1.3. Simon, who else can help us here? 
What we really need is a reproducible testcase (using modern skin, please). This
so rarely happens that debugging it is impossible.
Could someone please attach a copy of their localstore.rdf after this occurs?
It's found in the profile directory. Maybe it's being corrupted.
Attachment #113519 - Attachment description: chrash log → crash log
at which point in time do you want this for :
1) immediately after the issue occurs with Mozilla still running
2) immediately forcequit Mozilla and then copy the state of the file
3) immediately quit Mozilla normally and then copy the state of the file
4) take a copy of localstore before a session and report this

I haven't seen the issue in the latest builds, and I'm a *heavy* user of tabbed
browsing (open a page containing a picture-album and then quickly open each
html-link in a new tab). Previously, this occured one or more times during a
session when opening several tabs in quick succession, but - as stated - I
luckily haven't had the issue lately.

As to localstore.rdf being corrupted.
How could that explain my issue in comment #91 & #92 ?
If a crash of Mozilla corrupts localstore.rdf and then this subsequently is the
cause of the blank window, then Mozilla has of lately become rock-steady and
really very rarely crashes. This stability occured at the point in time when
TalkBack got included with the nightlies.

Could it be a timing problem of some kind ?
Or the sequence in which stuff gets drawn into a window ?
- eg the drawing into the window gets closed before the content really has been
drawn or committed to the the window.
It would be good to have any one of those. It would be great to have all of
them. If more than one, then put ithem in a Binhex file or something and then
attach it.
Are there any memory checker tools like Purify that run on the Mac that we use here?
Not that catch uninitialized stack variables. There are some that can help track
down memory smashers.
Attached file localstore.rdf
localstore.rdf file after an occurrence of a greyed out dialog box (modified
last hours before the grey box occurred, quitting Mozilla did not change the
modification date)
The localstore.rdf file I just posted came from the build 20021130 (aka 1.2.1 OS
X) with classic skin. 
Attached are two localstore.rdf files in a stuffit archive. One was copied
using the Finder while Mozilla was still running with a gray page (inside a
frame), the other was from immediately after a normal quit (no other actions
between going gray and quitting).

Mozilla build 2003022303
MacOS X 10.2.4
Connection is ethernet on a LAN, using dhcp.

I can't provide a link to the page because it requires log in, but it was a
SunOne calendar settings page if anyone is interested.
Thank you for the attachments. A developer should be able to tell us whether
those files are corrupt. There are several bugs related to corrupt
localstore.rdf files. Just search bugzilla for   localstore  . Of course, it's
just a shot in the dark.

Assuming that the localstore shot in the dark misses, it must be something else.
Going back over the comments, I was struck by comment 45 and comment 52.
Apparently the XUL Fastload file is not the cause of this bug. OTOH if you
disable the XUL cache, you don't get the bug. It looks like the XUL cache is
could somehow be responsible. I'm not sure what the difference is between the
XUL cache and the XUL Fastload file, however. 
I can have grey window within 5 min even after deleting the mozilla pref folder
and restarting from a new profile. Is localstore.rdf can be corrupted as fast as
that ?
Attached file unreliable testcase
I have had the same trouble reproducing this as everyone else. Today I was in
alert hell debugging some javascript and hit my first semi-reliable testcase.
When  looping through 10 or 15 alerts at a time I noticed I would get a grey
sheet once every 3 or 4 cycles through the loop. Same is true with the test
script i'm attaching
Okay, now that's spooky. :)

I tried attachment 115957 [details] on both CFM 2003011203 and Mach-O 2003021703 and got
the gray background on the popup alert on alert #8 on the fourth set on both. 
(Hit "start alerts" and go through all of them, and hit "start alerts" 3 more
times after that).
Took until the 5th set for me, but it does eventually reproduce the problem.
Hi, the grey window not only appears under mac, but also under winxp. But this
is 100 % reproducable. I change the style from modern (luna) to classic, and the
first mozilla window I open is grey. When I close it and open another one, then
everything's fine.
using the "many alerts" testcase, I've seen the "grey alert" twice on my mach o,
debug, trunk (from last night) debug, modern build.

twice out of running it a number of times.

the grey alert doesn't fix itsself if I minimize and maximize (so it doesn't
appear to be a paint issue).

also, clicking on where the "OK" button should be doesn't work, but hitting the
return key does.  (does that help?)

sfraser, I'm not sure if the alert is the same problem as the originally reported.
The "many alerts" test case will reproduce the bug with the XUL cache disabled
(contrary to several comments above), but it takes longer. 
Looks like this isn't going to make 1.3 unless we have a breakthrough. This bug
sucks for those that are experiencing it but it's shipped in alpha and beta and
only generated a few duplicates so it's not as high-visibility as almost all of
the other 1.3 blockers. 
I set Moz to ask me about every cookie so that I get a lot of dialogs.  I see
this bug pretty often, but it's still intermittent.
Asa, can we get this moved to a 1.4a blocker?   It doesn't seem to be resolved.
 I have personally yet to see this problem despite following this bug closely. 
So I also think it's relatively limited.  And it's not going anywhere yet
despite all the hard work that seems to be going into it.  1.3 looks great from
my testing on OS X and Win32.  I don't think this is quite a blocker.  More of a
nusance for those it effects.

Perhaps with a more widespread release it will provide the necessary examples to
help debug?  Perhaps the testers in this case are just to small in number.

I would say release it, and send of a note to for them to forward
feedback regarding this issue... then post the results to this bug.  That would
be the best way to get the most information on this bug.  They are great with
stuff like that, and I'm sure would be more than willing to put a note on their
page for a day or two.
"Perhaps with a more widespread release it will provide the necessary examples to
help debug?  Perhaps the testers in this case are just to small in number."

Then the release note should not mention it hence the number of dups should
increase, and you'll have the ability to see how imprtant the bug really is.
IMHO, if this bug retains a status above "NORMAL" then it should be on the
Release Notes. After all, isn't that why Mozilla has Release Notes?

However, a good point is made about getting additional testers with the bug to
help get to the root cause of the problem. Maybe this should be part of the RELNOTE.

Not gonna make 1.3.
Severity: blocker → major
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+
Keywords: relnote
I ran into this in a debug build early today.  I attached gdb and poked around
in mostly unfamiliar code.  When I got into nsViewManager.cpp to NS_PAINT, the
coordinates/rects all seemed fine.  What was possibly wrong is view->mVis which
was set to nsViewVisibility_kHide.  Changing it to "show" in the debugger caused
the contents of the dialog to render completely (as desired).  mVis being set to
"hide" might also explain why tabbing didn't force the repaint either.  I do hit
my breakpoints when I tab if mVis is "show".

By the way, I was able to debug this by double-clicking the window title bar to
put the window in the dock and then click it in the dock to force the repaint
(which wasn't happening via other means like dragging offscreen or obscuring
with other windows).  
> What was possibly wrong is view->mVis which was set to nsViewVisibility_kHide.

Ooh, that'd do it.

Instrument nsView::SetVisibility to print out the current and new visibility
settings, and run that through the alert testcase to see if someone is setting
the view to invisible when garbage comes up.
I ran the testcase about 8 times and never saw a gray dialog <sigh>
Note that when things go bad, there is an extra call to nsView::SetVisibility
that changes the visibility from 1 to 0.  I don't know why there's an extra
call, however.
I think there's a way to get gdb to dump a stack trace every time you hit a
breakpoint. Need to repeat the test with that enabled at
nsView::SetViewVisibility to get a stack trace for the guilty SetVisibility(0).
I tried reproducing the alerts testcase with several versions of Moz on X 10.2.4.

Moz 1.2.1 - couldn't reproduce the problem after running the testcase at least 5

Moz 1.4a (2003030703) - reproduced the grey alert at the final alert of the 2nd
run, and at 7th alert of third run.

I'm running Moz on a Beige G3 266 Desktop with 416 Mb RAM and original video
card (unfortunately :).
In relation to my previous comment, a second go at the alert testcase caused the
following matches:

- 11th alert of 5th run
- 3rd alert of 7th run.
In layout/html/base/src/nsContainerFrame.cpp, about line 824 (1.3b), in the
method nsContainerFrame::SyncFrameViewProperties, is the line
The resulting value for windowType appears to be random.  And sometimes, in
particular, it happens to be "2" (aka eWindowType_popup), in which case the
following "if" statement is executed, and the visibility flag is turned off. 
And a grey window results. 

Note that in widget/src/xpwidgets/nsBaseWidget.cpp, the constructor does _not_
initialize the mWindowType variable.  Initializing it to -1 results in a
consistent -1 value for windowType in nsContainerFrame::SyncFrameViewProperties.
 Correct initialization I have to leave to someone who knows the code.
Hmmm, in mozilla/widget/public/nsIWidget.h we have this -

594     NS_IMETHOD GetWindowType(nsWindowType& aWindowType) = 0;
That just means that any class derived from nsIWidget must implement that
virtual method.
nsBaseWidget does in fact do so.  Of more interest might be,
wherein nsCocoaWindow::StandardCreate appears to not set mWindowType if there is
a parent window.
I'm not familiar enough with this code to know if that's a typical code path.  I
will say that it's a bad idea for nsBaseWidget to not be initializing the member
field mWindowType (which might explain the inconsistency of this bug).  However,
on other platforms, classes derived from nsBaseWidget take it upon themselves to
call  SetWindowType in their StandardWindowCreate(). 
(widget/src/beos/nsWindow.cpp, widget/src/gtk/nsWindow.cpp,
widget/src/os2/nsWindow.cpp, widget/src/xlib/nsWidget.cpp,
widget/src/windows/nsWindow.cpp, etc).
This explains everything.

It's a bit disturbing that nsCocoaWindow::StandardCreate doesn't initialize much
of anything when aNativeParent is non-null.

A Mac person should be able to easily spin a fix now.

I don't think we use widget/cocoa on Mac, it's only used by Camino.
Fair enough.  It looks like widget/mac/nsWindow.cpp also fails to initialize the
window type.  
I'm returning this to blocking1.3+ with the hope that with a diagnosis we can
get a pretty quick fix. Simon, Jan, others, any chance of a patch before Monday?
Flags: blocking1.3- → blocking1.3+
Attachment #116690 - Flags: superreview?(roc+moz)
Attachment #116690 - Flags: review?(sfraser)
Attachment #116690 - Flags: superreview?(roc+moz) → superreview+
In the interests of time perhaps we should just let sfraser review this trivial
patch AFTER it gets checked in.
I would agree with checking this into the Trunk before Mondays smoketests.
However, IMHO, the 1.3 Branch is a different matter and probably should wait
until further testing on Monday (and the "r").
Attachment #116690 - Flags: approval1.3+
I've built 1.3b with the patch applied.  It's available at if anyone would like to try it.  I haven't seen a
grey window so far. 
Flags: blocking1.3+ → blocking1.3-
Andy, you did not want to set blocking1.3b-, did you?
Flags: blocking1.3- → blocking1.3+
I didn't intend to change it.  It looks as if when I reloaded the page, the
change from "-" to "+" made last night was not reflected in the reloaded page. 
And thus I inadvertently changed it back.
Comment on attachment 116690 [details] [diff] [review]
initialize the window type

I say we should check this into the 1.3 branch, ASAP, so we can release
tomorrow's builds as 1.3.  This is not going to break anything worse than it's
already broken!

Attached patch patchSplinter Review
Let's do this instead.	There's no reason for nsBaseWidget not to initialize
its mWindowType member.
Attachment #116690 - Attachment is obsolete: true
Comment on attachment 116727 [details] [diff] [review]

I got r=pinkerton on irc for this.
Attachment #116727 - Flags: review+
Checked in on the branch and trunk.  Crossing fingers and marking fixed.
Closed: 21 years ago
Resolution: --- → FIXED
Fantastic, great work guys.
Nice work guys.
How about instead:  "Great work everyone!" so the person who spent all day
Friday debugging and pointing out the problematic area gets credit too.  :-)
Comment on attachment 116690 [details] [diff] [review]
initialize the window type

clearing review request on obsolete patch
Attachment #116690 - Flags: review?(sfraser)
From looking at the 1.0 sources, the patch appears to be equally valid there. 
It might have been the fix for bug 113083 that triggered the bug, as it added
code to change the visibility based on the (uninitialized) window type.
To nominate a patch for the 1.0 branch, send e-mail to
Removing RELNOTE keyword as no longer needed as fix is in.

As for the 1.0 branch, doesn't the NSBETA1+ keyword indicate it will be applied
to that branch?
Keywords: relnote
>doesn't the NSBETA1+ keyword indicate it will be applied
>to that branch?

Not at all. nsbeta1+ means, I think, that netscape employees should work on this
bug, for the next major release.
You're right, I forgot all about the Commercial Tree. Emailing drivers to
nominate for 1.0 Branch.
Whiteboard: [adt1] → [adt1] fixed1.3
I don't think this needs to go on the branch, since it was never known to cause
a problem there.
*** Bug 181987 has been marked as a duplicate of this bug. ***
Blocks: PhtN6
This appears to be fixed in the Macho trunk (2003-06-11-08) and branch
*** Bug 196129 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.