951134 - ES builtin functions should be visible on Xrays to the global object

Status: REOPENED

(Core :: XPConnect, defect)

Description

[Matthew Gertner]

The following code returns "undefined":

var win = gBrowser.contentWindow;
var sandbox = Cu.Sandbox(win, { sandboxPrototype: win });
Cu.evalInSandbox("window.parseInt", sandbox);

However, window.parseInt does evaluate to a function. If I use wantXrays:false for the sandbox or "window.wrappedJSObject.parseInt" as the script, then it works. Is parseInt missing from some IDL file or am I misunderstanding what the correct behavior should be?

Comment 1

[Boris Zbarsky [:bzbarsky]]

parseInt isn't defined in IDL and isn't part of the DOM.  It's directly defined by the JS engine on the global object.  As in, it _is_ an expando property.

Not sure whether we have existing bugs about making such things (ES-standard functions on the global) work over Xrays...

Comment 2

[Bobby Holley (:bholley)]

So, I added support recently for ES constructors in bug 933681.

We can properly Xray to constructors, because they're stored in a slot on the global. But there are a few things that live on the global but don't live in any particular slot. These are enumerated in builtin_property_names in jsapi.cpp:

http://mxr.mozilla.org/mozilla-central/source/js/src/jsapi.cpp#1208

The only one of those things that seemed at all useful to use over Xrays was eval, so I special-cased it here:

http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/wrappers/XrayWrapper.cpp#831

Is there a use case for doing xrayedWindow.parseInt? It seems like you could always just do |parseInt|, which would work fine. Or is the issue that you're trying to run a content script (outside of your control) in the sandbox, and that sandbox happens to invoke |window.parseInt|?

If we want to support this, I think the easiest thing is just to redirect everything but |eval| to the local global.

This should be a straightforward patch to write, but not something I have time for right now. I'm happy to mentor whoever wants to do it, though.

Comment 3

[Matthew Gertner]

(In reply to Bobby Holley (:bholley) from comment #2)
> Is there a use case for doing xrayedWindow.parseInt? It seems like you could
> always just do |parseInt|, which would work fine. Or is the issue that
> you're trying to run a content script (outside of your control) in the
> sandbox, and that sandbox happens to invoke |window.parseInt|?

Exactly. In this case, we are using a third-party library called html2canvas as a content script, and it happens to use window.parseInt. We can work around it by telling the sandbox not to use Xrays but it seems to me like the correct behavior would be to have parseInt and similar properties accessible over Xrays.

Comment 4

[Bobby Holley (:bholley)]

(In reply to Matthew Gertner from comment #3)
> Exactly. In this case, we are using a third-party library called html2canvas
> as a content script, and it happens to use window.parseInt. We can work
> around it by telling the sandbox not to use Xrays but it seems to me like
> the correct behavior would be to have parseInt and similar properties
> accessible over Xrays.

Yes, that sounds like the right thing to do. If anyone is interested in doing this, let me know and I'll explain what needs to be done.

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.