Last Comment Bug 613142 - "can't wrap XML objects"
: "can't wrap XML objects"
Status: RESOLVED INVALID
: testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- minor (vote)
: ---
Assigned To: general
:
Mentors:
Depends on: 485791
Blocks: jsfunfuzz
  Show dependency treegraph
 
Reported: 2010-11-18 00:23 PST by Jesse Ruderman
Modified: 2013-02-21 12:07 PST (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jesse Ruderman 2010-11-18 00:23:41 PST
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).
Comment 1 Andreas Gal :gal 2010-11-18 00:26:25 PST
The can't wrap xml objects part is intentional.
Comment 2 Blake Kaplan (:mrbkap) 2010-11-18 00:31:37 PST
xpcshell exiting with code 3 just means an uncaught exception was thrown (it's for automated testing, AIUI).
Comment 3 Kris Maglione [:kmag] 2010-12-17 17:05:55 PST
It's clearly intentional, but is there a reason for it? It's causing me major problems.
Comment 4 Brendan Eich [:brendan] 2010-12-17 18:55:02 PST
(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
Comment 5 Blake Kaplan (:mrbkap) 2011-02-28 16:10:23 PST
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).
Comment 6 Brendan Eich [:brendan] 2011-02-28 16:18:56 PST
If E4X objects become Proxies, does this bug get fixed for free?

/be
Comment 7 Blake Kaplan (:mrbkap) 2011-02-28 16:22:00 PST
I'm not sure, but probably, yeah.
Comment 8 Kris Maglione [:kmag] 2011-02-28 19:19:18 PST
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.
Comment 9 Blake Kaplan (:mrbkap) 2011-03-15 11:20:15 PDT
Yeah, the easiest way to work around this is to serialize/deserialize for now. Hopefully, that won't be too expensive.
Comment 10 Kris Maglione [:kmag] 2011-03-15 11:46:29 PDT
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.
Comment 11 /\/\arcio Galli 2011-05-10 21:28:14 PDT
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.
Comment 12 Kris Maglione [:kmag] 2012-05-09 08:40:28 PDT
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?
Comment 13 Luke Wagner [:luke] 2012-05-09 09:27:39 PDT
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.
Comment 14 Tom Schuster [:evilpie] 2013-02-21 12:07:35 PST
Gone.

Note You need to log in before you can comment on or make changes to this bug.