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)
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.
Comment 1•20 years ago
|
||
Reporter, is it possible for you to attach a testcase showing what you describe to this bug?
| Reporter | ||
Comment 2•20 years ago
|
||
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.
| Reporter | ||
Comment 3•20 years ago
|
||
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)
Comment 4•19 years ago
|
||
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?
| Reporter | ||
Comment 5•19 years ago
|
||
(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
Comment 6•19 years ago
|
||
Reopen to mark WFM. Fixed is only for when the code change that caused the fix is known.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Updated•19 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•