Closed Bug 181293 Opened 22 years ago Closed 22 years ago

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

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: sfraser_bugs)

References

Details

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

Attachments

(8 files, 1 obsolete file)

screenshot of browser window that i get
36.71 KB, image/gif
Details
Yet Another Screenshot
56.48 KB, image/jpeg
Details
crash log
5.15 KB, text/plain
Details
localstore.rdf
30.15 KB, text/plain
Details
2 localstore.rdf files
4.89 KB, application/octet-stream
Details
unreliable testcase
502 bytes, text/html
Details
added printf statement to nsView::SetVisibility
1.93 KB, text/plain
Details
patch
540 bytes, patch
bryner
: review+
Details | Diff | Splinter Review
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: 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 → ---
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. Thanks
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 Thanks
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: #ifdef IS_LITTLE_ENDIAN outString->Append(PRUnichar(NS_SWAP16(unichar))); #else outString->Append(unichar); #endif 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 (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.
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 155013.
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 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 ?
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. :-\
Status: NEW → ASSIGNED
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 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?
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 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.
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 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 !
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
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.
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 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.
"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 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 :).
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 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.
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 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!!!!!!!!
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").
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-
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! /be
Attached patch patch — — Splinter 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] 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
Closed: 22 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 drivers@mozilla.org.
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 (2003-06-11-05).
Status: RESOLVED → VERIFIED
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: