Crash if I call addEventListener on object rather than document

VERIFIED DUPLICATE of bug 31847

Status

()

Core
JavaScript Engine
P1
critical
VERIFIED DUPLICATE of bug 31847
17 years ago
16 years ago

People

(Reporter: Cormac F, Assigned: joki (gone))

Tracking

({crash})

Trunk
mozilla0.9
x86
All
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

17 years ago
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?
(Reporter)

Comment 1

17 years ago
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
(Reporter)

Updated

17 years ago
Priority: P3 → P1

Comment 2

17 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

17 years ago
Created attachment 19527 [details]
Here is the HTML file causing the crash

Comment 4

17 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

17 years ago
Created attachment 19530 [details]
WinNT stack trace

Comment 6

17 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

17 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
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

17 years ago
For what it's worth: 


Note bug 49017  "RFE: EventListener objects not accepted by addEventListener"
Note bug 53640  "addEventListener() for event capture not always registering"

Also bug 18066  "[mlk] unconditional addref in AddEventListener()"  [FIXED]
(Reporter)

Comment 10

17 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!)
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

17 years ago
Created attachment 19900 [details]
Testcase:html file, its css and a js file
(Reporter)

Comment 13

17 years ago
Sorry, trying to post a testcase for this one.Blame the college proxy. I'll try 
again!
(Reporter)

Comment 14

17 years ago
Created attachment 19901 [details]
Testcase:zip file
(Reporter)

Comment 15

17 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

17 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

17 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

17 years ago
Created attachment 19909 [details]
Final (working) attachment, all in one file

Updated

17 years ago
Keywords: crash
Changing crasher bug milestone to mozilla0.9.
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 20

17 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
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 21

17 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.