It seems that using setParameter() with a String object as opposed to a literal string will cause the XSLT processor to give up with an error. In other words, this is bad: myProcessor = new XSLTProcessor(); myProcessor.setParameter(null,'foo',new String('bar')); Note that the following works: myProcessor.setParameter(null,'foo','bar'); Testcase is coming up. Cheers, - Bill
So I could fix this in Transformiix, but I wonder if it wouldn't be better to have XPConnect handle this itself. XPCVariant::InitializeData (http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpcvariant.cpp#240) special-cases JS primitive types and JS arrays (and nsIJSID, nsIJSIID and nsIJSCID). Anything else just gets wrapped and stored as an nsISupports in the variant. Would it make sense to have some of the builtin JS classes converted into a specific nsVariant type (VTYPE_DOUBLE for Number, VTYPE_BOOL for Boolean, ...)?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 174206 [details] Better testcase
Attachment #171306 - Attachment is obsolete: true
I'll do this as part of bug 248025. I'll convert all JS objects to string parameters.
Depends on: 248025
Comment on attachment 171306 [details] Test case showing that using String 'objects' as opposed to literals doesn't work. This doesn't crash in any way.
Attachment #171306 - Attachment description: Test case showing that using String 'objects' as opposed to literals crashes the XSLT processor → Test case showing that using String 'objects' as opposed to literals doesn't work.
Fixed by patch in bug 248025, all JS objects are converted to string now.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.