"onMessage" spelling is inconsistent with the Web Workers API.

[Pauan]

When communicating with content scripts, you can attach onMessage
event listeners in two different ways:

require("page-worker").PageWorker({
contentURL: "foo",
onMessage: function (message) {
// Handle the message
}
});


// OR


var page = require("page-worker").PageWorker({
contentURL: "foo"
});
page.on("message", function (message) {
// Handle the message
});


This is quite reasonable and sane. However, within a content script,
you must use a global variable `onMessage`:

var onMessage = function (message) {
// Handle the message
};
postMessage("bar");


This is where things start to break down. Why are we using a global
variable, rather than say, addEventListener? Perhaps it's to be
consistent with the Web Workers API, which isn't entirely
unreasonable. Except the Web Workers API uses "onmessage", not
"onMessage".

I see a few ways to fix this:

1) Rename the global "onMessage" to "onmessage" within content
scripts, to be consistent with Web Workers.


2) Use addEventListener, like with other global events:

addEventListener("message", function (message) {
// Handle the message
}, true);
postMessage("bar");


3) Give content script JS access to the require function, but give it
very limited capability. Then it would be written like this:

var worker = require("worker");
worker.on("message", function (message) {
// Handle the message
});
worker.postMessage("bar");


4) Give content scripts a single global that would implement the
Worker interface:

worker.on("message", function (message) {
// Handle the message
});
worker.postMessage("bar");


#1 is a simple and quick fix, though it will probably break existing
programs. #2 is reasonable and shouldn't break existing programs. #3
and #4 are more about alternatives to the onmessage global that Web
Workers uses.

[Irakli Gozalishvili]

Hi Pauan,

There were long discussions on that and I personally prefered onmessage to be more consistent with web workers, but then DOM spelling for a dom event names is inconsistent by itself so we've sticked to a spelling that was more consistent with other jetpack APIs.

Good news is that #4 is actually in place, you can do:

self.on('message', function onMessage() {
   self.postMessage(....)
})

Also please note that `self`refers to the global in context of web worker as well so you could do:

self.postMessage
self.addEventListener


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[Alexandre poirot]

The use of standards names, patterns like postMessage is a cool idea,
but there is some corner cases with that particular choice:
When we use Panel or Widget (or any future visual API), we load a content document.
In most cases, this document want to communicate
with addon script that instanciate it.
So, if you had already played with addon-sdk,
you will immediatly try to use 'postMessage' function.
But this postMessage function is going to fail and you may not understand why easily!
It fails because this is HTML standards postMessage function:
https://developer.mozilla.org/en/DOM/window.postMessage

The solution is to communicate only with a contentScript.
Ok but that mean that contentURL is almost useless
when we want to define UI with an HTML document :(
Because communication between this document and addon script is going to be hard.

I would suggest to avoid confusion with W3C names and do "like in firefox":
https://developer.mozilla.org/en/The_message_manager
1/ Having an identifiable API that does not confuse with HTML ones
2/ As a bonus: having names on messages. This is a so common use case!!!
3/ I don't really know if it's doable, but offering a way to add this message passing API
in Widget/Panels content document would be very cool!

2010/12/30 Irakli Gozalishvili <rfo...@gmail.com>

[Pauan]

Well, great. I'm glad that there's a more sane alternative to the
onMessage global. I think that should be mentioned in the
documentation. As far as I can see, it mentions only `onMessage` for
content scripts.

On Dec 30, 3:38 am, Irakli Gozalishvili <rfo...@gmail.com> wrote:
> Hi Pauan,
>
> There were long discussions on that and I personally prefered onmessage to
> be more consistent with web workers, but then DOM spelling for a dom event
> names is inconsistent by itself so we've sticked to a spelling that was more
> consistent with other jetpack APIs.
>
> Good news is that #4 is actually in place, you can do:
>
> self.on('message', function onMessage() {
>    self.postMessage(....)
>
> })
>
> Also please note that `self`refers to the global in context of web worker as
> well so you could do:
>
> self.postMessage
> self.addEventListener
>
> Regards
> --
> Irakli Gozalishvili
> Web:http://www.jeditoolkit.com/

> Address: 29 Rue Saint-Georges, 75009 Paris, France <http://goo.gl/maps/3CHu>

> > mozilla-labs-jet...@googlegroups.com<mozilla-labs-jetpack%2Bun subs...@googlegroups.com>
> > .