Closed Bug 396502 Opened 13 years ago Closed 7 years ago

"Error: Permission denied to get property XULElement.accessibleType {and XULElement.accessKey} / XPCSafeJSObjectWrapper.cpp / 445", starting ChatZilla

Categories

(Core :: XPConnect, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.9.1

People

(Reporter: cbook, Assigned: mrbkap)

References

Details

(Keywords: regression, Whiteboard: [See comment 5 and 13])

Attachments

(2 files)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8

When i launch Chatzilla in M8 it cause a bunch or js error Messages:

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 :: XPCSafeJSObjectWrapper.cpp :: anonymous :: line 434"  data: no]
Source File: XPCSafeJSObjectWrapper.cpp
Line: 434
Product: Firefox → Core
QA Contact: general → general
So I can see this fine, but I can't seem to debug it at all (using Venkman means less error messages appear, and they don't seem to relate to the two places where we manipulate accesskeys ourselves in menu-manager.js) ... CC'ing mrbkap who should know more about this stuff...
Getting a JS stack for the exception is pretty trivial (using a native debugger), but the stack is rather crazy. The native stack is even more fun, but ultimately blames the reading of window.innerHeight at:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/extensions/irc/xul/content/static.js&rev=1.245&mark=2651#2641

This forces pending reflows to be processed, which result in nsTextBoxFrame::UpdateAccesskey being called, which in turn tries to call:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/content/widgets/text.xml&rev=1.34&mark=28-33#18

Which balks. Why? I have no idea, just getting that far was fun enough.

(Stacks will be attached.)
That stack is reminiscent of bug 352791 -- the XPCWrappedJS method call pushes null prinicipals disallowing a lot of things.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

(No errors, with SM v1.)


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

("Confirming", with SM v2.)

1. Start ChatZilla.
1r. In Error Console, get 7 times
{{
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 :: XPCSafeJSObjectWrapper.cpp :: anonymous :: line 446"  data: no]
Source File: XPCSafeJSObjectWrapper.cpp
Line: 446
}}


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

With a more recent build, "new" errors (text):
4 times
{{
Error: Permission denied to get property XULElement.accessibleType
Source File: XPCSafeJSObjectWrapper.cpp
Line: 445
}}
plus 7 times
{{
Error: Permission denied to get property XULElement.accessKey
Source File: XPCSafeJSObjectWrapper.cpp
Line: 445
}}

***

At the very least, we shouldn't get "XPCSafeJSObjectWrapper.cpp : 445" as a source link, should we ?
Depends on: 352791
Flags: blocking1.9?
Keywords: regression
Summary: Starting Chatzilla in M8 cause Error: [Exception...nsIDOMXULLabelElement::accessKey] → "Error: Permission denied to get property XULElement.accessibleType {and XULElement.accessKey} / XPCSafeJSObjectWrapper.cpp / 445", starting ChatZilla
Whiteboard: [See comment 5]
Target Milestone: --- → mozilla1.9
Component: General → XPConnect
QA Contact: general → xpconnect
(In reply to comment #5)
> That stack is reminiscent of bug 352791 -- the XPCWrappedJS method call pushes
> null prinicipals disallowing a lot of things.
> 

Blake, what does that mean for fixing this bug? It seems to me like just asking for .innerHeight shouldn't throw up random errors like this, but maybe I'm being naive...
(In reply to comment #7)
> It seems to me like just asking
> for .innerHeight shouldn't throw up random errors like this, but maybe I'm
> being naive...

That part is probably bug 428590 ;-/
(In reply to comment #8)
> That part is probably bug 428590 ;-/

(Well, it is similar to it, at least.)
Don't think this blocks release, but an obvious candidate to help seamonkey out after that time ...
Flags: wanted1.9.0.x?
Flags: blocking1.9?
Flags: blocking1.9-
Assignee: nobody → mrbkap
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: wanted-next+
Priority: -- → P4
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.2pre) Gecko/2008070302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a1pre) Gecko/2008070303 Minefield/3.1a1pre] (nightly) (W2Ksp4)

Bug still there.
Flags: blocking1.9.1?
This is somehow related to the "Permissions denied for <http://example.com> to call method XULControllerForCommand in XPCSafeJSObjectWrapper.cpp bug #449081", reported by me, Polonus, it is a minor bug because it only shows up in the error console, and security wise could be a blessing to prevent evil redirects beyond the proper domaindomain, so the bug could be a feature and could have to do with installing the Redirect Remover 2.5.5 add on on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008080504 Minefield/3.1a2pre ID:2008080504. Here I experienced it.
Also bug #352791 could be related. Anyone has a clue as what causes this >
> Permission denied to call method Selection.addSelectionListener -
> XPCSafeJSObjectWrapper.cpp
> Line: 445

polonus
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/2008080519 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4)

7 times
{{
Error: Permission denied for <moz-safe-about:blank> to get property XULElement.accessKey from <>.
Source File: XPCSafeJSObjectWrapper.cpp
Line: 445
}}

Bug 434522 added details :-)
The empty "from" is odd, but maybe caused by comment 5 issue too ?

*****

(In reply to comment #12)

Please, even if these bugs are related, keep them apart.
Depends on: 434522
Whiteboard: [See comment 5] → [See comment 5 and 13]
Well we'll stick to the rules then and keep this bug in the proper place. What is the the proper way then of reporting various bug relations, the thing that strikes me is the Line in the error console - Line: 445, that similarity for both errors/bugs brought me here. Some things are undefined here, and this has some relation, and to do with NsServiceManager.JS - an invalid XML name, browserUtilities.JS - so it is stemming from higher up in the code hierarchy,

polonus
(In reply to comment #14)
> What is the the proper way then of reporting various bug relations,

Mark Duplicate if they are so.
Add a dependency on one to the other. (I guess this is what you want in this case.)
...
Yes, I think bug# 449081 could well be a duplicate of this bug.
Furthermore regarding bug # 396502 the following observations:
The Exception is a Reference Error
in script XPCSafeJSObjectWrapper:cpp:445
Is it so that XPCSafeJSObject is not wrapping the window and thus the evall call?
Is this a bug or a "security feature" so that one is unable to call constructors from the wrapped window object - getting a NOT_ENOUGH_ARGS. error,

polonus
Flags: blocking1.9.1? → blocking1.9.1+
Priority: P4 → P3
Target Milestone: mozilla1.9 → mozilla1.9.1
On second thought this won't block the release, but we'd love to have a fix for it in time for 1.9.1.
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Priority: P3 → P1
I'm assuming this works now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.