Two common use cases for the upcoming page mods API of the Jetpack SDK are: 1. add properties to a page's global object (f.e. an experimental camera API); 2. manipulate the DOM of a page using a JavaScript library like jQuery. To make the page mods API as simple as possible to learn and use, it should be possible to do both things with a consistent API, ideally even in the same mod, via something like this simplified sample code: PageMod({ scriptURL: [url("my-script-that-adds-property.js"), url("jquery.js"), url("my-script-that-manipulates-dom.js")] ... }); We can support the first use case by loading the script on content-document-global-created, per bug 549539, but that doesn't support the second use case, because jQuery assumes that document.documentElement exists, as it is normally loaded by a web page via a <script> tag, by which time the document element has been created. To support our ideal API, it should be possible to run page mod code at the point in time after which the document element for a page has been created but before any of the scripts specified by the page have run.

Note that right now there may not be such a time. Making such a time exist may well involve parser changes for both xml and html.

Another problem is, are we fine with notifying into a jetpack from the content thread, and blocking until the jetpack is done handling that notification? I guess it's ok once we have process separation between chrome and content? But before then? What do we do elsewhere?

(In reply to comment #2) > Another problem is, are we fine with notifying into a jetpack from the content > thread, and blocking until the jetpack is done handling that notification? Don't we already do this for content-document-global-created?

content-document-global-created is just a observerService notification. But if someone calls into jetpacks when they fire and block until the jetpack returns, then yes, we are. Is that the case?

(In reply to comment #4) > content-document-global-created is just a observerService notification. But if > someone calls into jetpacks when they fire and block until the jetpack returns, > then yes, we are. > > Is that the case? Yes. When the notification fires, if a Jetpack-based addon has registered some code to be run alongside the page being loaded (via the Page Mods API or some other API with access to content pages), an observer creates a sandbox with access to the page's JS context and loads code provided by the addon into it. However, once Jetpack-based addons run in separate "jetpack" processes, this particular chunk of work will probably still happen in the content process, so there will be no need for the content process to block waiting for the jetpack process (which, as understand it from conversations with bsmedberg, is tricky to implement and requires some bridging infrastructure).

This is an untested patch.

Comment on attachment 469280 [details] [diff] [review] v0.1 Err.. nevermind

Ok, this one should work better.

Comment on attachment 469310 [details] [diff] [review] Patch v0.2 I tested this patch with my Jetpack SDK changes in bug 590968, attachment 469514 [details] [diff] [review], and it worked fine. I was able to load jQuery as a content script on document-element-inserted without exceptions being thrown, and it behaved as expected.

Jonas: is this safe to land or is there a high risk of regression from it? If so, I'd rather push it to beta6+; what say you?

This was actually already checked in friday night: http://hg.mozilla.org/mozilla-central/rev/34afbe32fb0e

Documented here: https://developer.mozilla.org/en/Observer_Notifications#Documents And mentioned on Firefox 4 for developers.