Closed
Bug 6316
Opened 26 years ago
Closed 16 years ago
[ESM/CSS] onmouseout event not deliver when text node changed
Categories
(Core :: DOM: Events, defect, P2)
Core
DOM: Events
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: doyle.davidson, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dom1, testcase, Whiteboard: [nsbeta3-])
Attachments
(3 files)
M5 release: Given a SPAN with an onmouseover and onmouseout event handler:
If I change the text node of an element under JavaScript via DOM, the
onmouseout event is never received. Example HTML:
<HEAD>
<TITLE>My page</TITLE>
<STYLE TYPE="text/css">
.box { color:red; width:7em; padding:0; text-align:center; position:relative;
top:5 }
.box2 { color:yellow; background-color:gray; width:150; padding:0; text-
align:center; position:relative; top:5 }
</STYLE>
</HEAD>
<BODY>
<H1>Welcome</H1>
<P>This is a web page with nothing much of any use.
<SPAN ALIGN="center" CLASS=box ID=it>XX</SPAN>
Isn't this fun?</P>
<SCRIPT LANGUANGE="JavaScript">
var inText = "Sucker!";
var outText = "Move Over Me!";
var e = document.getElementById( "it" );
function set(elem, text)
{
if ( elem.firstChild != null && elem.firstChild.nodeName == "#text" )
{
var newtext = document.createTextNode( text );
elem.replaceChild( newtext, elem.firstChild );
}
}
function doOver()
{
// comment out the following set() and doOut() will be called
set( e, inText );
}
function doOut()
{
// this isn't called it doOver() IS called.
set( e, outText );
}
set( e, outText );
e.onmouseover = doOver;
e.onmouseout = doOut;
</SCRIPT>
</BODY>
|
||
Updated•26 years ago
|
Assignee: vidur → joki
|
|
||
Comment 1•26 years ago
|
||
The problem is that we don't update mouse over state in the EventStateManager
when we do a reflow.
Note that I had to fix a bug in nsRange.cpp (introduced recently) to get the
test to work. I'll file a separate bug on that.
Forwarding to Tom for his list.
|
||
Comment 2•25 years ago
|
||
Still seeing this one.
|
||
Updated•25 years ago
|
Target Milestone: M15
|
|
||
Comment 3•25 years ago
|
||
Mass-moving bugs out of M15 that I won't get to. Will refit individual
milestones after moving them.
Target Milestone: M15 → M16
|
|
||
Comment 7•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
||
Comment 9•25 years ago
|
||
Adding [ESM/CSS] prefix to bugs in EventStateManager with its generated events
or CSS pseudo-class management.
Summary: onmouseout event not deliver when text node changed → [ESM/CSS] onmouseout event not deliver when text node changed
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
|
||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
Whiteboard: [nsbeta3+]
|
|
||
Updated•25 years ago
|
Priority: P3 → P2
It seems like vidur was correct. When content changes we blow some
frames/content and as a consequence the pointer comparisons that check whether
or not we should fire a mouse over event get confused.
Anyway, the axe has hit this bug: nsbeta3-. Image rollovers still work so that
is a workaround.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Future.
Target Milestone: M18 → Future
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW
|
||
Updated•24 years ago
|
Component: DOM Level 1 → DOM Events
FWIW, I see the same thing if I do:
document.getElementById("dynamic").sheet.insertRule(rule, 0);
where the rule matches the class of the element (a span containing only text)
I'm hovering over. Is that a content change?
Where do I look to fix this?
|
||
Comment 17•24 years ago
|
||
*** Bug 60480 has been marked as a duplicate of this bug. ***
|
|
||
Comment 18•24 years ago
|
||
shaver: it should cause a reflow if the font-weight changes, so it's probably
relevant to this bug. But what do I know...
|
||
Comment 20•22 years ago
|
||
I wish someone could clarify what this bug is really about. I'm not sure there
is a bug clearly related to mouseout.
From attachment 10623 [details], I removed "width:7em;" to the css declaration of class
box, then corrected the code a bit, added a doctype and suddenly everything
pretty much worked.
Later I added new elements, other functions and a few other aspects into the
attached test case. Mozilla seems to be making clean distinction between text
node and text node value.
Changing the width of an element due to a mouseover event might have an impact
on the event fired: this is more or less what happens when you mouse-over the
span from the right hand side. You mouse-over the element, the width
diminishes, then you should be out (mouseout) of the element but the browser
does not have time to notice or does not notice.
So, what should be the expected behavior when the mouse comes from the right
hand side of the span and then mouse over the span?
|
||
Comment 21•22 years ago
|
||
I'm not really sure if this testcase is related to this bug. If it isn't, tell
me, and i'll file it as a new bug.
The onmouseout behavior seems to be related to the use of innerhtml to change
the node's text and the changing of the cursor from caret to arrow.
In my proposed testcase, the first row of the table, uses
element.childNodes[0].nodeValue to change the text of the cell, and also
changes the background color.
The second row uses innerhtml to change the text, and the same code to change
the color.
In the first row, mouseout and mouseover behave as expected. In the second row,
the events work as long as you keep the mouse pointer on the right side of the
cell (where the pointer is an arrow). If you place the mouse on the cell's text
(where it becomes a caret), and you move it quickly upwards or downwards, the
onmouseout event doesn't see to be triggered, and the background color is not
changed.
|
||
Updated•20 years ago
|
OS: Windows 98 → All
Hardware: PC → All
|
||
Comment 22•20 years ago
|
||
Is this still an issue?
|
||
Updated•19 years ago
|
Assignee: joki → events
QA Contact: vladimire → ian
|
||
Comment 23•16 years ago
|
||
Seems to be WFM, unless I don't understand this. Please reopen if it is still broken.
Assignee: events → nobody
Status: NEW → RESOLVED
Closed: 16 years ago
QA Contact: ian → events
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•