Closed
Bug 613142
Opened 14 years ago
Closed 11 years ago
"can't wrap XML objects"
Categories
(Core :: JavaScript Engine, defect)
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).
Comment 1•14 years ago
|
||
The can't wrap xml objects part is intentional.
Comment 2•14 years ago
|
||
xpcshell exiting with code 3 just means an uncaught exception was thrown (it's for automated testing, AIUI).
Comment 3•13 years ago
|
||
It's clearly intentional, but is there a reason for it? It's causing me major problems.
Comment 4•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
If E4X objects become Proxies, does this bug get fixed for free? /be
Comment 7•13 years ago
|
||
I'm not sure, but probably, yeah.
Comment 8•13 years ago
|
||
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•13 years ago
|
||
Yeah, the easiest way to work around this is to serialize/deserialize for now. Hopefully, that won't be too expensive.
Comment 10•13 years ago
|
||
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•13 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•