Note: Starting in Firefox 3.1, you can no longer use this method to append script elements that retrieve their code from anything other than chrome: URLs.
############
I have been searching trying to find changelogs or discussion on this proposed change in Firefox. Unless I am misunderstanding the note on the Mozilla documentation page for appendChild, we will no longer be able to append a <script> element in the following manner:
> ############ > Note: Starting in Firefox 3.1, you can no longer use this method to append > script elements that retrieve their code from anything other than chrome: > URLs.
This is only the case for chrome documents, not in general, as I recall. You might want to double-check with the documentation author, though... Maybe I missed something.
> > ############ > > Note: Starting in Firefox 3.1, you can no longer use this method to append > > script elements that retrieve their code from anything other than chrome: > > URLs.
> This is only the case for chrome documents, not in general, as I recall. > You might want to double-check with the documentation author, > though... Maybe I missed something.
This comes from bug 425153 and 418356. Nothing I see in those bugs says that the limitation is restricted to chrome documents, that I can find. If this is in error, I'd appreciate it if someone would let me know for certain so I can revise the documentation appropriately.
Sheppy wrote: > This comes from bug 425153 and 418356. Nothing I see in those bugs > says that the limitation is restricted to chrome documents, that I can > find. If this is in error, I'd appreciate it if someone would let me > know for certain so I can revise the documentation appropriately.
Ah, I see.
The change in bug 425153 makes sure that any <script> loaded from a document that gets XPCNativeWrapper automation also gets XPCNativeWrapper automation. It does affect whether script are loaded. It does affect XBL loading: XBL that does not get XPCNativeWrapper automation cannot be applied to a node in a document that does.
The change in bug 418356 doesn't affect <script> loading behavior at all; it merely affects whether scripts loaded programmatically ia the subscript loader get XPCNativeWrapper automation. They're forced to if the loading code does.
Neither one affects appendChild behavior in terms of whether the script executes; all that's affected is whether the executing script gets XPCNativeWrapper automation. This is relevant only to chrome documents, of course.
The one recent change I know of that affected _whether_ scripts are loaded (or rather whether they're executed) is bug 424426. This affects only documents in a signed jar, and only allows such documents to execute scripts whose principal subsumes the principal of the document (in practice, either chrome scripts or scripts from a signed jar on the same server and signed with the same signing certificate). That change was made for 1.9.0, though.
Boris Zbarsky wrote: > Neither one affects appendChild behavior in terms of whether the script > executes; all that's affected is whether the executing script gets > XPCNativeWrapper automation. This is relevant only to chrome documents, > of course.
And we _do_ probably want to document this in the documentation that discusses XPCNativeWrapper automation, or something.
It might be good if bugs always included a summary of what the patch does. That would probably help the documentation work a good bit. Eric, please feel free to point out cases when a bug asks for documentation and doesn't have such a summary?
On Mar 2, 10:28 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Boris Zbarsky wrote: > > Neither one affects appendChild behavior in terms of whether the script > > executes; all that's affected is whether the executing script gets > > XPCNativeWrapper automation. This is relevant only to chrome documents, > > of course.
> And we _do_ probably want to document this in the documentation that > discusses XPCNativeWrapper automation, or something.
> It might be good if bugs always included a summary of what the patch > does. That would probably help the documentation work a good bit. > Eric, please feel free to point out cases when a bug asks for > documentation and doesn't have such a summary?
I've been doing that lately when it wasn't reasonably clear what was needed. This particular change seemed obvious, although apparently it wasn't. Because the bug specifically mentioned cases that had incorrect behavior, I assumed those cases were all fixed as described, and that's what I documented. I'll try to do a better job of double- checking those things going forward.
I'd appreciate it if you could revise the documentation in question, as I'm actually more unclear now than ever as to what needs to be done. :)
Sheppy wrote: > I'd appreciate it if you could revise the documentation in question, > as I'm actually more unclear now than ever as to what needs to be > done. :)
OK. I've just removed the incorrect text from the appendChild article, since there was no change to appendChild behavior.
I don't really know what the right place is to document the XPCNativeWrapper automation behavior; if you can point me to the article that discusses it right now I can try to document it.
I had tested the assumed revision in a beta version of 3.1b to test the feature and I can indeed appendChild <script> elements without issue so I was wondering when the *break* was going to occur ... and it's not. I appreciate the confirmation. Thanks fellas.
Sheppy, thanks for the heads up and the direction. I'll watch for the documentation update ;)
