Closed Bug 752281 Opened 8 years ago Closed 8 years ago

'TypeError: can't wrap XML objects' when calling method: [calICalDavCalendar::refresh]

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: sparky, Unassigned)

References

Details

Updating Thunderbird to the 2012/05/05 nightly build breaks Lightning. This error appears in the console:

--------------------------------------
Timestamp: 05/06/2012 12:23:59 AM
Error: Assert failed: [Exception... "'TypeError: can't wrap XML objects' when calling method: [calICalDavCalendar::refresh]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "JS frame :: file:///Data/Profiles/Thunderbird/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calCompositeCalendar.js :: cCC_refresh :: line 378"  data: no]
2: [null:0] null
3: [file:///Data/Profiles/Thunderbird/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calCompositeCalendar.js:381] cCC_refresh
4: [null:0] null
5: [chrome://calendar/content/calendar-common-sets.js:402] cC_doCommand
6: [chrome://global/content/globalOverlay.js:98] goDoCommand
7: [chrome://messenger/content/messenger.xul:1] oncommand
8: [null:0] null

Source File: resource://calendar/modules/calUtils.jsm -> file:///Data/Profiles/Thunderbird/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js
Line: 1105
--------------------------------------

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c045085c0436&tochange=032d43b1770f

I'm guessing this is a compartment/wrapper issue, as there were a number of those changes in the pushlog.
Sorry, I meant the 2012/05/04 build.
(In reply to Boris Zbarsky (:bz) from comment #2)
> cpg fallout?

Yeah. Apparently lightning is using e4x somewhere, which we disallow for cross-compartment-wrappers, because, well, it's dying soon anyway.

So the fix is probably to make lightning stop using e4x, which has the added advantage of future-proofing it for when we drop e4x support entirely.
e4x's days are numbered so it does not make sense to add proxy support.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Shouldn't someone file a bug on Lightning here?
Since it doesn't look like a Lightning bug has been filed yet, I created Bug 754164.
Boris, Bobby, Luke: Some time ago I complained that Lightning has been struck (please excuse the wordplay ;-) multiple times by things removed from the Mozilla Platform without a good alternative. This included things like not allowing to dispatch runnables to other threads and removing xpcom from chrome workers. I believe there were also a few other cases.

e4x is now effectively broken for us, since we can't use it across compartments.

Back then, e4x was already on the list of things to slowly go away and I said that this is something lightning heavily relies on. I was promised that e4x would get a comparable replacement in terms of simplicity. 

Now you might argue, JXON could replace e4x. The problem here is that the current JXON parser found on MDN doesn't provide all the features we require:

* Being fully namespace aware
* Allowing selectors covering multiple namespaces (e4x *::node)
* Quick parsing from string to js object.

Also, it seems a bit overkill, that if I get a string response that I should convert String -> DOM -> JXON / js object, just to retrieve some values on it.

Of course I could spend some time changing our request handlers to use XHR instead of xpcom interfaces so we get responseXML for free, of course I could spend time using the SAX parser to convert directly from string to js object, or spend some time extending the MDN example to support namespaces the way we need them, but this all has one thing in common: I need to spend time working on a replacement, instead of just plugging in the replacement I was promised.


So tell me, are there any plans for making JXON native, or maybe a different replacement for e4x?

Thank you for your time.
You need to log in before you can comment on or make changes to this bug.