Closed Bug 298189 Opened 20 years ago Closed 19 years ago

between mousedown and mouseup, all mouse events report the target as the element that caused the mousedown

Categories

(Core :: DOM: Events, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: johbjo09, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)

in between the time a mousedown event has fired on an element, and the mouse
button is released, the event target of all mouse-related events will report the
element that caused the mousedown as target, even though the mouse pointer moves
over other elements. this seems wrong.

if the mouse button is released, regardless of whether a mouseup listener is
registered, the mousemove event will report the element under the pointer as the
target, which is correct.

when implementing drag and drop, this is extremely irritating. it is impossible,
or very awkward, to implement the drop without being able to tell which element
the drag is hovering over.


Reproducible: Always

Steps to Reproduce:
1. set a callback for document.onmouseover and one for onmousedown of an element
2. fire the onmousedown event and hold the mouse button down
3. monitor the .target member of the object that is passed to the onmouseover
callback
Actual Results:  
.target points to the element with the onmousedown callback.

Expected Results:  
.target should have pointed to whatever element the mouse moved over.
Reporter, is it possible for you to attach a testcase showing what you describe
to this bug?
Attached file Test case
I investigated a bit further and it seems this has to do with positioning and
how the event system handles different "layers" (I don't know the internals).

The problem is that after a mouse press in a div that has relative or absolute
positioning, no event outside of this div will get the correct event target
while the mouse is pressed down. They will get correct targets within their
divs.
Attached file Second testcase
It seems to work when the source element has css style -moz-user-select: none;

And it only works when starting the drag on the text, not on the rest of the
area (compare starting the drag from the blue area with starting it from the
text in the relative box)
Keywords: testcase
So... I can't quite tell what I should be seeing with the testcases, but the
behavior is looking ok over here.  Johan, could you please more clearly explain
what the steps to reproduce the bug, expected behavior, and actual behavior are,
and test with a current trunk build (eg the Deer Park alpha), not the ages-old
1.7 Gecko branch?
(In reply to comment #4)
> So... I can't quite tell what I should be seeing with the testcases, but the
> behavior is looking ok over here.  Johan, could you please more clearly explain

Ah yes, it works as expected with build 2005062807. I should have tested it with
newer releases before submitting.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reopen to mark WFM. Fixed is only for when the code change that caused the fix
is known.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: