Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

appendChild

18 views
Skip to first unread message

Todd Keup

unread,
Mar 1, 2009, 5:16:08 PM3/1/09
to
I read the recent quote on the Mozilla site, from the appendChild page
https://developer.mozilla.org/en/DOM/element.appendChild

############

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:

var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'test.js';
document.getElementsByTagName('head')[0].appendChild(script);

Other browsers will allow DOM manipulation using these methods, so I
question why is this change being incorporated in Firefox?


Boris Zbarsky

unread,
Mar 1, 2009, 5:33:21 PM3/1/09
to Eric Shepherd
Todd Keup wrote:
> I read the recent quote on the Mozilla site, from the appendChild page
> https://developer.mozilla.org/en/DOM/element.appendChild
>
> ############
> 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.

-Boris

Sheppy

unread,
Mar 2, 2009, 5:56:05 AM3/2/09
to

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.

Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
http://www.bitstampede.com/

Boris Zbarsky

unread,
Mar 2, 2009, 10:26:11 AM3/2/09
to
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

Boris Zbarsky

unread,
Mar 2, 2009, 10:28:14 AM3/2/09
to
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?

-Boris

Sheppy

unread,
Mar 2, 2009, 12:26:07 PM3/2/09
to

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. :)

Boris Zbarsky

unread,
Mar 2, 2009, 12:36:57 PM3/2/09
to
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.

-Boris

Todd Keup

unread,
Mar 2, 2009, 2:22:31 PM3/2/09
to
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 ;)


0 new messages