Closed
Bug 381825
Opened 18 years ago
Closed 18 years ago
mouseOver & mouseUp from/to input text element from containing element generate spurious events with bad relatedTargets
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: alexander.bocast, Unassigned)
Details
Attachments
(1 file, 3 obsolete files)
1.54 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
If you swipe horizontally over a text box that is completely within a containing element, four mouseOver and mouseOut events are always generated, but the mouseOver or mouseOut events for which the text box should be the relatedTarget generate instead a faulty relatedTarget, which throws an exception if any property is requested. If you swipe over the same text box vertically, the number of reported events may may be 0, 4, 6, or 8. The spurious events are of two types: one type generates a faulty relatedTarget, which throws an exception if any property is requested; the other type reports that the relatedTarget is the same as the target. If one or more of the latter type of event is present, they seem to be always between a pair of mouseOver & mouseOut events with faulty relatedTargets. The exception thrown is: [Exception... "'Permission denied to get property HTMLDivElement.id' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no]
I would attach the powerpoint slides I have used to work out these patterns from event transcripts, but I don't see how to do that...
Reproducible: Always
Steps to Reproduce:
1. run my event testing page (which I would attach if I could see how to do that...)
2. move mouse horizontally across input text box
3. move mouse vertically across input text box
Here's code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>test DOM event propogation</title>
<script language="javascript" type="text/javascript">
function bubbleMouseIn(evt) {
frames["messages"].document.write( "bubbleMouseIn: "+evt.currentTarget.id+" target ["+evt.target.id+"]<br>" );
if( evt.relatedTarget ) {
frames["messages"].document.write( "bubbleMouseIn: "+evt.currentTarget.id+" related ["+evt.relatedTarget.id+"]<br>" );
} }
function bubbleMouseOut(evt) {
frames["messages"].document.write( "bubbleMouseOut: "+evt.currentTarget.id+" target ["+evt.target.id+"]<br>" );
if( evt.relatedTarget ) {
frames["messages"].document.write( "bubbleMouseOut: "+evt.currentTarget.id+" related ["+evt.relatedTarget.id+"]<br>" );
} }
function startup() {
document.getElementById("tr.div.text").addEventListener("mouseover",bubbleMouseIn,false);
document.getElementById("tr.txt").addEventListener("mouseover",bubbleMouseIn,false);
document.getElementById("tr.div.text").addEventListener("mouseout",bubbleMouseOut,false);
document.getElementById("tr.txt").addEventListener("mouseout",bubbleMouseOut,false);
}
</script>
<style>
div.text { height: 40px; background-color:#D5D5D5; }
input[type="text"] { border: none; position: relative; top: 10px; left: 20px; }
</style>
</head>
<body onLoad="startup();">
<form id="frm.callback" name="callback" method="post" action="domevents.html" >
<div id="tr.div.text" class="text" >
<input type="text" id="tr.txt" name="term" value="term" >
</div text>
</form>
<iframe height="600" id="messages" name="messages" scrolling="auto" width="600"></iframe>
</body></html>
Actual Results:
number of mouseOver & mouseOut events varies depending upon direction of traversal. number of events generated for vertical traversal (including 0 events) appears loosely correlated with speed of traversal. at least one faulty relatedTarget is always generated, which will raise an exception if any attempt is made to access any of its properties.
Expected Results:
In any direction, exactly four events should be reported in a transcript when a text box and its containing element are both listeners: (1) mouseOut: leaving containing element to enter text box (2) mouseOver: entering text box from containing element (3) mouseOut: leaving text box to return to containing element (4) mouseOver: entering containing element from text box. None of these events should reference a faulty relatedTarget. None of these mouseOut or mouseOver events should identify the relatedTarget as the target.
This bug appears to be identical to one reported at quirksMode ( http://www.quirksmode.org/bugreports/archives/2005/11/extraneous_and_erronous_Mozilla_mouseover_and_mous.html)
This bug may be related to Bug 369644: text inputs trigger spurious mouseout/mouseovers at the border (https://bugzilla.mozilla.org/show_bug.cgi?id=369644) However, Bug 369644 does not address: (a) thrown exceptions, (b) different behaviors in different directions of mouse movement, or (c) varying numbers of generated events.
Reporter | ||
Comment 1•18 years ago
|
||
Comment 2•18 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070523 Minefield/3.0a5pre
Could you retest on a nightly trunk build, for this appears to be fixed.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
If your conclusion is the same, you can resolve this bug as WORKSFORME.
Reporter | ||
Comment 3•18 years ago
|
||
The problem with faulty relatedTargets and relatedTargets = target does appear to be resolved. However:
Horizontally: Instead of the expected sequence [ out in out in ], only [ in out ] is generated. A mouseOut when the mouse moves from the containing element into the text box is not generated nor is a mouseOver generated when the mouse moves from the text box into its containing element.
Vertically: All events of the expected sequence [ out in out in ] are not always generated. I have observed [ in out in ], [ out in out ], [ in out ], and [ ].
In addition, in one case, instead of the expected transitions from the input text box to its containing DIV to a select element on the other side of the containing DIV:
bubbleMouseOut: tr.div.text target [tr.txt] related [tr.div.text]
bubbleMouseIn: tr.div.text target [tr.div.text] related [tr.txt]
bubbleMouseOut: tr.div.text target [tr.div.text] related [tr.div.select]
this single event was reported:
bubbleMouseOut: tr.div.text target [tr.txt] related [tr.div.select]
Reporter | ||
Comment 4•18 years ago
|
||
Checked whether the anomalous eventPhase for a target input text element might also have been addressed while fixing this bug. This does seems to have been worked on. However, a new eventPhase anomaly seems to have been introduced. Here is a transcript of capture & bubble propagation of an onClick event, showing a mouse click on a text box:
captureClick: tr.div.combocontainer target[tr.txt] phase[1]
captureClick: tr.div.text target[tr.txt] phase[1]
captureClick: tr.txt target[tr.txt] phase[2]
bubbleClick: tr.txt target[tr.txt] phase[2]
bubbleClick: tr.div.text target[tr.txt] phase[3]
bubbleClick: tr.div.combocontainer target[tr.txt] phase[3]
captureClick: tr.div.language.term target[tr.txt] phase[3]
bubbleClick: tr.div.language.term target[tr.txt] phase[3]
The outermost click capture appears in the midst of the bubble propagation and its phase is reported as bubbling (3) instead of capture (1). The transcript should look like:
captureClick: tr.div.language.term target[tr.txt] phase[1]
captureClick: tr.div.combocontainer target[tr.txt] phase[1]
captureClick: tr.div.text target[tr.txt] phase[1]
captureClick: tr.txt target[tr.txt] phase[2]
bubbleClick: tr.txt target[tr.txt] phase[2]
bubbleClick: tr.div.text target[tr.txt] phase[3]
bubbleClick: tr.div.combocontainer target[tr.txt] phase[3]
bubbleClick: tr.div.language.term target[tr.txt] phase[3]
Should this be reported as a separate bug?
Reporter | ||
Comment 5•18 years ago
|
||
Please strike all but the first two sentences of Comment 4. The propagation and phase identification for onClick are working peachy, and thank you.
Updated•18 years ago
|
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Updated•18 years ago
|
Attachment #265899 -
Attachment description: asp page with javascript to recreate anomalies → page with javascript to recreate anomalies
Attachment #265899 -
Attachment filename: domevents-stripped.asp → domevents-stripped.html
Attachment #265899 -
Attachment mime type: application/x-asp → text/html
Comment 6•18 years ago
|
||
This modified testcase includes relatedTarget information even if it's undefined, an inaccessible node (which appears to happen in Firefox 2.0.0.2 but not on trunk), or an element that doesn't have an id.
Attachment #265899 -
Attachment is obsolete: true
Comment 7•18 years ago
|
||
Those "secret divs inside the textbox" are still leaking into the page's event model on trunk :( This happens when the cursor moves across the left border of the textbox; you'll see the testcase say "originalTarget: [Permission denied?]".
Attachment #269570 -
Attachment is obsolete: true
Comment 8•18 years ago
|
||
The bogus originalTarget is probably bug 208427.
The difference in behavior between entering/exiting the right side of the textbox horizontally vs. vertically does seem like a bug to me. It seems to be related to whether the originalTarget is the textbox or the "secret inner div". If I move in horizontally but on the bottom pixel, I see the same behavior as moving in vertically.
Comment 9•18 years ago
|
||
Using stopPropagation keeps the bubbling events from showing up twice and confusing everyone.
Attachment #269571 -
Attachment is obsolete: true
Comment 10•18 years ago
|
||
I've split off comment 3 and comment 8 into bug 385625.
Everything else here works correctly on trunk (right?) so I'm marking this bug as WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Comment 11•18 years ago
|
||
There still seems to be an issue when the mouseover/out event is from one input to another input. Sometimes instead of the other input being the relatedTarget, it is the hidden div of that input. Should this be filed as a new bug?
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•