Closed Bug 101197 Opened 23 years ago Closed 15 years ago

HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martin.honnen, Unassigned)

References

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

Details

Attachments

(2 files)

test case (see description on how to use it)
1.38 KB, text/html
Details
bug example
1.37 KB, text/html
Details 
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>
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
Closed: 23 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
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?
OS: Windows 95 → All
Hardware: x86 → All
Summary: HTMLTextAreaElement seems to contain HTMLDivElement → HTMLTextAreaElement seems to contain HTMLDivElement (wrong event.relatedTarget)
Attached file bug example — 

    
    

    
  
Confirmed on FF 3.1b3pre
Depends on: 432586
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)

    
    

    
  
(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
Closed: 23 years ago → 15 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: