13860 - Crash on "self.close()"

Status: VERIFIED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Alex]

Overview Description:
Opening multiple URLs with "#" creates annoying problem of clicking on Back
more than necessary to go to the previous page.

Steps to Reproduce:
 1) Visit same URL:
http://www3.cybercities.com/g/gerbilpower/notebook/epigrams/index.html
 2) Click on any one of the links in the Epigrams page, opening up a pop-up
window.
 3) Scroll down pop-up window and click on "Close."

Results:
Upon clicking on Close, Apprunner crashes. I've test section of my web site
repeatedly and it crashed repeatedly.

Although another section of my site that employs similar pop-ups and the
"self.close()" JavaScript,
http://www3.cybercities.com/g/gerbilpower/gerbil/visual/index.html , does not
experience this crash and runs smoothly, although the pop-ups at this page also
employ frames.

Build Date & Platform Bug Found:
I've only been able to test Build 1999091409 on my PC running Windows 98.
Testing on other platforms and operating systems is needed.

Comment 1

[Alex]

The documents that the caused the crash used <a href="javascript:self.close()">
to close the window.

However, I tested <a href="#" onclick="javascript:self.close()"> on my computer
and it did not crash using "onclick" instead of "href" to close the window.

Comment 2

[Mike Shaver (:shaver emeritus)]

Sounds like a javascript: bug, and when I click on the ``close'' link nothing
happens.  Brendan, you wanna take a look?

Comment 3

[brendan-obsolete]

This is very likely a dup of 14049 -- a stack backtrace would confirm.

/be

*** This bug has been marked as a duplicate of 14049 ***

Comment 4

[Prashant Desale]

Marking verified.

Comment 5

[metrol]

Thought I'd just add in here that you can also reproduce this bug with the
following code...

<input type="button" name="Button" value="Cancel" OnClick="self.close()">

Bug 14049 has been marked as fixed, but this bug is still very much alive and
kicking as of 13-Dec-1999.

Comment 6

[Brendan Eich [:brendan]]

Dan, did self.close() from onclick break recently?  I thought we had enough
kung-fu deathgrips to avoid crashing.

/be

Comment 7

[Dan M]

Recently? I don't know. I've been deathgripping things right and left, but I haven't
found a general solution. metrol's simple test case above crashes for me with today's
build, but not on Linux or Windows; just on the Mac. Re-opening and adjusting to
match my experiences.

Comment 8

[leger]

Clearing DUPLICATE resolution due to reopen.

Comment 9

[Brendan Eich [:brendan]]

Dan: What stack did you get on that Mac crash?  You wanna take this bug from me,
or make me borrow your Mac?

/be

Comment 10

[Dan M]

Hmmmmm. Nope, you want to at least be involved in the architecture behind the solution,
if not the grungework. Leaving it with you for now.

Here's the problem, though. We suck. More specifically, this is just case #247 where
we designed dangling pointers into our system. More specifically,
layout/events/src/nsEventListenerManager.cpp,
nsEventListenerManager::HandleEvent, in the NS_MOUSE_LEFT_BUTTON_UP case,
goes through a loop, servicing mMouseListeners->Count() event handlers. There are at least
two in this case, and the second is deleted while bringing down the window while servicing
the first. There's already a deathgrip on the event listener manager itself; it would probably
be deleted within the loop, itself, if not for that. This is a general problem throughout our
event handling code. I can't think of anything to do about it but massively spank event handlers
with Scott's weak reference code.

Oddly, the same problem doesn't happen on, say, Windows. Mac crashes on the second
evenlistenermanager involved. Windows only ever involves one manager.

Comment 11

[Michael Collette]

Changing the OS on this bug to All.  I've got a web based database editing
application that heavily utilizes pop up windows and the need to close them.  On
both NT and Linux any screen that I attempt to close via Javascript crashes
Mozilla hard.  This is far more than just a Mac problem.

Comment 12

[Michael Collette]

Woops, forgot to change the platform... doing so now.

Comment 13

[Prashant Desale]

Actually I tried this one with todays builds [2000-01-19-13], but I don't see
crash at all.
Here is my own testcase.
Please visit foillowing URL, and follow the directions mentioned there.

http://bubblegum/whitebox/JS_tstm/testcases/win087.html

I don't see crash at all. I tried to use "self.close" on buttons click too, but
there is no crash.

Comment 14

[Brendan Eich [:brendan]]

Moving to M14, probably closing then once danm and I are convinced all necessary
kung fu death grips have been used (and their number minimized by consolidating
squirrely code paths).

/be

Comment 15

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 16

[Brendan Eich [:brendan]]

I'm on sabbatical for 8 weeks.  Plus, this bug seems to have been abated by 
kungfu deathgrips or luck.  Dan, can you verify it's fixed and close it?  Sure, 
the potential for more such problems exists.  But we can only fix what we know 
is broken, and if we've done that, the outstanding bug report should be closed.

/be

Comment 17

[Dan M]

Hmmm. Marking "works for me," by which I mean just that. Everyone seems to be 
unable to reproduce the problem any longer, including me. I've stepped through 
the load and mouse event handlers as the window is torn down, and seen nothing of 
the problem I mentioned above. Looks like someone fixed some object lifetimes 
somewhere and this bug benefits. Woohoo! I think.

Comment 18

[Prashant Desale]

Verified with 2000-02-02-14.