187286 - Having more then one mozilla window open can Freeze

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Travis Chase]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3b) Gecko/20021230
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3b) Gecko/20021230

Having more then one Mozilla window open occasionally freezes into solid grey
boxes when trying to close them, I use the Close button at the top left corner
on the Title Bar. I found this applys to Pop Ups as well as extra windows.
Boxes that grey are still moveable and don't affect the open ones they just hang
in the background. All Boxes close when Mozilla is forced to close under the
ctrl alt shift method on the Deskbar. This problem has reproduced itself, on
Both my BeOS Computers and previous Mozilla Builds. This problem does not crash
Mozilla.

Reproducible: Sometimes

Steps to Reproduce:
1. Open Extra windows or go to a site with pop ups
2. Close windows
3. Occasionally they turn into a grey box and sit in the background.

Actual Results:  
See 3.

Expected Results:  
Windows should go away leaving the user to be stress free and happy =)

Comment 1

[Sergei Dolgov]

confirming.

Comment 2

[Travis Chase]

I have a screenshot now of the Grey Box of Doom, if it helps?

Comment 3

[Sergei Dolgov]

probably dup of  http://bugzilla.mozilla.org/show_bug.cgi?id=164498

Comment 4

[Sergei Dolgov]

This awful issue rised without BeOS-port help, i suspect changes in ViewManager
 after 1.1 but cannot be sure. Need help to guess reason. I suspect that those
ghost-twin windows exist permanently but go "visible" after proper window
destruction, but maybe i'm wrong and this is just corpse of real nsView, where
main BView was destroyed, but container window remains:((

Comment 5

[Sergei Dolgov]

http://bugzilla.mozilla.org/show_bug.cgi?id=70489 - should revise

Comment 6

[Travis Chase]

Attachment: A screen shot of a Greyed box hanging around.

Comment 7

[Sergei Dolgov]

*** Bug 193082 has been marked as a duplicate of this bug. ***

Comment 8

[Sergei Dolgov]

*** Bug 195180 has been marked as a duplicate of this bug. ***

Comment 9

[Sergei Dolgov]

I suspect this LEAK/FREEZE/CRASH bug was here long ago.
But it started to be explicitly visible since attachment
http://bugzilla.mozilla.org/attachment.cgi?id=92841&action=view
to bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=71343
where we stopped to hide toplevel windows.

And this bug is turned to be softer compared to old times - in similar situation,
e.g. when i changed fonts and DPI in font preferences BeZilla crashed
frequently. Now it "freezes" for sime time and lefts "ghost" Preferences window.
 Same with "Find" dialog box and alert box, when search string was't found.

I think that it happens when mozilla tries to write into preferences/RDF files
in mozilla/settings folder - number of Destroy() calls reached
nsWindow/nsWindget is less for one call.

Wondering if it is related in any sense to infamous "Corrupted XUL.mfasl..." bug.

Comment 10

[Paul]

I will hopefully be posting a patch for this this week, based on work Sergei had
done to nsWindow.cpp

Comment 11

[Paul]

Reporter:  Can you still reproduce this bug?
Bug#134837 was checked it, and can be tested in the latest 1.5b release at
ftp.mozilla.org.
Please check, and let me know, thanks.

Comment 12

[Sergei Dolgov]

I doubt that we totally get rid if that. Rather this bug is bit hidden now due
to rewrite :Show() method.

I frequently meet similar situation with searching while something is missing on
page.
In such case attemp to close "Not Found" alert freezes Mozilla for quite long
time. It unfreezes then, but before with different :Show() implementation we had
just those zombie windows. No, i suspect, those zombies are just hidden.

Comment 13

[Travis Chase]

I can't try and reproduce at the moment, I currently don't have a BeOS machine
with Internet access, Im just using a work machine right now :( I still don't
have phone lines installed in my new place yet

Comment 14

[Niels Reedijk]

This bug is horribly old and probably hasn't got anything to do with the current state of the code.

If anyone objects, please reopen.