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

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: mikepinkerton, Assigned: sfraser_bugs)

Tracking

({qawanted, testcase})

Trunk
PowerPC
Mac OS X
qawanted, testcase
Bug Flags:
blocking1.3a -
blocking1.3b -
blocking1.3 +
blocking1.4a +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1] fixed1.3)

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

16 years ago
I've seen this too. It must be a compositor issue.
Component: Browser-General → GFX Compositor
(Reporter)

Comment 2

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

Comment 4

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

Comment 6

16 years ago
I can not reproduce this
(Reporter)

Comment 7

16 years ago
it's 100% repro for me.
(Reporter)

Comment 8

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

Comment 9

16 years ago
Created attachment 107071 [details]
screenshot of browser window that i get

here's an image of what i get opening a browser after i open mail compose.

Comment 10

16 years ago
Using 20002112108 release build, I dont see this issue.
Pinkerton, are you seeing this only in debug?
(Reporter)

Comment 11

16 years ago
mozilla opt bits off sweetlou. i don't even have a recent trunk debug build.
(Reporter)

Comment 12

16 years ago
this does happen with a brand new profile.

Comment 13

16 years ago
Dcone, can you please look inot this? 
Assignee: kmcclusk → dcone

Comment 14

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

Comment 15

16 years ago
Yep, I see the issue with Peter's test case. With focus being in the outliner, I
can reproduce this consistently.

Comment 16

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

Comment 17

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

Comment 18

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

Comment 19

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

Updated

16 years ago
Keywords: qawanted

Updated

16 years ago
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha

Comment 22

16 years ago
This has been happening for more than just a few days. Dup of bug 175939?

Comment 23

16 years ago
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:
ftp://sweetlou.mcom.com/products/client/seamonkey/macos/10.x/ppc/
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 → ---

Comment 24

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

Comment 25

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

Comment 26

16 years ago
FWIW, WFM under Mac OS 9.2.2 running trunk build 2002112008.

Apparently a Mac OS X issue.

Comment 27

16 years ago
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?).
(Reporter)

Comment 28

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

Comment 29

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

Comment 32

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

Comment 33

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

Comment 34

16 years ago
Could this be related to bug 180814 ?

Comment 35

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

Comment 36

16 years ago
2002111903 is affected too
trying 2002111703, nsTreeBodyFrame was modified that day (bug 147887)

Comment 37

16 years ago
since this doesn't *technically* block smoketests, and there are workarounds,
and there is someone tracking this down now, removing smoketest keyword.
Keywords: smoketest

Comment 38

16 years ago
Mach-O builds seem to work fine.

Comment 39

16 years ago
2002111703 is affected too

Comment 40

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

Comment 41

16 years ago
2002111503 is fine

Comment 42

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

Comment 43

16 years ago
I've seen this in Macho builds, on 10.2.2.

Comment 44

16 years ago
So, is this a different problem than bug 175939?

Comment 45

16 years ago
I'm not able to reproduce it with disabled XUL cache and fastload

bug 177401 looks suspicious:
#ifdef IS_LITTLE_ENDIAN
        outString->Append(PRUnichar(NS_SWAP16(unichar)));
#else
        outString->Append(unichar);
#endif                                                                          

Boris, Alec any ideas ?
(Reporter)

Comment 46

16 years ago
any update on this? it makes the trunk close to impossible to use.
(Assignee)

Comment 47

16 years ago
*** Bug 175939 has been marked as a duplicate of this bug. ***

Comment 48

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

Comment 49

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

Comment 50

16 years ago
nominating to block 1.3a. 
Flags: blocking1.3a?
Is this reproducable after removing the fastload file?

Comment 52

16 years ago
I'm not able to reproduce it with disabled XUL cache.
Disabling just XUL fast load doesn't help.

Updated

16 years ago
Flags: blocking1.3a? → blocking1.3a-
(Reporter)

Updated

16 years ago
Flags: blocking1.3b?

Updated

16 years ago
Flags: blocking1.3b? → blocking1.3b+

Comment 53

