Jetpack APIs which are currently not multi-process-able
Benjamin Smedberg
https://jetpack.mozillalabs.com/sdk/0.5/docs/ looking for behaviors which
are either not possible to implement in a multi-process world, or are going
to require significant changes to implement correctly:
context-menu:
The context property as a function will require some significant redesign.
Firefox cannot synchronously call this function and wait for the reply
before displaying the context menu. For those cases where it is necessary
for context to be a function, we could delay displaying the context menu for
a short period (10-50ms?) until the jetpack responds, and show a context
menu with a throbber in the degenerate case. Not sure what to do here, exactly.
The contextObj (node/document/window) will not be able to synchronously talk
to the DOM. Instead it will have to be handles to nodes/document/window, and
will need to send messages and retrieve data.
It is possible, even likely, that we should invent a message-passing
mechanism so that when the user clicks on content, the jetpack can run
pagemods-style code in content, collect any important/interesting
information, and then attach data to the event.
observer-service:
If this is meant to be exposed to addons (instead of being an implementation
detail), the behavior of the callbacks will become asynchronous.
page-worker:
This API will require changes such as have already been discussed for page
mods. The jetpack will need to run code which touches the page in a separate
context from the main addon:
page.window and page.document will be unavailable. onReady should probably
be removed. Instead use message-passing, e.g.
var page = PageWorker.Page({
script: self.data.url('wikiscript.js'),
content: "http://en.wikipedia.org/wiki/Internet",
onMessage: function(message) {
if (message.origin != "-moz-addon:" + self.id)
return;
// do something interesting with message.data
}
});
private-browsing:
onBeforeStart will not work: the browser is not going to wait for the
jetpack to reply before entering private-browsing mode. There should be a
single private-browsing.onStart() function which is called asynchronously.
similarly onStop/onAfterStop.
selection:
There aren't any bad APIs inherently, but asynchronous behavior may change
the behavior of current scripts a lot. For example, if the user selects text
and then immediately switches windows, it's possible to receive an onSelect
callback where selection.text contains the selection of the second window
twice, and none for the first window. It probably won't matter in practice,
though. It might be more of an issue for things like context-menu
selections, though.
simple-storage:
Fine, except that .onOverQuota callbacks may be asynchronous with respect to
setting storage data, and a few extensions may not expect this behavior.
tabs:
the on* functions will be called asynchronously. For the most part, this
probably doesn't matter.
.contentWindow, .contentDocument: not available
.thumbnail: probably not available
widget:
on* events are delivered asynchronously
We should probably add a page-worker style API for widgets which have
content:URL.
--BDS