Closed
Bug 60785
Opened 24 years ago
Closed 24 years ago
Crash if I call addEventListener on object rather than document
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
mozilla0.9
People
(Reporter: ruairif, Assigned: joki)
Details
(Keywords: crash)
Attachments
(5 files)
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
BuildID: 2000111704
Trying to get used to the addEventListener method to implement a movable window
thing on Mozilla.Sorry, I can't send uploads over the college network, so I'll
reproduce some of the code here:
HTML document:
.
.
<DIV onClick="movebox(this);">
..
An external javascript file is called in the <head> part :
...
function move(obj){
obj.addEventListener("mousedown",changepos,true);
function changepos(e){
alert("test");
}
...
When I click on the DIV area specified above, the "test" alert box is displayed
and the browser crashes.If I change "mousedown" to "click", I can click the
area once.However, if I do it again, the browser crashes.
The Dr.Watson output is:
Exception: access violation (0x0000005)
address: 0x77f6ce4c
Its really important that I find out about this, for the project I'm working
on, so if anyone can tell me that this problem can be solved sometime soon it
would put my mind at ease!
(Am I perhaps misusing the event handler in some way?)
Reproducible: Always
Steps to Reproduce:
1.set a <DIV> tag that calls a javascript function on some mouse event
with 'this' as parameter
2.within the javascript function, attach an Event Listener to the object.
3.place some action within the function called by the event listener
4.perform the event to call the Event Listener (e.g. click the <DIV>)
Actual Results: Browser crashes
Expected Results: I assume you should be able to attach event listeners to
things other than the document as a whole, to any node with the object tree?
Additonal info:
When the onClick event is followed by "click" in the event handler, and the
second click crashes the browser, the address in Dr.Watson changes to:
address: 0x60b3cc67
|
||
Comment 2•24 years ago
|
||
Confirming on WinNT. Using debug Mozilla build 2000-11-06.
I have transcribed the reporter's HTML as follows, and will attach below.
<HTML>
<HEAD><TITLE>Bug 60785</TITLE>
<SCRIPT>
function moveBox(obj)
{
obj.addEventListener("mousedown", changepos, true);
function changepos(e){alert("test");}
}
</SCRIPT>
</HEAD>
<BODY>
<DIV align = "Center" onClick="moveBox(this);" >
<HR WIDTH="75%" SIZE=3>
This DIV has an onClick handler. Click anywere here -
<BR>
<BR>
<HR WIDTH="75%" SIZE=3>
</DIV>
</BODY>
</HTML>
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 3•24 years ago
|
||
|
|
||
Comment 4•24 years ago
|
||
cc'ing Brendan and jband because the stack trace looks interesting.
Summary of WinNT stack trace (will attach details below):
NTDLL! 77f6ce0c()
NTDLL! 77f67546()
js_SuspendThread()
js_Enqueue()
js_Lock()
js_LockScope1()
js_LockObj()
js_GetSlotWhileLocked()
JS_GetPrivate()
nsScriptSecurityManager::GetFunctionObjectPrincipal()
nsScriptSecurityManager::CheckFunctionAccess()
nsJSContext::CallEventHandler()
nsJSDOMEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsGenericElement::HandleDOMEvent()
nsHTMLDivElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager2::DispatchEvent()
HandleEvent()
nsWindow::DispatchEvent()
nsWindow::DispatchWindowEvent()
nsWindow::DispatchMouseEvent()
ChildWindow::DispatchMouseEvent()
nsWindow::ProcessMessage()
nsWindow::WindowProc()
USER32! 77e71820()
|
|
||
Comment 5•24 years ago
|
||
|
|
||
Comment 6•24 years ago
|
||
Steps to reproduce:
1. With Mozilla, bring up the 2000-11-20 15:14 attachment above.
2. Click anywhere inside the DIV that is shown. Nothing happens.
3. Click on the DIV again. An alert comes up.
4. Click "OK" ---> CRASH
|
|
||
Comment 7•24 years ago
|
||
Confirming on Linux as well, although it is a little harder to reproduce.
I found I had to be careful not to click on the text portion of the DIV.
Changing OS to "All" -
OS: Windows NT → All
|
||
Comment 8•24 years ago
|
||
Possible dup of bug 31847? Not clear from stack, would hope for an earlier
crash but maybe the state of memory contained "valid pointers" up to a point
(namely, the crashpoint). The alert dialog will definitely run the GC. The
closure (joined function object) passed to addEventListener would certainly
become unreferenced once the outer function (move, moveBox) returns.
Ok, I buy it -- I'm that close to dup'ing against bug 31847, but will leave that
to joki. Reassigning.
/be
/be
Assignee: rogerl → joki
|
|
||
Comment 9•24 years ago
|
||
|
Reporter | |
Comment 10•24 years ago
|
||
This bug could have a pretty majoe effect on what I'm trying to do - its
preventing me from making some generic funciton to move any DIV about the
screen. i.e. passing the object to a function, rather than referencing a
specific ID value, and using obj.addEvent... instead of
document.getElementById(...).AddEvent...
So, if this looks like a dup of an earlier bug unlikely to be fixed soon, I
wonder could anyone point me in the right direction, be it an idea or a link (I
know this isn't a bug help forum, but I did report the thing!)
|
|
||
Comment 11•24 years ago
|
||
I think we should fix bug 31847 soon.
In the mean time, if you can arrange to store a reference to each closure you
add as an event listener in a JS array that stays alive, your code should work:
var hackaround = [];
function moveBox(obj)
{
obj.addEventListener("mousedown", changepos, true);
hackaround.push(changepos);
function changepos(e){alert("test");}
}
|
|
Reporter | |
Comment 12•24 years ago
|
||
|
|
Reporter | |
Comment 13•24 years ago
|
||
Sorry, trying to post a testcase for this one.Blame the college proxy. I'll try
again!
|
|
Reporter | |
Comment 14•24 years ago
|
||
|
|
Reporter | |
Comment 15•24 years ago
|
||
Apologies, I can't seem to upload this file correctly (first time uploading
attachment:thought you could put up a zip file). I'll wait until someone with
adminstrative permissions has cleared away the dud ones, then I'll put up a
simpler example, contained in one HTML file:just to illustrate exactly the
behavior I'm experiencing.It's becoming quite a problem.
|
||
Comment 16•24 years ago
|
||
Your attachment "Testcase:html file, its css and a js file" is messed up, but
the "Testcase:zip file" can be saved as a zip an unzipped just fine for me.
|
|
Reporter | |
Comment 17•24 years ago
|
||
I've put it all in one file anyway, even though the zip file works. I'll put it
up now.
anyway, to explain myself:
With either of the working examples, this is what should happen:
1)Click and hold(mouseDown) on the titlebar of the window DIV.
2)The background color changes (line of code missing from zip attachments,
included in the one I just put up)
3)Moving the mouse about with the button held down should move the window about
4)releasing the button should stop the movement and restore the background color
What actually happens, is a number of things. I should probably file a bug
report for each of these (advice?):
1)Holding the mouse button down and moving doesn't make the window move.You
have to click.The window then jumps to the bottom right handle of the mouse
pointer.The background color changes.
2)Moving the mouse (without holding down the button) moves the window.You have
to click again to release the window, however the color does not change back
(as a valid mouseup has not occured)
3)Further, mozilla leaves a trail as you move the window about.Moving it
outside the main colored area also leaves a residue image. This does not occur
on IE5.
4)Finally, if you move the window about for a while, or vigourously for a short
time, mozilla crashes.
The almost identical code in IE5 produces no residue images, a smooth
movement ,no jumps and,most importantly, no crashes!
Sorry for the long post, but there seems to be quite a bit happening here.
All this is best illustrated in my final attachment above.
|
|
Reporter | |
Comment 18•24 years ago
|
||
Changing crasher bug milestone to mozilla0.9.
Target Milestone: --- → mozilla0.9
|
Assignee | |
Comment 20•24 years ago
|
||
This is another dupe of 31847. The function object is getting garbage collected
because it's unrooted.
*** This bug has been marked as a duplicate of 31847 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
|
||
Comment 21•24 years ago
|
||
Verifications. Tests (if necessary) were done with 2001052504 on Windows 2000.
Please forgive the spam.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•