16 years ago
I wonder if bug 181987 may also be related.

Comment 54

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

Comment 55

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

Comment 56

16 years ago
May be related to <a href="show_bug.cgi?id=#184972" title="Alert box is plain
grey w/no text.">Bug #184972</a>.

Comment 57

16 years ago
Forgot to mention my system specs: Mac OSx 12/16 trunk build

Comment 58

16 years ago
Created attachment 110227 [details]
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 (mozilla.org is home page)
4. Start to type bugzilla.mozilla.org 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
fields
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.

Comment 59

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

Comment 60

16 years ago
ccing jrgm at brendan's request.
QA Contact: shrir → petersen

Comment 61

16 years ago
Nav triage team: nsbeta1+/adt1
Whiteboard: [adt1]

Comment 62

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

Comment 63

16 years ago
The same thing happens in Composer.
(Assignee)

Comment 64

16 years ago
Thanks for the steps. Can you still repro if you quit and restart Mozilla, and
do the steps again?

Comment 65

16 years ago
The problem described in comment 62 is different, and is already filed as bug
155013.

Comment 66

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

Comment 68

16 years ago
I doubt that this is fixed.

Comment 69

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

Comment 70

16 years ago
I also saw a mostly-grey Prefs window yesterday using FizzillaMach/2003012503.

Comment 71

16 years ago
*** Bug 184972 has been marked as a duplicate of this bug. ***

Comment 72

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

Comment 73

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

Comment 74

16 years ago
Yeah, just remove 'XUL Fastload file' or 'XUL.mfasl' or both

Comment 75

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

Comment 76

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

Comment 77

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

Comment 79

16 years ago
I finally was able to reproduce it with my own Mach-o build pulled with
MOZ_CO_DATE=20021118
Unfortunately, I couln't reproduce it again.
This bug drives me crazy.
Can some of the Mac developers cc'ed on this bug help ?
(Assignee)

Comment 80

16 years ago
I can only repro this in an opt build. Doing an opt-with-symbols build now.
Assignee: varga → sfraser
(Assignee)

Comment 81

16 years ago
OK, I've been pushing opt builds around for several hours now, and I haven't
seen this once.  :-\
Status: NEW → ASSIGNED

Comment 82

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

Comment 83

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

workaround:
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?

Comment 85

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

Comment 86

16 years ago
I stopped using Mozilla on my Mac because of this problem. I'll download a new build and try it for a few days.

Comment 87

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

Comment 88

16 years ago
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 http://www.mozlla.org/ports/fizzilla/Mach.html."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.

Comment 89

16 years ago
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. :-)

Comment 91

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

Comment 92

16 years ago
Created attachment 113519 [details]
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

Comment 93

16 years ago
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 mozillazine.org, 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 !
(Assignee)

Comment 95

16 years ago
Yeah, I saw this a couple of times yesterday (never in debuggable builds, grrr).

Comment 96

16 years ago
bumping to final. 
Flags: blocking1.3b-
Flags: blocking1.3b+
Flags: blocking1.3+

Comment 97

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

Comment 98

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

Comment 99

16 years ago
*** Bug 192630 has been marked as a duplicate of this bug. ***

Comment 100

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

Comment 101

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

Comment 102

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

Comment 103

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

Comment 105

16 years ago
*** Bug 184438 has been marked as a duplicate of this bug. ***

Comment 106

16 years ago
*** Bug 175214 has been marked as a duplicate of this bug. ***

Comment 107

16 years ago
*** Bug 184375 has been marked as a duplicate of this bug. ***

Comment 108

16 years ago
Simon, can you test roc's suggestion in comment 104 ? This is the only horrible
mac-specific problem left for 1.3 I believe. 
(Assignee)

Comment 109

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

Comment 110

16 years ago
I'm moving discussion of the native scrollbars (classic theme) issues into bug
155013. This bug remains for the random blank window issue.

Comment 111

16 years ago
*** Bug 188918 has been marked as a duplicate of this bug. ***

Comment 112

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

Comment 113

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

Comment 115

