Closed Bug 613142 Opened 14 years ago Closed 11 years ago

"can't wrap XML objects"

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
minor

Tracking

()

RESOLVED INVALID

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: testcase)

In xpcshell,

      var sandbox = Components.utils.Sandbox("http://example.com/");
      try {
        Components.utils.evalInSandbox("throw <x/>;", sandbox);
      } catch(e) {
      }

Causes "can't wrap XML objects" to be printed to the console, and causes xpcshell to exit with code 3 (which is what I noticed first).
The can't wrap xml objects part is intentional.
xpcshell exiting with code 3 just means an uncaught exception was thrown (it's for automated testing, AIUI).
It's clearly intentional, but is there a reason for it? It's causing me major problems.
(In reply to comment #1)
> The can't wrap xml objects part is intentional.

Yeah, but it may be a mistake, or a temporary exhaustion situation and not a long-term tenable position. What's hard about wrapping XML objects?

/be
Kris, can you comment a little more on why you're using E4X?

I have to admit that my memory is fuzzy here, but my recollection here is that we'd have to write a bunch of extra code in order to support E4X. For example, we'd need to split up GetProperty/GetMethod and deal with whatever bizarre quirks E4X introduced into the object model (I don't remember all of them right now).
If E4X objects become Proxies, does this bug get fixed for free?

/be
Depends on: 485791
I'm not sure, but probably, yeah.
Blake: I'm using it primarily for dynamic DOM node creation and templating. It becomes a problem when I try to load plugins, user command input, and other script fragments into sandboxes, at which point many parts of my API (including the function which translates E4X into a DOM tree) become inaccessible. It's also especially problematic where MozMill comes into play, given that functional tests are loaded into Sandboxes.
Yeah, the easiest way to work around this is to serialize/deserialize for now. Hopefully, that won't be too expensive.
Blake: That's fine with me. Unless I'm mistaken, that seems to be how <a>{<b/>}</a> seems to work anyway (or, at any rate, it has those semantics), and that doesn't seem to cause too much trouble.

If it helps, I can stringify and re-parse the arguments in my DOM generation code and report any obvious performance impact, although given how expensive DOM creation is it may not be the best test for the general case.
Wanted to point out the use case of one of my systems that broke. It turns out this app is a player for components written in JS where HTMl and CSS are inline defined in the JS, for instance var HTML = <> DUMP HTML CODE HERE </>. This was very practical to do. I was simply using this E4X subset ( as I understand ) in the middle of a normal JS code. Was this incorrect? in terms of moving forward.
With compartment per global landed, it would be significantly easier for me to fix this than to modify my code to work around it. Would a patch to clone xml objects passing between compartments as discussed be accepted?
E4X is on a path to deprecation (bug 695577 comment 1) so an investment in removing E4X would be more worth your time.  I don't think the JS module is interested in taking new E4X code.
Gone.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.