Last Comment Bug 101197 - HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)
: HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 225462 418280 477041 (view as bug list)
Depends on: 432586 497780
Blocks: 382735
  Show dependency treegraph
 
Reported: 2001-09-23 07:37 PDT by Martin Honnen
Modified: 2009-08-24 14:56 PDT (History)
17 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (see description on how to use it) (1.38 KB, text/html)
2001-09-23 07:39 PDT, Martin Honnen
no flags Details
bug example (1.37 KB, text/html)
2009-02-05 05:52 PST, bugzilla33
no flags Details

Description Martin Honnen 2001-09-23 07:37:42 PDT
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>
Comment 1 Martin Honnen 2001-09-23 07:39:12 PDT
Created attachment 50458 [details]
test case (see description on how to use it)
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2001-09-23 09:47:11 PDT
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 ***
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2003-11-12 23:21:02 PST
I'm reopening this.  This is a different bug, way deep under the hood, from bug
97634
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2003-11-12 23:21:40 PST
*** Bug 225462 has been marked as a duplicate of this bug. ***
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2003-11-12 23:24:42 PST
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).
Comment 6 jsp 2003-11-13 10:16:47 PST
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.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2003-11-13 10:58:32 PST
> 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. :(
Comment 8 Hixie (not reading bugmail) 2003-11-13 13:11:38 PST
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.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2003-11-13 13:37:05 PST
> 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?
Comment 10 Aiko 2009-02-05 05:38:45 PST
*** Bug 477041 has been marked as a duplicate of this bug. ***
Comment 11 bugzilla33 2009-02-05 05:52:56 PST
Created attachment 360706 [details]
bug example
Comment 12 bugzilla33 2009-02-05 05:56:02 PST
Confirmed on FF 3.1b3pre
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2009-06-12 07:30:37 PDT
*** Bug 418280 has been marked as a duplicate of this bug. ***
Comment 14 Steve Roussey (:sroussey) 2009-07-22 14:28:11 PDT
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.
Comment 15 Olli Pettay [:smaug] 2009-08-19 06:43:04 PDT
Isn't this now fixed on trunk?
Comment 16 Olli Pettay [:smaug] 2009-08-19 06:43:31 PDT
(and FF3.6/Gecko1.9.2)
Comment 17 John J. Barton 2009-08-19 07:31:55 PDT
(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/
Comment 18 Olli Pettay [:smaug] 2009-08-19 07:35:20 PDT
(In reply to comment #17) 
> As in "accidently" or as a side effect of another fix?
Fixed in another bug, Bug 497780
Comment 19 Steve Roussey (:sroussey) 2009-08-19 09:26:51 PDT
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!!

Note You need to log in before you can comment on or make changes to this bug.