Closed Bug 614757 Opened 9 years ago Closed 9 years ago

getElementById returns XrayWrapper when called from chrome on unwrapped content document

Categories

(Core :: XPConnect, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: myk, Assigned: mrbkap)

References

Details

(Keywords: regression, Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 1 obsolete file)

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
Closed: 9 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 → ---
Attached patch updated testcase (obsolete) — Splinter Review
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: --- → ?
Keywords: regression
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
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.
No longer blocks: 611250
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+
Attached patch Proposed fixSplinter Review
Assignee: gal → mrbkap
Attachment #493488 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #495203 - Flags: review?(gal)
Attachment #495203 - Flags: review?(gal) → review+
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.
Blocks: 616768
http://hg.mozilla.org/mozilla-central/rev/0641328503d8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 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
(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.
Duplicate of this bug: 618878
Depends on: 708340
You need to log in before you can comment on or make changes to this bug.