609143 - E4X XML objects cannot be passed to sandbox

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Simon Kornblith]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre

When E4X XML is added or passed to a function in a sandbox in Firefox 4.0/Gecko 2.0, the typeof operator returns "object" rather than "xml" and E4X methods cease to function.

This isn't high priority, since the string can be passed to the sandbox and then re-parsed, but it is a bit of an oddity and a regression from Firefox 3.6/Gecko 1.9.2.

Reproducible: Always

Steps to Reproduce:
var sandbox = Components.utils.Sandbox("http://www.example.com");
sandbox.test = new XML("<tag/>");
alert(Components.utils.evalInSandbox("test.name()", sandbox)); // Throws TypeError: test.name is not a function
Components.utils.evalInSandbox("typeof test", sandbox); // "object" (should be "xml") 
Actual Results:  
Throws "TypeError: test.name is not a function"
typeof on object produces "object"

Expected Results:  
Shows an alert with "tag"
typeof on object produces "object"

Comment 1

[Andreas Gal :gal]

Yes, we intentionally disallowed this. We should discuss whether this should be fixed or not. The fix would be very invasive. The problem is that XML objects are not behaving like JavaScript objects. Properties and functions have to be looked up differently. The abstraction wrappers use doesn't support this distinction (because its design for pure JavaScript, not for JS+E4X), so there is no reasonable way for us to create a transparent wrapper around an XML object.

Comment 2

[Brendan Eich [:brendan]]

We want to implement E4X's runtime semantics (funny "xml" typeof type, the XML and XMLList constructors, at least) using proxies. Say we do. Does that fix this bug or not?

/be

Comment 3

[Andreas Gal :gal]

I don't think the full precise behavior of E4X can be expressed with the currently proposed proxy API. We can't distinguish GetMethod from just Get (which we need to distinguish between calling a method on the xml object or getting a list property off it). If we are willing to break that feature, we can fix this bug trivially and also implement xml on top of proxies. In the alternative we have to hack up proxies to support xml. Its doable but somewhat involved surgery for the C++ API (I don't think we want to express this in the scripted API either way).

Comment 4

[Brendan Eich [:brendan]]

(In reply to comment #3)
> I don't think the full precise behavior of E4X can be expressed with the
> currently proposed proxy API. We can't distinguish GetMethod from just Get

Yes, let's ignore that for now -- otherewise, would this bug go away?

> If we are willing to break that feature, we
> can fix this bug trivially and also implement xml on top of proxies.

Cool!

> In the
> alternative we have to hack up proxies to support xml. Its doable but somewhat
> involved surgery for the C++ API (I don't think we want to express this in the
> scripted API either way).

Let's defer this bug a good while. Sorry, E4X fans. You'll have to serialize and deserialize.

/be

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #3)
> I don't think the full precise behavior of E4X can be expressed with the
> currently proposed proxy API. We can't distinguish GetMethod from just Get

It's always possible for get to return a proxy that either is callable as an XML.prototype-homed method, or not called and dynamically computes an XMLList containing all the children of the given name. That would not be super-efficient but it would implement the ECMA-357 semantics, AFAICT.

/be

Comment 6

[Nicholas Nethercote [inactive]]

e4x is being removed (bug 788293).