Closed Bug 261423 Opened 20 years ago Closed 17 years ago

Permission denied to get property XULElement.accessKey' when calling method: [nsIDOMXULLabelElement::accessKey]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"

Categories

(Core :: Disability Access APIs, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mcsmurf, Assigned: aaronlev)

References

()

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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?
Attached file Testcase (obsolete) —
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
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.
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
Attachment #160348 - Attachment is obsolete: true
> 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
Status: REOPENED → RESOLVED
Closed: 20 years ago17 years ago
Resolution: --- → 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: