Safe innerHTML (nsIScriptableUnescapeHTML) assignment inside content scripts in Electrolysis

Add-ons Development
#1

Cheers,

First of all, my apologies for cross-posting - I was advised that “add-ons/development” is a better place to post. My question is about safe innerHTML assignment inside content scripts in Electrolysis. If if it is still not the best place to ask this type of question or if it was answered before (which I missed in my googling) - please let me know what would be a better place…

With Electrolysis release coming in January, we are trying to make our [overlay-based] add-on compatible with it ASAP. We are mostly done [functionally] as far as making our add-on work on “nightly” [Electrolysis] Firefox. One sticky place that we are unsure how to proceed is how to transform our markup builder code within our add-on (as that markup is based on the info we get from our server). Originally we built markup using JQuery’s html() function or direct innerHtml assignment. When reviewer asked us to modify that as unsafe we started using Components.interfaces.nsIScriptableUnescapeHTML.

Well, now in Electrolysis nsIScriptableUnescapeHTML seems to be unavailable to the content scripts. So what can we do to quickly rectify this situation? [We can certainly build the markup within the background code, but the process is somewhat incremental and making frequent calls to go back and forth between content script and background is probably not too efficient…] What’s the alternative to using nsIScriptableUnescapeHTML for safe markup creation inside content script under Electrolysis?

Thanks,

Bob.

Safe innerHTML assignment (nsIScriptableUnescapeHTML) inside content scripts in Electrolysis
#2

nsIScriptableUnescapeHTML is obsolete. Use nsIParserUtils. It has a parseFragment() method which is probably what you want. It will give you a documentFragment element that can be inserted into your page. I’m surprised the reviewer didn’t mention it, they usually flag up deprecated code automatically.

When you say content script, do you really mean frame script?

1 Like
#3

My question is about safe innerHTML assignment inside content scripts in Electrolysis. First of all, I apologize if it is not the best place to ask this type of question or if it was answered before (which I missed in my googling) - in this case please let me know what would be a better place…

With Electrolysis release coming in January, we are trying to make our [overlay-based] add-on compatible with it ASAP. We are mostly done [functionally] as far as making our add-on work on “nightly” [Electrolysis] Firefox. One sticky place that we are unsure how to proceed is how to transform our markup builder code within our add-on (as that markup is based on the info we get from our server). Originally we built markup using JQuery’s html() function or direct innerHtml assignment. When reviewer asked us to modify that as unsafe we started using Components.interfaces.nsIScriptableUnescapeHTML.

Well, now in Electrolysis nsIScriptableUnescapeHTML seems to be unavailable to the content scripts. So what can we do to quickly rectify this situation? [We can certainly build the markup within the background code, but the process is somewhat incremental and making frequent calls to go back and forth between content script and background is probably not too efficient…] What’s the alternative to using nsIScriptableUnescapeHTML for safe markup creation inside content script under Electrolysis?

#4

My apologies. I was advised that for my type of question addon development would be a better place to post…

#5

@Lithopsian

First of all, thank you for your reply and advice.
It looks like nsIParserUtils is a way to go, indeed.

And - yes - I meant “frame script”, just was calling it the way google chrome extensions do.

Second. Both nsIParserUtils and nsiScriptableUnescapeHTML didn’t work for me originally, as - for whatever reason - inside my frame script Components.classes was not defined, only Components.interfaces was (and even there virtually every expected field was still undefined).
After caching Components.classes (and the required service obtained from it) during frame script initialization, it started working.
I guess, we can say that the problem is solved (although I am still unclear why Components.classes are not always available - I never saw this problem prior to Electrolysis; both namespaces and global variables in Electrolysis seem messed up - is it the way it will be? is there any good guide for that?).

Thanks again,
Bob.

#6

That’s odd. Components is a standard global variable in the frame script environment. I tend to put a line at the top of each script for my convenience:
var {classes: Cc, interfaces: Ci} = Components;

Perhaps there is some difficulty referring to them from the scope of certain event or message handlers? I would have thought it would be mentioned, but I haven’t come across it either in my code or in the documentation. Some interfaces won’t be available, but that should be the case at all times. One possibility is that you are seeing differences between running in the content process and running in the chrome process. Some pages are actually run in the chrome process, not a separate process, such as about:* pages. They still get a frame script and it should still look the same, but there are subtle differences.

Frame scripts is the description in Firefox, because content script refers to something else. Frame scripts have been around for a while, but there wasn’t really much use for them before e10s.