56162 - mozilla does not react gracefully to ungraceful window close

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test9-pre1 i686; en-US; m18)
Gecko/20001009
BuildID:    2000100908

If a window is closed ungracefully (using the "Anihilate" command in
Enlightenment (right click on close button), for instance), mozilla segvs

Reproducible: Always
Steps to Reproduce:
1. Open mozilla.
2. Open as many windows as you want
3. (Using Enlightenment) right-click in the 'X' in the title bar. Other window
managers have a similar command.

Actual Results:  A bunch of Gdk-WARNING **: GdkWindow 0x440002d unexpectedly
destroyed (with different numbers each time) and a segv message from the sh wrapper.

Expected Results:  Something sane. At least not closing all windows with a segv.

If there were 2 or more windows, it should recover; else, it should gracefully quit.

Comment 1

[Asa Dotzler [:asa]]

over to XPApps.  I can confrim this with 101108 mozilla trunk linux build.  I
think this is a recent regression.

Comment 2

[don]

Pavlov, any idea what's going wrong here?

Comment 3

[Cesar Eduardo Barros]

New behavior (2000101908Mtrunk): now it doesn't crash, it just doesn't take
notice that the windows were closed.

This means that, besides spewing a screenful of horrible GTK messages in the
console, mozilla won't quit when you close all its windows.

To reproduce: open two windows. right-click-close (destroy) both. Notice mozilla
is still running. (Tested only once here.)

Comment 4

[Cesar Eduardo Barros]

With 2 windows open, killing the second one still segvs mozilla. Marking as
crasher. Crashers should be "critical", should the severity go up too?

Tested on 2001021908.

Comment 5

[sairuh (rarely reading bugmail)]

->toolkit?

Comment 6

[John Morrison]

Ok, critical since it does take out the app.

(But, on the other hand, we are taking "Annihilate" literally :-]

Comment 7

[Dan Rosen]

could this possibly be a dup of bug 67006?...

Comment 8

[sairuh (rarely reading bugmail)]

i still see this using a debug from noon today, as well as 2001.04.12.08 verif
bits. i don't think this is a crash, per se...more like a hang, so changing
keyword.

Comment 9

[clayton]

Pav, are you the right owner?  Might someone in Apps have more cycles for this
since you're busy on imagelib?

Comment 10

[Dan Rosen]

pavlov is *so* not going to work on this :)

Comment 11

[Dan Rosen]

->0.9.3 (not a netscape rtm stopper, per pdt)

Comment 12

[Dan Rosen]

pushing back up to 0.9.2. this should be very easy to bulletproof, and should be
done for netscape rtm.

Comment 13

[Dan Rosen]

[spam] pushing off non-critical 0.9.2 bugs to 0.9.3. please take the helpwanted
keyword to heart if you'd like to see these fixed in 0.9.2!

Comment 14

[Dan Rosen]

[spam] [e-mail]'s bugs subject to redistribution by chofmann. R!

Comment 15

[Cesar Eduardo Barros]

Well, it does crash here (with some Gtk errors and $? of 1 -- no SEGV now). I
don't see a hang. Crashes should be critical. Correct me if I'm wrong.

IMHO it would be dataloss if it weren't a crash (the definition for dataloss
excludes crashes).

Comment 16

[Jesse Ruderman]

Documentation for Enlightenment seems to describe Annihilate in two vague, conflicting ways:

"Annihilate destroys the window without regard to the application the window belongs to, which is especially useful if the application refuses to respond to being closed with Close."

"Annihilate - This will kill the application if you are having trouble closing the window."

Comment 17

[Robert Kaiser]

This didn't get new info for a long time. If this is still happening, please add an appropriate crash ID link from about:crashes when reopening, as in its current form, this is hard for developers to analyze or work on.