16 years ago
I really don't want to ship this in 1.3. Simon, who else can help us here? 
(Assignee)

Comment 116

16 years ago
What we really need is a reproducible testcase (using modern skin, please). This
so rarely happens that debugging it is impossible.

Comment 117

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

Updated

16 years ago
Attachment #113519 - Attachment description: chrash log → crash log

Comment 118

16 years ago
localstore.rdf:
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.

Comment 119

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

Comment 121

16 years ago
Not that catch uninitialized stack variables. There are some that can help track
down memory smashers.

Comment 122

16 years ago
Created attachment 115851 [details]
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)

Comment 123

16 years ago
The localstore.rdf file I just posted came from the build 20021130 (aka 1.2.1 OS
X) with classic skin. 

Comment 124

16 years ago
Created attachment 115888 [details]
2 localstore.rdf files 

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.

Comment 125

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

Comment 127

16 years ago
Created attachment 115957 [details]
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).

Comment 129

16 years ago
Took until the 5th set for me, but it does eventually reproduce the problem.

Comment 130

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

Comment 132

16 years ago
The "many alerts" test case will reproduce the bug with the XUL cache disabled
(contrary to several comments above), but it takes longer. 

Comment 133

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

Comment 134

16 years ago
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 MacFixIt.com 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.

Comment 136

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

Comment 137

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

Comment 138

16 years ago
Not gonna make 1.3.
Severity: blocker → major
Flags: blocking1.4a+
Flags: blocking1.3-
Flags: blocking1.3+

Updated

16 years ago
Keywords: relnote

Comment 139

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

Comment 141

16 years ago
I ran the testcase about 8 times and never saw a gray dialog <sigh>

Comment 142

16 years ago
Created attachment 116606 [details]
added printf statement to nsView::SetVisibility

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

Comment 144

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

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

Comment 145

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

Comment 146

16 years ago
In layout/html/base/src/nsContainerFrame.cpp, about line 824 (1.3b), in the
method nsContainerFrame::SyncFrameViewProperties, is the line
widget->GetWindowType(windowType);
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.

Comment 147

16 years ago
Hmmm, in mozilla/widget/public/nsIWidget.h we have this -

594     NS_IMETHOD GetWindowType(nsWindowType& aWindowType) = 0;

Comment 148

16 years ago
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 nsCocoaWindow.mm,
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.

Thanks!!!!!!!!

Comment 150

16 years ago
I don't think we use widget/cocoa on Mac, it's only used by Camino.

Comment 151

16 years ago
Fair enough.  It looks like widget/mac/nsWindow.cpp also fails to initialize the
window type.  

Comment 152

16 years ago
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+
Created attachment 116690 [details] [diff] [review]
initialize the window type
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.

Comment 155

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

Comment 156

16 years ago
I've built 1.3b with the patch applied.  It's available at
http://homepage.mac.com/afyfe if anyone would like to try it.  I haven't seen a
grey window so far. 
Flags: blocking1.3+ → blocking1.3-

Comment 157

16 years ago
Andy, you did not want to set blocking1.3b-, did you?

Updated

16 years ago
Flags: blocking1.3- → blocking1.3+

Comment 158

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

/be
Created attachment 116727 [details] [diff] [review]
patch

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]
patch

I got r=pinkerton on irc for this.
Attachment #116727 - Flags: review+
Checked in on the branch and trunk.  Crossing fingers and marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 164

16 years ago
Fantastic, great work guys.
(Assignee)

Comment 165

16 years ago
Nice work guys.

Comment 166

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

Comment 168

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

Comment 169

16 years ago
To nominate a patch for the 1.0 branch, send e-mail to drivers@mozilla.org.

Comment 170

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

Comment 172

16 years ago
You're right, I forgot all about the Commercial Tree. Emailing drivers to
nominate for 1.0 Branch.

Updated

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

Comment 174

16 years ago
*** Bug 181987 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 204127

Comment 175

16 years ago
This appears to be fixed in the Macho trunk (2003-06-11-08) and branch
(2003-06-11-05).
Status: RESOLVED → VERIFIED

Comment 176

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