Side navigation
#7729 closed bug (duplicate)
Opened December 08, 2010 01:24PM UTC
Closed February 08, 2011 03:41PM UTC
Last modified March 13, 2012 09:01PM UTC
mouseenter/leave is fired from bubbled up mouse events happening on child-input-fields
| Reported by: | phofstetter@sensational.ch | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.5.1 |
| Component: | event | Version: | 1.5 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
A parent's mouseenter/mouseleave events are fired when the mouse moves over an <input> field somewhere in the child hierarchy.
This is contrary to the documentation which says that mouse(enter|leave) should only fire if the mouse enters/leaves the element the handler is attached to, but not any of its children.
I've created a reduced testcase on http://jsfiddle.net/qs9f2/. The code is basically the same as the example code that was on the API documentation for mouseleave(). As you see, events are generated when you move your mouse over the <input>-element.
Seen in:
- Chrome (8 and 9)
- Safari 5.0.2
So it look as if this is primarely an issue with webkit browsers.
Expected results:
When you move the muse over the input field, "enter" should appear one in the logging-div. When you move the mouse away from the input field, but stay inside the outer div, nothing should appear in the logging div
Actual results:
When you move over the input field, "leave" is logged. When you move out of the input field, "enter" is logged.
Attachments (0)
Change History (10)
Changed December 08, 2010 02:07PM UTC by comment:1
Changed December 08, 2010 02:32PM UTC by comment:2
Here's a patch that fixes this issue:
http://www.pilif.ch/safari-mouseenter.diff
I think it's save to treat an element that's not part of the DOM but still just got a mouse event fired on the same way as an element where reading its parentNode throws an exception.
Changed December 08, 2010 02:39PM UTC by comment:3
And for people in need of a client-side fix that doesn't require patching jQuery, at the beginning of your mouseenter or mouseleave handler, add
if (e.originalEvent.relatedTarget &&
e.originalEvent.relatedTarget !== document &&
!e.originalEvent.relatedTarget.parentNode)
return;
to discard the bogus events in Webkit based browsers.
Changed December 08, 2010 02:39PM UTC by comment:4
if (e.originalEvent.relatedTarget &&
e.originalEvent.relatedTarget !== document &&
!e.originalEvent.relatedTarget.parentNode)
return;
Changed December 08, 2010 06:34PM UTC by comment:5
Thanks for taking the time to contribute to the jQuery project by writing a bug report and providing a test case!
I tried this cleaned version of your test case with Opera 10.63, FF 3.6.12, Safari 5.0.3, Chrome 8.0.552.215 and Chrome 9.0.597.10 (all on Windows)
The only one where I could reproduce an incorrect behavior was Chrome 9.0.597.10 which is a development version. All other browsers behave as expected. Triggering one "enter" when moving onto the div and one "leave" when moving of the div. No unwanted enter/leave messages are displayed when moving over/out the input.
So after trying hard I couldn't reproduce this bug.
Changed December 08, 2010 06:48PM UTC by comment:6
| component: | unfiled → event |
|---|---|
| priority: | undecided → low |
| resolution: | → worksforme |
| status: | new → closed |
I close this bug for now as we are unable to reproduce this except on a dev version of Chrome (you should file a bug there).
If you can provide a valid test case which reproduces the behavior please report back and request the reopening of the ticket.
Changed February 08, 2011 03:41PM UTC by comment:7
| milestone: | 1.6 → 1.5.1 |
|---|---|
| resolution: | worksforme |
| status: | closed → reopened |
| version: | 1.4.4 → 1.5 |
Changed February 08, 2011 03:41PM UTC by comment:8
| resolution: | → duplicate |
|---|---|
| status: | reopened → closed |
a bit of investigation has shown that in Webkit browsers, when the bogus event ist fired,
originalEvent.relatedTarget
is set to a <div> that's otherwise not part of the DOM but contains the input's value, so this must be some implementation specific internal div. Now to find out how we can detect that this otherwise completely detached div is actually a child of the parent where mouseleave is attached to.