Last Comment Bug 208427 - <input>'s hidden DIV shows up as event.originalTarget in click events
: <input>'s hidden DIV shows up as event.originalTarget in click events
Status: NEW
[firebug-p3]
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 11 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
data:text/html,<input onclick="alert(...
: 214340 (view as bug list)
Depends on: 432586 234455
Blocks: 330961
  Show dependency treegraph
 
Reported: 2003-06-05 09:29 PDT by neil@parkwaycc.co.uk
Modified: 2013-09-23 14:06 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description neil@parkwaycc.co.uk 2003-06-05 09:29:17 PDT
Steps to reproduce problem:
1. Load the URL
2. Click on the input

Expected results: [object HTMLInputElement]

Actual results: [object HTMLDivElement]

This has no security ramifications because the div element is restricted.
Howver this does make it impossible for content to use originalTarget.
Comment 1 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-07-30 10:16:53 PDT
*** Bug 214340 has been marked as a duplicate of this bug. ***
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-07-30 10:33:02 PDT
Also happens for relatedTarget.

In short, the event needs to be retargeted when it crosses the content boundary
from inside the input to outside it...  XBL does this naturally; the hacks that
we use for input may need some work to do it.
Comment 3 Leif W 2003-10-03 09:40:33 PDT
As mentioned in the duplicate bug 214340, this error also affects javascript
code when triggered by a mouseover/mouseout event over a text input inside a
div.  I've noticed with Mozilla 1.5 rc2 that the error still exists, but the
error message has changed (trivially less information).

Is there any idea on if or when this bug will be fixed?  It has been some months
and there's been no followups.

--
With Mozilla 1.4 it was:

