Closed
Bug 715755
Opened 12 years ago
Closed 12 years ago
Permission denied to access property '__isXrayWrapperProxy' is thrown when using Annotator example
Categories
(Add-on SDK Graveyard :: General, defect, P2)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
FIXED
1.6
People
(Reporter: ochameau, Assigned: ochameau)
Details
Attachments
(1 file)
jQuery is able to get access to a XUL DOM node when your mouse goes over scrollbars, `event.originalTarget` refers to `xul:slider`. This slider node ends up being a chrome object, so an xraywrapper, that is throwing on any property access. That's why we get this exception. It is a regression compared to 1.3 as proxies code were hosted in a system principal sandbox, in 1.3, and weren't hitting this exception. This exception isn't breaking any Annotator functionnality as it throw an exception on mouse enter/leave for nodes that won't be usable in anycase. But I'd imagine that this kind of exception may break other kind of code that get access to XUL nodes. (I'm wondering if this is a platform bug?) Right now, I don't see any way to distinguish such xraywrapper object. The following test is true: XPCNativeWrapper.unwrap(event.originalTarget) === event.originalTarget And any property access throw an exception. Even `event.originalTarget.toString()` throws :/ The only thing we can do is `(""+event.originalTarget)`. So I'll try to ping some wrapper experts in order to find a way to identify them and avoid creating proxies for such objects.
Priority: -- → P2
Comment 1•12 years ago
|
||
I'd like to share my findings related to this bug, which does impact the behavior of our add-on. We rewrote our PriceBlink add-on starting with SDK 1.1. Recently I discovered the permission denied error starting with SDK 1.4 as mentioned here: http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/cf203e892cd58ec3 Tonight I decided to download SDK 1.6 branch to see if anything had improved. Here is the error I'm seeing several times in the console: error: An exception occurred. Traceback (most recent call last): File "resource://info-at-priceblink-dot-com/api-utils/data/content-proxy.js", line 761, in return wrap(o, obj, name); File "resource://info-at-priceblink-dot-com/api-utils/data/content-proxy.js", line 270, in wrap if ("__isXrayWrapperProxy" in value) Error: Permission denied to access property '__isXrayWrapperProxy' Our content script gets attached to the page on "start" and then it tries to filter out any frames. The reason being is we don't care about frames and only the main document. We use the following code to grab the content document URL: var url = content.document.location.href; Since this fires for each frame I see the "permission denied" for each one. It doesn't throw an error for the main document. Perhaps I should be accessing the URL differently but this has worked ever since we began development of our add-on. I hope this helps and I'll look through the SDK to see if there's a better way to do this.
Comment 2•12 years ago
|
||
I get this error when trying to access window.frames[3].document, while I didn't when using SDK version 1.3. In this particular case, I have an addon that fires when a frameset document is loaded. It replaces the natural content of one of the frames (the third) with a file loaded from a resource:// URL, and also sets up a content script in the main frameset. When the main content script attempts to access the replaced frame document, I get the _isXrayWrapperProxy error. Accessing the other, unmodified frames is ok. I don't really know whether I should have *ever* been able to access the frame replaced with a resource url. But if desired I could make a minimal extension that reproduces this error.
Comment 3•12 years ago
|
||
I don't think it's an xraywrapper, it is more likely a system only wrapper. In which case if you don't have chrome access you won't be able to access any of it's properties. I think you should just catch the exception if thrown for some property access and skip creating a proxy for these elements. Of course one always can define a property getter that throws the same exception to trick you, in which case can avoid a proxy to be created, but I don't think it's a big issue, or is it?
Assignee | ||
Comment 4•12 years ago
|
||
There is two issues there. - SDK throws this exception when a content script try to access to a cross domain or chrome object. We shouldn't throw such exception. - We improved content script security in SDK 1.4 release. Now content script are evaluated with same rights than the webpage. It means that you can no longer access to iframe content if it is on another domain. You may found that too restrictive. But at the very least, we shouldn't have cross domain priviledges in content script. We are currently discussing about giving some, on demand only. Some discussion started in bug 722232.
Assignee | ||
Comment 5•12 years ago
|
||
Here is patch in order to avoid this exception. So instead of having this exception, we return the COW wrapper. It won't really help most people that faced this issue, as they most likely would like some cross domain feature. But it may fix issues when using valid cross domain access.
Assignee: nobody → poirot.alex
Attachment #602061 -
Flags: review?(rFobic)
Comment 6•12 years ago
|
||
Comment on attachment 602061 [details]
Pull request 354
Looks good to me r+ with suggested port change.
Attachment #602061 -
Flags: review?(rFobic) → review+
Comment 7•12 years ago
|
||
Commit pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/5f6f368610c7a24ec2377ecf945cd777341e8fa6 Merge pull request #354 from ochameau/bug-715755 Bug 715755: avoid creating proxies for COWs r=@gozala
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•12 years ago
|
||
We discussed about blocking 1.5 release for this bug so that I think we should land this in stabilization for 1.6. We received multiple reports where this error is being thrown and break addons, mostly around iframe usages. (see bug 723434 for such case)
Assignee | ||
Updated•12 years ago
|
Target Milestone: --- → 1.6
Comment 9•12 years ago
|
||
Commit pushed to stabilization at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/4f16cf3013f3f7ad560d771719d799da80d41aa6 Merge pull request #354 from ochameau/bug-715755 Bug 715755: avoid creating proxies for COWs r=@gozala(cherry picked from commit 5f6f368610c7a24ec2377ecf945cd777341e8fa6)
Assignee | ||
Comment 10•12 years ago
|
||
This changeset described in comment 7 ended up turning orange tinderbox. Two followup revisions were needed in order to get test being green again: https://github.com/mozilla/addon-sdk/commit/03ac7ba31d220b6e9f36b4675d0a6bee8a672571 and then: https://github.com/mozilla/addon-sdk/commit/4e16b2018ab6e84e9f7906453a5e097fe20ca0b8
Comment 11•12 years ago
|
||
I've been seeing this error in my SearchRater add-on in the last month. It's happening in Firefox 10 and 11. Traceback (most recent call last): File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/adlimiter/data/sitetruthclient.js", line 200, in querySiteTruthServerReply var proxy = proxyids.getitem(replymsg.id); // get our local proxy object Error: Permission denied to access property 'id' What's weird is that "id" is a field in a reply from a "port.on" callback. function querySiteTruthServerReply(replymsg) { var proxy = proxyids.getitem(replymsg.id); ... } self.port.on("ratereply", querySiteTruthServerReply); There should be no situation in which that is a security error. That's just a attribute of a local variable that's supposedly been created by de-serializing JSON created at the add-on end of the port. It's not connected to a DOM at all. (Or is data sent on ports not really being serialized?)
(In reply to John Nagle from comment #11) Are you seeing this with the 1.6rc1 build or with the 1.5 release? The fix for this should ship next Tuesday in 1.6.
Comment 13•12 years ago
|
||
I'm seeing it in the Firefox 11.0 release version. So I don't have the fix yet. (Not clear if it's the same problem. Does the "port" system cheat and not actually serialize and deserialize the data being sent?)
(In reply to John Nagle from comment #13) > I'm seeing it in the Firefox 11.0 release version. So I don't have the fix > yet. > > (Not clear if it's the same problem. Does the "port" system cheat and not > actually serialize and deserialize the data being sent?) The fix landed in the SDK, not Firefox. You'd need to repack the extension with SDK 1.6 or newer to pick up the fix.
Comment 15•12 years ago
|
||
I'm still seeing it with SDK 1.6.1 and Firefox 12. Timestamp: 5/8/2012 11:26:54 AM Error: An exception occurred. Traceback (most recent call last): File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/api-utils/data/content-proxy.js", line 698, in return name in obj || name in overload || name == "__isWrappedProxy" || Error: Permission denied to access property 'document' This may be a different bug. That's being raised in SDK code, not my code.
You need to log in
before you can comment on or make changes to this bug.
Description
•