#postmessage

Last week I worked on a small feature for the Wiser chrome extension. I added functionality such that when a user highlights text on the webpage and then opens the extension, the selected text gets pulled into the excerpt field in the extension.

The tricky part was, there are three layers to the extension, the webpage, the popup, and the iframe within the popup. Neither the popup nor the iframe could see the highlighted text. So I set up a series of listeners and sent the message (the selected text) from the webpage, to the popup, and finally to the iframe.

I sent these messages using two different methods: the chrome extension api and javascript's postMessage function. The latter allows you to send cross-origin messages, which I needed to do in order to get the text from the popup to the iframe.

Here's a picture of how the message flow works:

Here is the javascript from the three layers. The numbers in the comments correspond with the numbers in the picture.

content_script.js (runs in the webpage)

// (5) sends a message to popup.js using chrome extension api function tell (message) { chrome.extension.sendRequest({message: message, data: "from content_script"}); }; // (4) grab the selected text and send it using the tell function tell(window.getSelection().toString());

popup.js (runs in the extension popup)

// (7) calls tell function if response has a non-empty message function onPostMessage (request) { if (!request.message) { return; } else { tell(request.message) return; } }; // (8) sends message to iframe using postMessage function tell (message) { chrome.tabs.getSelected(null, function (tab) { if (!tab) { return; } iframe.contentWindow.postMessage(message, "*"); }); }; // (3) runs content_script.js using chrome extension api function iFrameReady () { chrome.tabs.executeScript(null, { file: "content_script.js" }); }; // (6) listener for message from content_script.js using chrome extension api // it's important that this listener is set up before we run content_script, // otherwise the message from content_script will arrive before the listener exists chrome.extension.onRequest.addListener(function(request) { onPostMessage(request); }); // (2) listener for message from iframe // (not using chrome extension api here because the message is sent using postMessage window.addEventListener("message", function(request) { if (request.data.data == "ready") { // when iframe is ready, run content_script iFrameReady(); } }, false);

in the iframe

!

On Sunday, somebody with the nickname {g} was on irc.mozilla.org asking about the behavior of setTimeout. In particular, he wanted to divide up work into a bunch of pieces in a way that allowed the user to interact with the page while the work was happening, and was doing this by doing a piece of the work, and then making a setTimeout call to continue the work. (In some cases, this could also be done using workers.) Unfortunately for him,setTimeout in most browsers doesn't allow a delay less than about 10 milliseconds (it forces any smaller delays to be longer), so the work wasn't finishing as fast as it could. (Chrome has changed this to 2 milliseconds, though, and apparently had some problems with it.)

A while ago, Jeff Walden suggested to me that Web pages could get the equivalent of setTimeout, with a real zero delay, using postMessage. This turns out to be relatively straightforward

...

I wrote a demo page that demonstrates that this is significantly faster than setTimeout(0). On a Firefox nightly 100 iterations of setZeroTimeout take about 10-20 milliseconds most of the time, but occasionally longer; on a WebKit build I have it takes about 4-6 milliseconds, but occasionally a bit longer. (We should probably investigate the performance difference here.) In comparison, in Firefox and on non-Chromium-based WebKit, the setTimeoutversion takes about a second (though perhaps even longer on Windows).

There was a recent article on Softonic claiming “Microsoft's browser benchmark cheats, gives IE 11 speed crown”. I attempted to comment on the article, but it seems that they are being eaten by the site’s comment system. Instead, I’m posting it here, as I think there are some important inaccuracies that need highlighting. After all, “cheating” is a serious allegation.

I had a small project that needed to serve up a form on a site (Site B) that would be shown in an iframe on another site (Site A) on a different domain. As well as submitting the form Site B needed to send some resulting data back to the Site A page.

Normally cross-domain restrictions prevent JavaScript data from being shared between the sites. However, the little known (to me at the time) window.postMessage method specified in HTML5 allows "documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks".

Ben Alman encapsulated it in a jQuery plugin and I used this to pass data from Site B to Site A. It was also useful in providing a way for Site A to set the height of the iframe based on the variable markup in Site B, so that scroll bars are never seen.

I've got a demo illustrating:

Sending a simple text string

Sending a package of data (passed as a param string via jQuery.param())

Resizing the iframe