Error: [Exception... "'Permission denied to get property
HTMLDivElement.parentNode' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

And with Mozilla 1.5 rc2 it is:

Error: uncaught exception: Permission denied to get property
HTMLDivElement.parentNode

Example code which causes the error (extracted from URL in duplicate bug 214340):

[...]

function scan ( e )
{
    var r = e.relatedTarget;

    while ( r && r.parentNode )
    {
        r = r.parentNode;
        //alert(r);
    }
};

[...]

<DIV ID="dv" STYLE="position:absolute;left:100;top:100">
  <FORM NAME="frm">
    <INPUT TYPE="textbox" NAME="tbox" VALUE="test..."
      ONMOUSEOVER="scan( event );"
      ONMOUSEOUT="scan( event );">
  </FORM>
</DIV>

[...]
Comment 4 Corey Gilmore 2004-08-25 11:15:47 PDT
Just a gentle reminder that this bug is present in the latest official release
of Firefox on Windows,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

I haven't tested on any other platforms.
Comment 5 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2006-02-28 23:27:13 PST
IMO, one should not be able to access native anonymous in anyway from
(at least untrusted) scripts. For C++ we could to remove
.tmpRealOriginalTarget and have .realOriginalTarget, which would point to the
very first target (before any retargeting) in the event target chain.
Comment 6 Jen 2006-07-06 09:29:51 PDT
I am having this same problem when clicking inside of <input>'s. The <input>'s it is happening on do not have events.  

However, the common factor is that I have fckeditor running on these pages also, so perhaps a problem with focusing from that element to the <input>'s?
Comment 7 Mihai Bazon 2007-06-06 07:11:02 PDT
Any updates on this? -- or possible ways to work around it?
Comment 8 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2007-06-06 13:38:47 PDT
use .target? 
Comment 9 ed 2007-08-16 08:45:53 PDT
Does anyone have a workaround for this issue? I am in shock that for one time in my life I have to redesign because of a bug in firefox not ie. How can I detect the issue because it occurs outside of a function and happens on focus to the textbox? Anyone? ANYONE? ok anyone?
Comment 10 ed 2007-08-16 09:11:07 PDT
Does anyone have a workaround for this issue? I am in shock that for one time in my life I have to redesign because of a bug in firefox not ie. How can I detect the issue because it occurs outside of a function and happens on focus to the textbox? Anyone? ANYONE? ok anyone?
Comment 11 ed 2007-08-16 11:30:13 PDT
(In reply to comment #9)
> Does anyone have a workaround for this issue? I am in shock that for one time
> in my life I have to redesign because of a bug in firefox not ie. How can I
> detect the issue because it occurs outside of a function and happens on focus
> to the textbox? Anyone? ANYONE? ok anyone?
> 
I wil start off by apologizing for the duplicate submission. Now let me clarify the issue I am talking about. The error is Permission denied to get property
HTMLDivElement.parentNode in firebug. This occurs when a user clicks on the text box of a form contained in a div element. The div is not anonymous. I am looking for a possible workaround. My questions are:
*How do I detect the error before displaying?
*Is there a possible way I may alter html to fix issue on my part?
*Why can't I access the related target?should I use .target to access?
*Should I add eventlistener to intercept eventTarget?

Once again sorry for the duplicate submission.


Comment 12 Martin Gutjahr 2007-09-01 02:52:46 PDT
@ed: I have the same here.
Workaround was to handle the access to parentNode in a try/catch-block
and loop max 5 times over ret=something.parentNode.
If ret is something useful, I exit the loop and return the result to 
my calling function. If after 5 times I still have no expected
result, I return an error-state.

Comment 13 Negora 2007-12-14 02:26:17 PST
Wow, when I firstly saw the date of this bug ticket (2003) I thought that had already been fixed and that the bug which I was suffering was different, but "fortunately" this is the same.

Like somebody said before, it seems that form elements are wrapped by a non-visible and "private" DIV element. So, when you try to "climb" higher nodes it throws that exception.

Like Martin, my only way to "avoid" this problem has been to use a "try/catch" statement and, depending on the case, look for an alternative way to get the element which I needed.

I hope this has been fixed in version 3.
Comment 14 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2007-12-14 03:39:48 PST
Normally one should use .target, not .originalTarget which is Mozilla only thing.
Comment 15 Negora 2007-12-14 09:14:59 PST
Well, in my case I was using "relTarget".
Comment 16 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2007-12-14 09:59:39 PST
You mean relatedTarget? This bug is about .originalTarget. If you have problems
with .relatedTarget, please test using the latest firefox 3 nightly build and
if the bug still exists, file a new bug and attach a *minimal* testcase.
Comment 17 Negora 2007-12-14 12:37:28 PST
Ok, excuse me.
Comment 18 Alessandro Vernet 2008-08-05 14:47:44 PDT
(In reply to comment #12)
> Workaround was to handle the access to parentNode in a try/catch-block
> and loop max 5 times over ret=something.parentNode.
> If ret is something useful, I exit the loop and return the result to 
> my calling function. If after 5 times I still have no expected
> result, I return an error-state.

I am wondering why you would need to loop 5 times. Is there any chance that subsequent call to something.parentNode succeed if a previous call failed?
Comment 19 John J. Barton 2009-07-21 20:17:14 PDT
I am posting here based on http://code.google.com/p/fbug/issues/detail?id=2075.
The arguments made there make sense to me.

"... the comments to pay attention to are #2 and #3.
originalTarget was a symptom (and a red herring). Internal div elements that Fx
manages should not be sent back to user space. Generally this is the case, but not so in some circumstances with the INPUT element."

Here is evidence that this problem causes workarounds in major javascript libraries, an area we should be leaving to IE:

(all quoted from the firebug report)
ExtJS
-----
ExtJS (which I use) does not have a good bug list, so here is a search on their forums:
http://www.google.com/#hl=en&q=site%3Aextjs.com+permission+denied+non-chrome+context&aq=f&oq=&aqi=&fp=Xmf0jJ9P_V0

They use the try/catch workaround in the function isTextNode() to get around it,
though they need that solution in other parts of their code as well (despite what
Firebug does, since this error still needs to be handled/ignored to prevent code from
stopping).

Also in ext-base-event.js they make explicit reference to it:
 function elContains(parent, child) {
...
92 	                // In FF if you mouseout an text input element
93 	                // thats inside a div sometimes it randomly throws
94 	                // Permission denied to get property HTMLDivElement.parentNode
95 	                // See https://bugzilla.mozilla.org/show_bug.cgi?id=208427


mochikit
--------

From:
http://trac.mochikit.com/changeset/1089

 	549	            try { 
 	550	                e.relatedTarget().nodeName; 
 	551	            } catch (err) { 
 	552	                /* probably hit a permission denied error; possibly one of 
 	553	                 * firefox's screwy anonymous DIVs inside an input element. 
 	554	                 * Allow this event to propogate up. 
 	555	                 */ 
 	556	                return; 
 	557	            } 


jQuery
------
They use the same technique in the function withinElement, etc. There dev site is
currently down, but when it returns look at ticket #222 from three years ago.


GWT
---
http://code.google.com/p/google-web-toolkit/issues/detail?id=671
http://code.google.com/p/google-web-toolkit/issues/detail?id=638
http://code.google.com/p/google-web-toolkit/issues/detail?id=243
http://code.google.com/p/google-web-toolkit/issues/detail?id=1909



Other links:
http://kendsnyder.com/archives/6-MouseEnter-and-MouseLeave.html
Comment 20 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2009-07-22 07:11:46 PDT
Why is any web script using .originalTarget?
And https://bugzilla.mozilla.org/show_bug.cgi?id=208427#c16
Comment 21 Steve Roussey (:sroussey) 2009-07-22 07:30:42 PDT
It just happens to be *any* property, both existing and nonexistent: originalTarget, relatedTarget, parentNode, xyz, asdf. Since Fx returns the anonymous div [HTMLDivElement] inside the input on the event and not the input itself [HTMLInputElement], doing anything with it causes the permission error.

I did a search of ExtJS for example, and found no reference to originalTarget.

PS: I think the error is confined to the mouseout event for the text input element.
Comment 22 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2009-07-22 07:42:34 PDT
event.target is not the anonymous node when content scripts access the event.

This bug is about event.originalTarget, which is Mozilla only feature and
shouldn't be used in the web, IMHO.

If .relatedTarget points to an anonymous node, that is a different bug (already filed).
Comment 23 Steve Roussey (:sroussey) 2009-07-22 07:46:57 PDT
It was filed but marked as a duplicate. Though I could be missing another bugzilla ID...

https://bugzilla.mozilla.org/show_bug.cgi?id=214340#c1
Comment 24 Steve Roussey (:sroussey) 2009-07-22 08:01:12 PDT
This is not the same as https://bugzilla.mozilla.org/show_bug.cgi?id=497780, btw. If I remember right, in that case if you called Object.prototype.toString.call(node) == '[object XULElement]'. But in this case it is '[object HTMLDivElement]' as referenced in the original post.
Comment 25 Steve Roussey (:sroussey) 2009-07-22 08:04:28 PDT
Here is some of the ExtJS code that checks for the XUL bug and for the the old bug we are talking about here (the use of the try/catch around the nodeType and parentNode):

    var isXUL = Ext.isGecko ? function(node){ 
        return Object.prototype.toString.call(node) == '[object XULElement]';
    } : function(){};
        
    var isTextNode = Ext.isGecko ? function(node){
        try{
            return node.nodeType == 3;
        }catch(e) {
            return false;
        }

    } : function(node){
        return node.nodeType == 3;
    };
        
    function checkRelatedTarget(e) {
        var related = pub.getRelatedTarget(e);
        return !(isXUL(related) || elContains(e.currentTarget,related));
    }

    function elContains(parent, child) {
       if(parent && parent.firstChild){  
         while(child) {
            if(child === parent) {
                return true;
            }
            try {
                child = child.parentNode;
            } catch(e) {
                // In FF if you mouseout an text input element
                // thats inside a div sometimes it randomly throws
                // Permission denied to get property HTMLDivElement.parentNode
                // See https://bugzilla.mozilla.org/show_bug.cgi?id=208427
                
                return false;
            }                
            if(child && (child.nodeType != 1)) {
                child = null;
            }
          }
        }
        return false;
    }

Example:
http://extjs.com/deploy/dev/examples/menu/menus.html

Just move the mouse back and forth (quickly!) over all the buttons (be
sure to include the textfield in there). 

With break on errors set, it will stop in Firebug when trying to access
properties on the Firefox inserted div inside an input element.
Comment 26 Steve Roussey (:sroussey) 2009-07-22 14:26:38 PDT
Some more checking. relatedTarget does seem to be the cause of my test cases. Here is a simple one:

<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>


The earliest bug for this from 2001:
https://bugzilla.mozilla.org/show_bug.cgi?id=101197

This might be related:
https://bugzilla.mozilla.org/show_bug.cgi?id=382735
Comment 27 Ufku 2013-09-23 14:06:16 PDT
Anonymous div alsıo ruins dragenter/dragleave events of textareas. Is there a workaround to fix this?

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