context-menu API changes in Jetpack SDK 0.9

73 views
Skip to first unread message

Drew Willcoxon

unread,
Oct 13, 2010, 7:24:22 PM10/13/10
to mozilla-la...@googlegroups.com
Hi all,

The context-menu API will change in Jetpack SDK 0.9, so I want to give
everyone a sketch of what those changes look like. The info in this
message is also in 0.9's context-menu documentation, so if you're
interested feel free to skip this and read that instead.

As you may know, we're adapting many of Jetpack SDK's APIs to work with
Electrolysis, often called e10s for short [1]. Since the context-menu
API interacts with web content, it's one of the APIs that has to change.

The first thing to note is that context-menu now uses content scripts.
Each menu item you make has an associated content script, similar to the
page-mod, page-worker, and panel APIs. Whenever you need to interact
with web pages in Jetpack, as these APIs do, think content scripts. You
can only interact with pages from content scripts.

For context-menu this means that function contexts and the menu item
onClick() method are gone.

Instead of function contexts, you now listen for the "context" event in
your content script. If your listener returns true, then the menu item
associated with the content script is shown, so that part is similar to
function contexts.

So for example, instead of:

contextMenu.Item({
context: function (contextObj) {
return contextObj.document.URL == "http://example.com/";
}
});

You would now do:

contextMenu.Item({
contentScript:
'on("context", function (contextNode) {' +
' return document.URL == "http://example.com/";' +
'});'
});

contextNode is the node in the web page that the user right-clicked to
open the context menu.

And instead of onClick(), you now listen for the "click" event in your
content script. So instead of:

contextMenu.Item({
onClick: function (contextObj, clickedItem) {
doSomething(contextObj.node);
}
});

You would now do:

contextMenu.Item({
contentScript:
'on("click", function (contextNode, clickedItemData) {' +
' postMessage(contextNode.someProperty);' +
'});',
onMessage: function (nodeProperty) {
doSomething(nodeProperty);
}
});

clickedItemData is the data property of the menu item that the user
clicked. postMessage() is how your content script communicates to its
menu item, and onMessage() is how your menu item receives messages from
its content script. You can only pass messages that can be converted
into JSON, but your messages don't have to be JSON.

Inside your content script, `window` and `document` refer to the window
and document of the web page on which the context menu was invoked. And
of course you can use the contentScriptURL property rather than
contentScript when making new menu items.

So that's it for e10s changes.

There's one more change. You can still use the `context` property when
making menu items, but the values it accepts are different in 0.9.
There are now different Context classes: PageContext, SelectionContext,
SelectorContext, and URLContext. You can read about each of them in
0.9's documentation, but to take one example, if you have a menu item
with a selector context, it used to look like this:

contextMenu.Item({
context: "a[href]"
});

And in 0.9 it would now look like this:

contextMenu.Item({
context: contextMenu.SelectorContext("a[href]")
});

Feel free to reply if you have any questions or comments.

Drew

[1] e10s is an ongoing project by people on the Gecko platform team to
run different parts of Firefox and other Gecko-based applications in
separate processes. For Firefox that means web content, browser chrome
UI, plug-ins like Flash, and parts of Jetpack-based extensions will all
be running in different processes. More info:
<https://wiki.mozilla.org/Electrolysis>

Wes Widner

unread,
Oct 21, 2010, 8:30:57 PM10/21/10
to mozilla-labs-jetpack
I've just started playing with the new context menus now that .9 is
out and I have several questions. My first one is this: Is there no
way to access modules in content scripts? Do we no longer have access
to notifications, clipboard, panels, and xhr?

-Wes

Drew Willcoxon

unread,
Oct 21, 2010, 8:44:00 PM10/21/10
to mozilla-la...@googlegroups.com
You can't access Jetpack APIs from content scripts, but all content
script-based APIs have a web worker-like interface for posting and
receiving messages between content scripts and your Jetpack modules,
which can of course use Jetpack APIs.

So what you end up doing is collecting data from content and then
postMessage()'ing it to your Jetpack module. Some APIs also let your
Jetpack module talk back to content.

Here's an (untested) example for context-menu:

var contextMenu = require("context-menu");
var item = contextMenu.Item({
label: "Hello!",
contentScript: 'on("click", function () {' +
' postMessage(document.URL);' +
'});',
onMessage: function (docURL) {
require("notifications").notify({
text: docURL
});
}
});
contextMenu.add(item);

Another example with context-menu and request is here:
https://jetpack.mozillalabs.com/sdk/0.9/docs/#guide/programs

Drew

Julián Ceballos

unread,
Oct 21, 2010, 10:27:52 PM10/21/10
to mozilla-la...@googlegroups.com
I have a doubt, why this new implementation?... Security?

El 21/10/10 19:44, Drew Willcoxon escribi�:


--
Juli�n Ceballos
Mozilla M�xico Software

Wes Kocher

unread,
Oct 22, 2010, 12:09:24 AM10/22/10
to mozilla-la...@googlegroups.com
E10S future-proofing, if I understand it correctly.
The previous way would be really buggy trying to cross from some firefox process to the content process for the page.

With the eventEmitter stuff, all the interactions are clearly defined.

2010/10/21 Julián Ceballos <cristianjul...@gmail.com>

Drew Willcoxon

unread,
Oct 22, 2010, 12:27:42 AM10/22/10
to mozilla-la...@googlegroups.com
We're getting the APIs ready for a world where Firefox handles web
content, chrome, and Jetpack modules all in separate processes. That
world isn't here yet, but we want to be prepared for it, especially
since Jetpack is currently in alpha and we want to avoid breaking APIs
later when it's more mature. (The process-separation project is
code-named Electrolysis, or e10s for short, as I mentioned earlier.)

Eventually your content scripts will run in content processes along with
web pages, and your Jetpack modules will run in Jetpack and chrome
processes. In general, and not just for Firefox or Jetpack, one process
can't directly access the memory of another. Jetpack modules won't be
able to directly access windows and documents for example, because
they'll live in separate processes. And there are other problems, like
making sure one process doesn't prevent another from doing its work,
especially when that work is something like running the UI. So people
invent ways for processes to safely communicate. For Jetpack APIs we're
trying an interface similar to web workers where you post messages
(JSON-able data) one place and receive them somewhere else.

Sorry if I'm talking down to you or anyone else, but Jetpack has a wide
audience!

Drew

Reply all
Reply to author
Forward
0 new messages