To reproduce (instructions here are rather abstract): 1. Make a function, which gets called when clicking a link on a html page 2. This JS function looks like this: node.style.visibility = "collapse"; node.parentNode.rows[node.rowIndex+1].style.visibility = "collapse"; alert(8); node.previousSibling.getElementsByTagName("TD")[0].childNodes[0].childNodes[1].nodeValue = "Show Comment"; node.previousSibling.getElementsByTagName("TD")[0].childNodes[0].childNodes[0].src = "chrome://nickblock/content/plus.gif" (node referrs to a TR table line) Now this error (it appears 3 times) occours when this function is called, _before_ the alert is displayed: Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://some.web.site.doesnt.matter :: show_hide :: line 0" data: no] Source File: http://some.web.site.doesnt.matter Line: 0 and this error after i click OK in the alert: Error: [Exception... "'Permission denied to get property XULElement.disabled' when calling method: [nsIDOMXULControlElement::disabled]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://some.web.site.doesnt.matter :: show_hide :: line 0" data: no] Source File: http://some.web.site.doesnt.matter Line: 0 If i remove the alert, everything is ok and errors appear in JS console. Happens with a current trunk build.

(In reply to comment #0) > If i remove the alert, everything is ok and errors appear in JS console. Happens > with a current trunk build. That must be "and NO errors appear in JS console".

I think this was probably fixed by the fix for bug 260657. WFM If you test with the lastest builds and it's still a problem, reopen, but also please attach a testcase html file. Thanks.

aaronl: when did that fix land? the bug referenced was closed before this bug was filed

(In reply to comment #3) > aaronl: when did that fix land? the bug referenced was closed before this bug > was filed Yes but that doesn't mean his build was up-to-date. Timeless are you able to repro?

(In reply to comment #3) > aaronl: when did that fix land? the bug referenced was closed before this bug > was filed And as it says in that bug, it landed 2004-09-21 19:38 PDT

and this was reported 3 days later. i experienced something like this last friday, but i didn't take notes.

With a build from 26th this still appears, also the accessKey warning only appears two times (and the disabled warning one time). Well test case, if you really want to do the work installing it ;-), follow the instructions in Bug 261450 Comment 0 until Step 6 (you need to manually install a extension). When you click on the Hide Comment link, you'll see the warnings happen.

Don't mean to be rude, but personally when I file a bug I always attach a testcase file to make it easy for the developer.

Is this something that can be reproduced with a simplified HTML file that has not requirement for installing your extension?

Yes it is, but it takes some time to create it ;-). Just click the link in the testcase and you should see three warning after you clicked OK in the alert (i know on the original page parts of the warnings appeared also before that but i couldnt figure out why).

I'm still not able to duplicate this result. On mcsmurf's machine, just typing this in the URL bar prodcues the errors: javascript:alert('8') So the HTML that creates the alert is not relevant

(In reply to comment #11) > just typing this in the URL bar prodcues the errors: javascript:alert('8') CONFIRMED on 2004092805-trunk. WORKSFORME on 2004100504-trunk. When 2004092805-trunk(Win-2K), "javascript:alert('8') in URLbar" caused the JavaScript error of "Permission denied". But this JavaScript Error did not occur on 2004100504-trunk. Only check-in delay of fix for bug 260657? Or fixed by other bug?

bugs in linux gtk2+xft seamonkey 1.8a4: - attachment 161371 [details] in bug 263319 when clicking on "Open Popup Window" button - attachment 160348 [details] - javascript:alert('8') in URLbar Doesn't happen in gtk2+xft firefox aviary 20041007

I allways get this error in the JavaScript console with bug 269671. I thought it was a tech-evnagelism issue but now I think it could be related to this bug.

resolving worksforme now, i haven't seen this error anymore in a long time now (testcases are also wfm now), if someone disagrees, reopen or comment.

Go to http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/MSIE6Bugs.html (also same happening at http://www.gtalbot.org/BrowserBugsSection/Opera7Bugs/Opera7Bugs.html ) and click a link with Mozilla 1.8b2 build 2005040705 under XP Pro SP2 and I get 34 occurences of Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/MSIE6Bugs.html :: OpenRequestedPopup :: line 59" data: no] Source File: http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/MSIE6Bugs.html Line: 59 in the javascript console. The window opens slower than usual too, most likely because of the 34 errors being generated. If you click another link, then [expected results] you should recycle, re-use the secondary window (with window.name = "RequestedPopup") but you'll get another secondary window instead. That page used to work without problems in the past.

REOPENING

The javascript console error report happens when you try attachment 161371 [details] Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=161371 :: onclick :: line 1" data: no] Source File: https://bugzilla.mozilla.org/attachment.cgi?id=161371 Line: 1

*** Bug 236765 has been marked as a duplicate of this bug. ***

I have gotten this bug very consistently. I am now using Firefox 1.0.2, having installed from FF Central yesterday. If you would like an example, I could provide one easily - it occurs with many forms that I have, but does not occur in NN 7.2

WFM clean profile, but I can reproduce it with my regular profile. The only extensions I use are autoscroll and flashblock.

(In reply to comment #21) > WFM clean profile, but I can reproduce it with my regular profile. The only > extensions I use are autoscroll and flashblock. In my regular profile I can reproduce just by doing any alert()s... for example, putting this in the URL bar and hitting enter: javascript:alert("rheet"); I don't need all the stuff in the attached testcase.

I'm getting a similar error, but for the selectedIndex object, when calling a function that checks the length of a field value, and if it's a certain value, it changes the focus to the next field. I'm running FF 1.0.6. The specific line of code producing the error (where 'next_field' is the name of a input object on the page, and TabNext is the function) is: next_field.focus() Error: [Exception... "'Permission denied to get property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://192.168.11.20/totalatty/referral_leads/form.asp :: TabNext :: line 363" data: no] Source File: http://192.168.11.20/totalatty/referral_leads/form.asp Line: 363

> I'm getting a similar error, but for the selectedIndex object, when calling a > function that checks the length of a field value, and if it's a certain value, > it changes the focus to the next field. That's bug 236791.

I get this error in the JavaScript Console too by just triggering an alert(). The testcase seems to be obselete. All it does is make the following show up in the JavaScript Console: Error: document.childNodes[0].childNodes[2] has no properties Source File: https://bugzilla.mozilla.org/attachment.cgi?id=160348 Line: 8

This also happens when you call a prompt window.

however using seamonkey 1.0 on Linux I still get this error by simply typing javascript:alert('8'); in the URL bar This the exact count and messages shown in the javascript console, for 1 call of alert('8'); Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: javascript:alert('8'); :: <TOP_LEVEL> :: line 1" data: no] Source File: javascript:alert('8'); Line: 1 Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: javascript:alert('8'); :: <TOP_LEVEL> :: line 1" data: no] Source File: javascript:alert('8'); Line: 1 Error: [Exception... "'Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: javascript:alert('8'); :: <TOP_LEVEL> :: line 1" data: no] Source File: javascript:alert('8'); Line: 1

javascript: alert("foo"); will reproduce the bug in Seamonkey 1.5a rv 1.9a1 build 2006030210 under XP Pro SP2 here. I filled the URL field with that, as a testcase. Adding testcase keyword

> The testcase seems to be obselete. All it does is make the following show up in > the JavaScript Console: > Error: document.childNodes[0].childNodes[2] has no properties I agree and I removed it. The URL is now the testcase.

*** Bug 331454 has been marked as a duplicate of this bug. ***

My duped bug above might have more info in it to help you ? I have tested this some more and found a clean profile does not exhibit this bug (I referrer to my case from bug #331454 not this one here). But if I install checky-2.5-fx+mz.xpi or colorzilla-0.6.5-fx+mz.xpi this problem occurs. Maybe it occurs if I install any XPI extension, maybe this infomation can help someone find the source of the problem. I can confirm that your case here "javascript:alert("foo");" occurs in every situation I've tested that my case occurs.

I don't know if the bug as originally reported is the same bug as we are seeing now. Now the bug is a SeaMonkey only bug. The exception is reported in the JavaScript console every time that SeaMonkey opens any window using JavaScript, even if it is only an alert window. For me it happens with any profile, even brand new profiles and brand new installations on any version of Windows (Win 98, Win 2K, Win XP - I can't test any other OS's). It applies to the current SeaMonkey release 1.0 and all the present nightlies. Note the bug is not apparent in Firefox. It also has nothing to do with the Disability Access API, which is the component given at the top. I think it should relate to the script console or the script engine. I also think the product should be changed from Core to Mozilla Application Suite (SeaMonkey).

If you are correct and this is an unrelated bug, then maybe my bug #331454 should be reopened if the root cause is really a duplicate of this one. As I don't know what the problem actually is and I can not say with more authority than bugzilla@gtalbot.org who duped my recent SeaMonkey bug #331454 I'll leave the act of REOPENING to someone else.

(In reply to comment #33) > If you are correct and this is an unrelated bug, then maybe my bug #331454 > should be reopened if the root cause is really a duplicate of this one. > > As I don't know what the problem actually is and I can not say with more > authority than bugzilla@gtalbot.org who duped my recent SeaMonkey bug #331454 > I'll leave the act of REOPENING to someone else. > I agree. Darryl's bug #331454 is probably not a dupe of this and should be reopened as a SeaMonkey only bug. According to comment 15, the man who reported the original bug (Frank Wein) doesn't even see it any more. What we have here is a different bug. I theorise that the JavaScript engine's code for opening a window has been modified to look for something in the Firefox infrastructure or chrome that is not present in SeaMonkey. Comments 12 and 13 may be a clue to the timespan when any such regression occurred.

I suspect this is the same bug in a differen context. >>>>> Javascrip Console Error >>>>> Error: [Exception... "'Permission denied to set property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: file:///D:/Dave/Product%20Raters/Bauke/IN_AG_HO2.js :: anonymous :: line 727" data: no] Source File: file:///D:/Dave/Product%20Raters/Bauke/IN_AG_HO2.js Line: 727 >>>>> Alert Displayed >>>>> A schedule of covered structures must be submitted with the application. >>>>> The offending Lines of Code >>>>> mstruct: {value: Number.NaN, limits: [1,0,0], pmap: [[65001,72],[55001,66],[45001,60],[35001,54],[25001,48],[1,42],[0,0]], premium: function(){return(first_leq(this.value || 0,this.pmap))}, sdisplay: function(){return(text_input(0,'mstruct','','Other Structures',7,'nin'))}, update: function(value){if (!this.value & !!(this.value= value)) alert( 'A schedule of covered structures must be submitted with the application.' )}, next: 'total' }, >>>>> Comments >>>>> "mstruct": a data structure associated with a form input element of type "text". "update": called from an event handler which is called from the form element "onChange". Browser: Firefox 1.5.0.3. OS: Window 2000 Pro SP4, Windows NT Server SP6a I've encountered this same error in other applications. In one case, the error occurs at a particular point in a routine when the routine is called from one context but not when it is called from another. In this case the offending code is a call to "confirm".

Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1 ------------ Bug remains the same - when a JS function pops up an alert, an exception is caught. I see this bug only in Seamonkey, Mozilla 1.8.12 doesn't have such a bug.

WFM, SeaMonkey trunk on Linux.

I get this constantly when calling any window.open() from Javascript. Using FF 2.0.0.3 on Windows XP. It does not occur any more with alert() or confirm(). I was told that if I create the window with toolbar=no the error would not happen, but that's really not true. I wonder what accessKey is being referred to, one in the new window's accelerator table (whew, that takes me back) or perhaps a tag on the link which activates the window? Steve

Steve, does the bug occur in a recent Firefox 3.x build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Please attach a small testcase using the "Add an attachment" link on the bug. Thanks.

Test case requested by Mats Palmgren. It DOES NOT generate an error with latest build 3.0a5pre. It DOES generate the error with Firefox 2.0.0.3 Hope this helps, Steve

For 2.0.0.3 - does it work in Firefox Safe Mode or with a new profile? http://kb.mozillazine.org/Safe_Mode http://kb.mozillazine.org/Profile_Manager

In 2.0.0.3, the bug cannot be reproduced when running in Firefox Safe Mode or under a new profile. Steve

(In reply to comment #42) > In 2.0.0.3, the bug cannot be reproduced when running in Firefox Safe Mode or > under a new profile. Bug 352545 comment 1 makes me think the remaining problem is a bug in the Firebug add-on. Please file a bug here instead: http://code.google.com/p/fbug/issues/list (make sure it still occurs with the latest version of Firebug first). Thanks for you help analyzing the problem Steve. -> WORKSFORME

This bug is absolutely not resolved. Google for "Permission denied to get property HTMLDivElement.nodeType" and you get hundreds of results with several JS toolkits exercising the bug. ExtJS toolkit has the following code: 298 findParent: function(simpleSelector, maxDepth, returnEl) { 299 var p = this.dom, 300 b = document.body, 301 depth = 0, 302 dq = Ext.DomQuery, 303 stopEl; 304 maxDepth = maxDepth || 50; 305 if (typeof maxDepth != "number") { 306 stopEl = Ext.getDom(maxDepth); 307 maxDepth = 10; 308 } 309 try { 310 while (p && p.nodeType == 1 && depth < maxDepth && p != b && p != stopEl) { 311 if (dq.is(p, simpleSelector)) { 312 return returnEl ? Ext.get(p) : p; 313 } 314 depth++; 315 p = p.parentNode; 316 } 317 } catch(e) {}; 318 return null; 319 } Randomly the try/catch catches the bug in action on line 310 (p.nodeType==...) I see it constantly during development - all I have to do is move the mouse around really fast on top of one of their grids with a scroll bar present (e.g. a div with overflow: auto). I'll take a stab at a guess here. In some cases, you are exposing some of the chrome's elements as if they're part of the document's DOM, or firing events for those chrome elements and passing them along to the JS program downloaded into the browser by the WWW page. This bug's been around since 2004, how about it gets fixed?

Note: Firebug always halts on this error, even if you have the "Track Throw/Catch" option unchecked. That'd be a firebug problem, perhaps.