If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Javascript event-handler defined with "document.onmouseover" may behave inconsistently

RESOLVED EXPIRED

Status

()

Core
DOM: Events
RESOLVED EXPIRED
15 years ago
4 years ago

People

(Reporter: Gerrit Zimmermann, Assigned: saari (gone))

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

in JavaScript an event-handler definied for onMouseOver should be called each
time the mouse passes over a DOM-object. This is true, if 
1) all DOM-objects exist at loading (i.e. have been defined in the original
html-document).
or 2) user-created objects (with javascript-functions "newDiv =
document.createElement("div")" and
"document.getElementById(ParentObjectID).appendChild(newDiv)") are appended only
to objects existing at loading

If multiple childNodes are appended to one another some objects will no longer
spawn the onMouseOver-event.

Reproducible: Always

Steps to Reproduce:
A page demonstrating the problem can be found at the given URL.

1. Load page
2. Click and Drag Mouse anywhere on the page. A new "div"-object is created.
3. Move Mouse into and out of the new object. Watch the two input-fields. They
should give the id of the object, the mouse is currently positioned over and a
count of how often the event-handler has been called.
4. Repeat steps 2. and 3. If the second (and forth and so on) newly created
object is created inside another "div"-object, it is appended to it as a
childNode; otherwise the object's parent becomes the "body"-element; as long as
all created objects are siblings, behaviour is as expected. Otherwise some
objects won't spawn the onMouseOver-event any longer (always the same objects
for a given configuration of the tree).
Actual Results:  
See text above.

Expected Results:  
See text above.

Seems to be system-independent (occured on W2K and W98SE), could be reproduced
with Mozilla 1.0, 1.1 and 1.3a (1.2 not tested).

Comment 1

15 years ago
Sorry, but you script contains an error. In this line:

newDiv.style.top = Event.pageY -
parseInt(document.getElementById(LastObjectID).style.top);

See, Event.pageY get mouse coordinated from body box, and style top -- is
distance between two included boxes, so third box top evaluated incorrecly. Look
here:
--------------------------------------------------
Body box    ^
            |  style.top for 1th div
            V
------------------------------------------------------------
|                  ^
| 1th div          |   this is style.top for 2nd div
|                  V
|   --------------------------------------
|   |                                    |
|   |        x <--- Mouse pressed here   |
|   |                                    |
|   --------------------------------------
------------------------------------------------------------

so right value should be PageY - style.Top(2nd div)  - style.Top(1th div)
(Reporter)

Comment 2

15 years ago
Ok, Ruslan, you were right. I corrected the script's behaviour, but the error
stays the same.

Comment 3

15 years ago
Sorry, there are another bug, linked with border-width, that you don't count in 
evaluateParams(). You better try position:fixed div's (absolute positioned
elements are awesome to scripting). I made a testcase for it.

Comment 4

15 years ago
Created attachment 110657 [details]
Same testcase with position:fixed div's

Sorry, I could not do the same job with position:absolute -- it brain me out.
I bet the real issue is the positioning, anything else...
Whiteboard: DUPEME
(Reporter)

Comment 6

15 years ago
Call me dumb, but this really seems to be some obscure error in my script. 

With a *much* simplified Version (http://data-development.de/rd/js/working.html)
of the test-script the supposed error disappeared.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
(Reporter)

Comment 7

15 years ago
So now I've really made a fool of myself. I checked (and refined) my original
script quite thoroughly now and am sure the behaviour I described is no error of
mine.
The error occurs only if the objects created are resized by capturing
onMouseMove; if created with fixed width or resized only once (onMouseUp)
everything works as expected. So this might not be a real showstopper, since I
found a way to work around it, but it is an error nevertheless.

I've created two scripts to show the error. One is a working implentation, the
other has the error. The scripts differ in some object-juggling, only.

Working: http://www.data-devlopment.de/rd/js/testcase1.html
Error: http://www.data-devlopment.de/rd/js/testcase2.html
Severity: major → normal
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 8

15 years ago
At any rate, this is not JS Engine. Reassigning as a guess
to DOM Events for further analysis -
Assignee: rogerl → saari
Component: JavaScript Engine → DOM Events
QA Contact: pschwartau → vladimire

Comment 9

15 years ago
The site is not up, can you please attach the testcases to the bug?

Comment 10

15 years ago
Comment on attachment 110657 [details]
Same testcase with position:fixed div's

reporter (Gerrit Zimmermann),
http://www.data-devlopment.de/rd/js/testcase1.html and testcas2.html are
not working. can you post the testcases as attachment?

(related? bug 14692)
Attachment #110657 - Attachment filename: testcase1.html → 187665.html
Attachment #110657 - Attachment is obsolete: true
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago12 years ago
Resolution: --- → EXPIRED

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.