The default bug view has changed. See this FAQ.

HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
16 years ago
8 years ago

People

(Reporter: Martin Honnen, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
I wrote some JavaScript code to investigate onmouseover events that outputs the
results to a textarea. When you mouseover/out of text inside the textarea the
event.relatedTarget is a HTMLDivElement which has the textarea as the
parentNode. I can event set the style of the div or add another element to it,
for instance an input type="text" element which sits then inside what is
supposed to be a textarea.

The test code is as follows below. To find the div element you need to load the
page, then move the mouse from outside the content area into the content area,
then inside the textarea, and then over and out of the text in the longest line
in the textarea. The JavaScript code outputs some details about the div element
and then sets its background color and appends an input type="text" element
which appears inside the textarea.

<html>
<head>
<title>
div in textarea ??
</title>
<script type="text/javascript">
document.onmouseover = function (evt) {
  if (evt && document.implementation) {
    output(evt.type + ': relatedTarget: ' + evt.relatedTarget);
    if (evt.relatedTarget.nodeName.toLowerCase() == 'div') {
      document.onmouseover = null;
      var r = 'div details!!!!:\n';
      for (var p in evt.relatedTarget)
        if (typeof evt.relatedTarget[p] != 'function' && p != 'innerHTML')
          r += p + ': ' + evt.relatedTarget[p] + '\n';
      r += 'div.childNodes.length: ' + evt.relatedTarget.childNodes.length + '\n';
      for (var i = 0; i < evt.relatedTarget.childNodes.length; i++)
        r += i + ': ' + evt.relatedTarget.childNodes[i] + '\n';
      r += 'end div details!!!!\n';
      output(r);
      output('parentNode == textarea: ' + (evt.relatedTarget.parentNode ==
document.getElementById('output')));
      output('textarea.childNodes.length: ' +
document.getElementById('output').childNodes.length);
      evt.relatedTarget.style.backgroundColor = 'lightblue';
      evt.relatedTarget.appendChild(document.createElement('input'));
    }
  }
}
function output (text) {
  document.getElementById('output').value =
    text + '\n' +
    document.getElementById('output').value;
}
</script>
</head>
<body>
<textarea id="output" rows="30" cols="80"></textarea>
</body>
</html>
(Reporter)

Comment 1

16 years ago
Created attachment 50458 [details]
test case (see description on how to use it)
Duplicate of "Event.target.parentNode of the Text element passed to a
DOMCharacterDataModified/DOMNodeInserted listener is incorrect for a
<textarea>'s contents."

*** This bug has been marked as a duplicate of 97634 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Blocks: 31812
No longer blocks: 31812
I'm reopening this.  This is a different bug, way deep under the hood, from bug
97634
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 225462 has been marked as a duplicate of this bug. ***
Over to DOM events.  This is actually pretty serious... The problem is that
event retargeting does not change relatedTarget.  It probably should.  Otherwise
pages get access to all sorts of things they should have no access to (and run
up into some security checks we have, even, but it's better they simply get no
access to these nodes.

I would think we just want to null out the relatedTarget when we retarget (I
don't see any better options).
Assignee: rods → events
Status: REOPENED → NEW
Component: Layout: Form Controls → DOM Events
QA Contact: madhur → ian

Comment 6

14 years ago
The DOM2 Event spec says relatedTarget "is used with the mouseover event to
indicate the EventTarget which the pointing device exited and with the mouseout
event to indicate the EventTarget which the pointing device entered."  Setting
relatedTarget to null hides the extra div from the page author, which is a good
thing, but doesn't completely implement the spec.  I think relatedTarget to
point to whatever element it would point to if the extra div were not there
would meet the spec.

I don't know the code, so I don't know whether it's feasible to do this.  I
mention it in case it is, to avoid potential headaches in the future.  It
doesn't affect me, but someone may eventually wonder why relatedTarget is null
when the spec leads him/her to believe it should be, say, a form.
> I don't know the code, so I don't know whether it's feasible to do this.

I don't believe it is, in fact...

In fact, just handling this during retargeting won't work either, since the
actual event targeting chain may lie completely through non-anonymous elements,
while the relatedTarget may be some random anonymous node.

I bet XBL depends on non-null relatedTarget stuff somewhere too...  This is a
total mess. :(
As I understand it, XBL does the equivalent this as follows:

   * if a mouseover event goes from one anonymous node to another anonymous
     node with the same explicit parent, or to/from an anonymous node from/to an 
     explicit node, it doesn't bubble into the parent (or beyond).

   * if a mouseover event goes from one anonymous node to another node with a 
     different scope or different explicit parent, then the related node and
     target nodes are adjusted so that it looks like the mouseover happened over
     nodes of the same scope.

Basically, it prevents nodes from different scopes seeing the anonymous content.

Or something like that.

Anyway, in summary, when we mouseover from the div to the textarea/input, we
should probably just abort the bubbling.
> Anyway, in summary, when we mouseover from the div to the textarea/input, we
> should probably just abort the bubbling.

What if we mouseover from the <div> to the <body> ?  Eg if the textarea borders
are turned off?

Updated

8 years ago
Duplicate of this bug: 477041

Updated

8 years ago
OS: Windows 95 → All
Hardware: x86 → All
Summary: HTMLTextAreaElement seems to contain HTMLDivElement → HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)

Comment 11

8 years ago
Created attachment 360706 [details]
bug example

Comment 12

8 years ago
Confirmed on FF 3.1b3pre
Depends on: 432586
Duplicate of this bug: 418280
Blocks: 382735
Small additional test case:


<html>
<body >
	<div id="joe" style="background-color:red">
		<img src="http://cf.staticac.com/blank.gif" height="40" width="100"/>
	</div>
	<div id="tom">
		<input id="chris"/>
	</div>
</body>
<script>
	var s=document.getElementById('joe');
	s.addEventListener('mouseout',function(e){var t=e.relatedTarget.nodeType;},document)
</script>
</html>

To test move the cursor back and forth (quickly!) between red area and the input element.
Isn't this now fixed on trunk?
(and FF3.6/Gecko1.9.2)

Comment 17

8 years ago
(In reply to comment #15)
> Isn't this now fixed on trunk?

As in "accidently" or as a side effect of another fix?

FYI Steve, Firebug 1.5a21 mostly works on Firefox 3.6a1 if you want to give it a try,

https://developer.mozilla.org/devnews/index.php/2009/08/07/firefox-3-6-alpha-1-now-available-for-download/
(In reply to comment #17) 
> As in "accidently" or as a side effect of another fix?
Fixed in another bug, Bug 497780
It seems fixed in 3.6a1. Bug 497780 seemed a different case, but both that one and this one were really about retargeting internal elements back to user elements for relatedTarget.

What are the chances of this fix landing in Fx 3.5.3? Please!!
Assignee: events → nobody
QA Contact: ian → events
Status: NEW → RESOLVED
Last Resolved: 16 years ago8 years ago
Depends on: 497780
Flags: in-testsuite?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.