Open Bug 208427 Opened 22 years ago Updated 2 years ago

<input>'s hidden DIV shows up as event.originalTarget in click events

Categories

(Core :: DOM: Events, defect, P5)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

People

(Reporter: neil, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: [firebug-p3])

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.
*** Bug 214340 has been marked as a duplicate of this bug. ***
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.
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> [...]
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.
Depends on: 234455
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.
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?
Blocks: 330961
Any updates on this? -- or possible ways to work around it?
use .target?
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?
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?
(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.
@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.
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.
Normally one should use .target, not .originalTarget which is Mozilla only thing.
Well, in my case I was using "relTarget".
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.
Ok, excuse me.
(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?
Assignee: saari → nobody
QA Contact: desale → events
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
Whiteboard: [firebug-p3]
Why is any web script using .originalTarget? And https://bugzilla.mozilla.org/show_bug.cgi?id=208427#c16
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.
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).
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
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.
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.
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
Anonymous div alsıo ruins dragenter/dragleave events of textareas. Is there a workaround to fix this?
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.