614757 - getElementById returns XrayWrapper when called from chrome on unwrapped content document

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

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].

Comment 2

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Attachment: 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.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 5

[Myk Melez [:myk] [@mykmelez]]

If there is any way possible, I would dearly love to have this fixed for Firefox 4.0b8, as shipping the first Add-on SDK beta without support for jQuery and other JavaScript libraries in content scripts will really, really suck.  cc:ing more of the folks responsible for making such decisions.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

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]].

Comment 7

[Andreas Gal :gal]

Reproduced. Thanks myk!

Comment 8

[Andreas Gal :gal]

I am not the right guy for this bug, but until mrbkap is back I will poke at it.

Comment 9

[Damon Sicore (:damons)]

Marking blocking betaN+.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

This actually blocks a b8 blocker, so updating to reflect. Any ETA? Should we be punting that and bug 604641 to b9?

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/tracemonkey/rev/0641328503d8

Comment 15

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/0641328503d8

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.