getElementById returns XrayWrapper when called from chrome on unwrapped content document

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
XPConnect
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: myk, Assigned: mrbkap)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla2.0b8
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta8+)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 2

8 years ago
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 → ---
(Reporter)

Comment 3

8 years ago
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: --- → ?
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
(Reporter)

Comment 5

8 years ago
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.
(Reporter)

Updated

8 years ago
No longer blocks: 611250
(Reporter)

Comment 6

8 years ago
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

8 years ago
Reproduced. Thanks myk!

Comment 8

8 years ago
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+
(Assignee)

Comment 11

8 years ago
Created attachment 495203 [details] [diff] [review]
Proposed fix
Assignee: gal → mrbkap
Attachment #493488 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #495203 - Flags: review?(gal)

Updated

8 years ago
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.
(Reporter)

Comment 13

8 years ago
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.
(Reporter)

Updated

8 years ago
Blocks: 616768
(Assignee)

Comment 14

8 years ago
http://hg.mozilla.org/tracemonkey/rev/0641328503d8
Whiteboard: fixed-in-tracemonkey

Comment 15

8 years ago
http://hg.mozilla.org/mozilla-central/rev/0641328503d8
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago8 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
Blocks: 618778
(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.