Mozilla crashes/hangs on event listeners...

VERIFIED WORKSFORME

Status

()

Core
Event Handling
P3
critical
VERIFIED WORKSFORME
18 years ago
15 years ago

People

(Reporter: Aaron Winters, Assigned: joki (gone))

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [does not crash])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i586; en-US; m18) Gecko/20000913
BuildID:    2000091321

Ganthering any real definitive information on this bug has proven a bit
complicatated as its behaviors are somwhat random...

The bug was generated while trying to test the DOM level 2 event listeners in a
drag and drop type of enviornment.

Reproducible: Always
Steps to Reproduce:
1.Open a page containing repetitive event listeners created by another event
listener, such as an onmousedown, onmousemove combination.
2.Trigger the first event, id est click on the object.
3.Trigger the second event, id est drag the object.

Actual Results:  The object attempts to sluggishly follow the pointer. The stops
after a few seconds. The Browser becomes unresponsive.

Expected Results:  The object should follow the pointer unwaveringly until the
mouse button is realeased, comming to rest at that position.

Here is the required code from the two files that produced this bug.

dragDrop.js

/* Reference implementation of a multi-purpose drag and drop engine using the
level 2 DOM. */


function dragDrop ()
 {
  dragDrop.prototype.newObj =
  function (obj)
   {
    document.getElementById(obj).addEventListener("mousedown", beginDrag, false)
   }

  dragDrop.prototype.rmObj =
  function (obj)
   {
    document.getElementById(obj).removeEventListener("mousedown", beginDrag, false)
   }

  function beginDrag (evnt)
   {
    window.activeObject = evnt.currentTarget.id
    window.offsetX = evnt.clientX
    window.offsetY = evnt.clientY
    evnt.currentTarget.parentNode.addEventListener("mousemove", Drag, false)
    evnt.currentTarget.parentNode.addEventListener("mouseup", endDrag, false)
   }

  function endDrag (evnt)
   {
    evnt.currentTarget.removeEventListener("mousemove", Drag, false)
    evnt.currentTarget.removeEventListener("mouseup", endDrag, false)
   }

  function Drag (evnt)
   {
    var obj = window.activeObject
    var offX = evnt.clientX - window.offsetX
    var offY = evnt.clientY - window.offsetY
    var newX = parseInt(document.getElementById(obj).style.left) + offX
    var newY = parseInt(document.getElementById(obj).style.top) + offY
    document.getElementById(obj).style.left = newX + "px"
    document.getElementById(obj).style.top = newY + "px"
    window.offsetX = evnt.clientX
    window.offsetY = evnt.clientY
   }
 }

DragTest.htm

<html>
<head>
<title>Desktop</title>
</head>
<script language="javascript" src="dragDrop.js"></script>
<script language="javascript">
 function setIcons()
  {
   IconEvent = new dragDrop()
   IconEvent.newObj("Test")
  }
</script>
<body bgcolor="#3F6F9F" onload="setIcons()">
<div id="Test" align="center" orient="vertical" style="position : absolute; left
: 14px; top : 14px">
 <div align="center">
   <image src="images/icons/Test.png"/>
  </div>
  <div align="center" style="font-size : 12px">Test</div>
</div>
</body>
</html>

Any image should suffice in Test's place... however for reference test was a 35
x 35 px png image.

Also, the code that worked in the M17 build, and in NS6 PR2 generated even
stranger results... Under the 'Classic' skin the events seemed to be ignored
where under the 'Modern' Loading the page and attempting to drag one of the
icons would quickly crash the browser.

The DragTest.htm file is identical... and the dragDrop.js file is only slightly
different, implementing an older DOM level 0 method in place of the W3 method
because at that point it wasn't supported... the main purpose of this test was
to see if it had finally been successfully implemented.

dragDrop.js (Works in NS6 PR2)

function dragDrop ()
 {
  dragDrop.prototype.newObj =
  function (obj)
   {
    document.getElementById(obj).addEventListener("mousedown", beginDrag, false)
   }

  dragDrop.prototype.rmObj =
  function (obj)
   {
    document.getElementById(obj).removeEventListener("mousedown", beginDrag, false)
   }

  function beginDrag (evnt)
   {
    window.activeObject = evnt.currentTarget.id
    window.offsetX = evnt.clientX
    window.offsetY = evnt.clientY
    /* The following code was removed because there was no support for
neccessary methods at the time of this writing.
    evnt.currentTarget.parentNode.addEventListener("mousemove", Drag, false) */
    window.onmousemove = Drag
    evnt.currentTarget.parentNode.addEventListener("mouseup", endDrag, false)
   }

  function endDrag (evnt)
   {
    /* At the time of this writing there appeared to be no support for this
method whithout which this code fails.
    evnt.currentTarget.removeEventListener("mousemove", Drag, false) */
    window.onmousemove = null
    evnt.currentTarget.removeEventListener("mouseup", endDrag, false)
   }

  function Drag (evnt)
   {
    var obj = window.activeObject
    var offX = evnt.clientX - window.offsetX
    var offY = evnt.clientY - window.offsetY
    var newX = parseInt(document.getElementById(obj).style.left) + offX
    var newY = parseInt(document.getElementById(obj).style.top) + offY
    document.getElementById(obj).style.left = newX + "px"
    document.getElementById(obj).style.top = newY + "px"
    window.offsetX = evnt.clientX
    window.offsetY = evnt.clientY
   }
 }

Comment 1

18 years ago
which glibc do you use? (rpm -q glibc)

Comment 2

18 years ago
I noticed the buld ID and I suspect this could be related to bug #52612 where
drag and drop is not working in the browser itself.

