Accessing an onevent property (f.e. onload) of an xray-wrapped DOM object in a sandbox fails with NS_ERROR_NOT_AVAILABLE, which, among other problems, makes it impossible to load jQuery as a content script using page-mod, panel, widget, or any other Add-on SDK module that gives addons access to content via content scripts. Steps to Reproduce: 1. clone the Add-on SDK <https://hg.mozilla.org/labs/jetpack-sdk/>; 2. apply the attached patch, which contains a reduced testcase; 3. enter the SDK directory and activate the SDK; 4. enter the packages/jetpack-core/ directory and run "cfx test -f sandbox". Expected Results: the test passes. Actual Results: the test throws [Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: null :: <TOP_LEVEL> :: line 0" data: no].
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 607352
Erm, I overreduced the testcase, making it look like a duplicate of bug 607352. The Add-on SDK has the problem identified in bug 607352 as well, but the problem that led me to file this bug is actually that calling .getElementById() on an unwrapped document object returns an xray-wrapped object instead of an unwrapped object. In Firefox 4.0b6, where document objects are wrapped with XPCNativeWrappers, calling .getElementById() on an unwrapped document object in a chrome context returns an unwrapped object. In Firefox 4.0b7 (and tip), on the other hand, where document objects are wrapped with XrayWrappers, calling .getElementById() on an unwrapped document object in a chrome context returns an xray-wrapped object. So even if one loads jQuery in a chrome context that has access to an *unwrapped* document object (and window, etc.), jQuery is going to end up accessing wrapped objects and then trip over them because of bug 607352. And that breaks one of the example addons in the SDK (not to mention all the actual addons being built by developers using jQuery). I'll attach an updated testcase shortly.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Created attachment 493488 [details] [diff] [review] updated testcase Here's an updated testcase It actually tests both this bug and bug 607352. It fails the test for bug 607352 on 4.0b6, 4.0b7, and the tip. It only fails the test for this bug on 4.0b7 and the tip, however, because this problem only appeared in 4.0b7. Steps to Reproduce: 1. clone the Add-on SDK (hg clone https://hg.mozilla.org/labs/jetpack-sdk/); 2. enter the SDK directory and apply the testcase patch (cd jetpack-sdk; hg import --no-commit /path/to/test-wrappers.diff); 3. activate the SDK (source bin/activate); 4. enter the jetpack-core package directory and run the tests (cd packages/jetpack-core/; cfx test -f wrappers -b /path/to/firefox/binary). Expected Results: all tests pass in the "test getting DOM object from unwrapped document" test function. Actual Results: the "document element retrieved from unwrapped document via .getElementByID() is an [object HTMLHtmlElement]]" test fails.
blocking2.0: --- → ?
Summary: accessing onevent property of xray-wrapped DOM object throws exception → getElementById returns XrayWrapper when called from chrome on unwrapped content document
The same I have noticed 2 days ago while working on some Mozmill code. In a shared module of our tests we call wm.getMostRecentWindow(''). As result we get a window wrapped into a XRayWrapper. When I want to access window.opener I have to unwrap twice. Once for window and another time for opener. Is that the same issue as reported on this bug?
Status: REOPENED → NEW
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
I chatted with Andreas Gal, who asked me for a testcase that doesn't use the Add-on SDK's test harness. Here's one... while looking at this bug report page, open the Error Console and evaluate this statement: Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("navigator:browser").gBrowser.selectedBrowser.contentDocument.wrappedJSObject.getElementById("header") In Firefox 4.0b6, the following message appears in the console: [object HTMLDivElement]. On trunk, the message is: [object XrayWrapper [object HTMLDivElement]].
Reproduced. Thanks myk!
I am not the right guy for this bug, but until mrbkap is back I will poke at it.
Assignee: nobody → gal
Marking blocking betaN+.
blocking2.0: ? → betaN+
This actually blocks a b8 blocker, so updating to reflect. Any ETA? Should we be punting that and bug 604641 to b9?
blocking2.0: betaN+ → beta8+
Created attachment 495203 [details] [diff] [review] Proposed fix
I pushed the above patch to try (for builds and unit tests on linux-32, mac-64, and windows, opt and debug). There were a bunch of known intermittent oranges (plus a timeout on Win2K3 debug mochitest-other that's not known), but I think things looked ok.
I applied the patch to the tip of mozilla-central, built with it, and tested jQuery in an SDK-based addon (the reddit-panel example addon in the SDK's examples/ directory). It worked! So this patch fixes the problem that led me to file this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
Blake, as given in my comment 4 the problem is still persistent for Mozmill tests. Whenever a webpage raises a modal dialog (i.e. security warning) getMostRecentWindow returns a wrapped window with an additional wrapped window.opener. Is it different from this bug and has to be filed as a new one?
Target Milestone: --- → mozilla2.0b8
Depends on: 618176
(In reply to comment #16) > Blake, as given in my comment 4 the problem is still persistent for Mozmill > tests. Whenever a webpage raises a modal dialog (i.e. security warning) > getMostRecentWindow returns a wrapped window with an additional wrapped > window.opener. Is it different from this bug and has to be filed as a new one? I have created bug 618778 for the case discovered by Mozmill.
You need to log in before you can comment on or make changes to this bug.