Closed
Bug 13860
Opened 25 years ago
Closed 25 years ago
Crash on "self.close()"
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
WORKSFORME
M14
People
(Reporter: gerbilpower, Assigned: danm.moz)
References
()
Details
(Keywords: crash)
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.
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.
Assignee: vidur → brendan
Sounds like a javascript: bug, and when I click on the ``close'' link nothing
happens. Brendan, you wanna take a look?
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 3•25 years ago
|
||
This is very likely a dup of 14049 -- a stack backtrace would confirm.
/be
*** This bug has been marked as a duplicate of 14049 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•25 years ago
|
||
Marking verified.
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•25 years ago
|
||
Dan, did self.close() from onclick break recently? I thought we had enough
kung-fu deathgrips to avoid crashing.
/be
Status: VERIFIED → REOPENED
Component: DOM Level 0 → Event Handling
OS: Windows 98 → Mac System 8.5
Hardware: PC → Macintosh
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 9•25 years ago
|
||
Dan: What stack did you get on that Mac crash? You wanna take this bug from me,
or make me borrow your Mac?
/be
Assignee | ||
Comment 10•25 years ago
|
||
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.
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: M13
Updated•25 years ago
|
OS: Mac System 8.5 → All
Comment 11•25 years ago
|
||
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.
Updated•25 years ago
|
Hardware: Macintosh → All
Comment 12•25 years ago
|
||
Woops, forgot to change the platform... doing so now.
Comment 13•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 14•25 years ago
|
||
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 16•25 years ago
|
||
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
Assignee: brendan → danm
Status: ASSIGNED → NEW
Assignee | ||
Comment 17•25 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•