If possible, try this is a build that's a few days old (this is only a recent
problem) and see if it works.
(Reporter)

Comment 3

18 years ago
I am using glibc 2.1.3-15

I am not sure if this bug is related to drag and drop as it doesn't involve the
mozilla's own drag and drop engine. While the bug will repro by loading the
content the browser I first produced it from a chrome level XUL aplication, id
est a page loaded at the prompt with the -chrome option. At that point none of
the default browser behaviors are loaded and gecko is the developers canvas.

If I get time I will grab an older build and see if it is only a recently
introduced problem.
(Reporter)

Comment 4

18 years ago
Some additional comments on Drag and Drop... After taking a good look at the URL
drag and drop bug 52612 and then playing with Mozilla for a few minutes I can
provide a little bit more information.

Dragging and Dropping images works just fine. I was able to drag the Mozilla.org
banner into a new composer document, no prob.

And again, this seems to be a problem either in JS or something with the Level 2
DOM code, the code worked in older builds which didn't support all of the DOM
event model, granted as yet I'm not sure if the new build does either.

I am not using the browser's Drag and Drop functions, rather I am implementing
my own in a chrome level application. When the same code is loaded into a
general browser window the default drag and drop action and the behavior
implemented by the DOM Level 0 event listener in the last code snippit I
included run into conflict with one another. In the earlier example using the
Level 2 DOM the conflict should be resolved, but I can't say for certain.

My only suggestion would be to modify the code as needed to include an image of
some sort and then attempt to run the NS6/M17 verified code on one of those
builds so that you can see the behavior I am trying to generate, it seems to
work best on a windows platform, the motion is mutch smoother, but it also works
on a linux system. I am assuming you will probably just load this in a gereric
browser window so I will reiterate my previos statment regarding the conflict
between the default drag and drop behvaior and the behavior I am trying to
create. It usually doesn't present a problem on the first attampt, but on
successive attampts the browser will take over and attempt to perform its own
drag and drop action, this leave you with a browser generated icon clinging to
your mouse until you click --and I mean click, moving the mouse again is likely
to invoke the browser's drag and drop engine again leaving you where you
started-- the mouse button again.

If you attempt to run the full DOM level 2 implementation in older the NS6/M17
builds it will result in an icont that is infact attached to your mouse until
you load another page, or unload the current page. This problem stems from a bug
surrounding the removeEventListener method and its apparent lack of support in
these builds.

There was a bug submitted on this that i read earlier when I first encountered
it marking it as fixed, but I have yet to encounter it in a build... I was
attempting to verify the bug's actual status in the current code before
reopening it.

After you have loaded the code in a older build and been exposed to the desired
behaviors load the the two libraries alternately in a new build. The NS6/M17 
code is ignored if the user is using the Classic skin and will crash the browser
if the user is using the Modern skin. The pure Level 2 DOM implementation will
lock the browser after a few seconds of dragging and you must kill the process
manually which has made in inpossible to test for the correct implementation of
removeEventListener as the browser locks up before I can get a change to release
the mousebutton and fire the function responsible for that, this is not realated
to the skin, however I have not tested it under Windows, so I am unsure as to
the bahavior there, I don't have a test box available that I can install a new
Moz build as I have to maintain a clean Test box for the current line of
development.

I apologize of the extensive verbosity, but with all hope it will help you track
down the bug better.

Comment 5

18 years ago
changing status 
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

18 years ago
Updating QA Contact.
QA Contact: janc → lorca

Comment 7

18 years ago
*spam*

adding crash keyword...
Keywords: crash
Created attachment 16073 [details]
Testcase: dragtest with with first dragdrop.js
Created attachment 16074 [details]
Testcase: REALLY dragtest with with first dragdrop.js
Created attachment 16075 [details]
Testcase: REALLY dragtest with with second dragdrop.js
I tested this on NT on last weeks trunk build and todays PR3 branch build and
the samples do not crash. I also tested it on PR3 Linux build from today and it
is not crashing.

The dragging is working mostly OK. Occasionally the system level drag & drop
kicks in, but currently this is what is supposed to happen. Make the functions
return false (at least the begin drag) to see if it helps (it should).

I am removing the crash keyword. I think this is actually a dup of bug 47022,
marking dup.


*** This bug has been marked as a duplicate of 47022 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Keywords: crash
Resolution: --- → DUPLICATE
Whiteboard: [does not crash]
(Reporter)

Comment 12

18 years ago
Well, Kudos... I downloaded today's nightly build after recieving the updated
via e-mail and it would appear the bug has been fixed... however, I did take the
time to test it in the original build I submitted it for and it still crashes
that one.

Aother kudos on fixing the true level 2 DOM event handling scheme... i.e.
'removeEventHandler'

However, this bug is NOT a dup of 47022 this bug was NOT present in the M17
build only the nightly build it was submitted for. The two bugs deal with a
different behavior set, 47022 never crashed the browser, I've been to the page
and used parts of it as a reference to build parts of my drag and drop engine...
and experienced similar problems when trying to keep track of objects... this
bug didn't even allow you to get that far.. simply dragging one of the items
crashed the browser... if you want to see what I mean download the build I found
it in and run it...

I took some time to play with the new build and the DOM standard drag and drop
engine, for the first time everything works. All of the points I was concerned
about appear to have been fixed, so feel free to mark this bug as resolved...
but it is not a duplicate.
Ok, thanks for clarification, I will reopen and mark WFM. Sorry for the spam.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
wfm
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 15

18 years ago
Marking VERIFIED.
Status: RESOLVED → VERIFIED

Updated

15 years ago
QA Contact: bugzilla → gerardok
You need to log in before you can comment on or make changes to this bug.