The Coding Dojo page for this kata also has a video of it performed in Ruby. There’s also a link to a video of it in Excel, but as much as it sounds good, it’s just building a VB macro…

You can find my code on GitHub. I have also prepared a walk through on how I arrived at my solution (txt is the new ppt!)

The previous kata sessions used Jasmine – and it works just fine – but I chose to do things with YUI Test. If you feel like it – I prepared a skeleton for the project. Note that it loads YUI from Yahoo’s CDN, so make sure you’re online (or update the harness.html).

It may not be 100% correct, it may have it’s own flaws, and obviously it may soon become obsolete, as Opera 11 is still in alpha, but I did create a more reliable example of how to communicate between the user scripts and popup windows.

This article assumes you already grok the introductory information on Opera extension. In fact, knowledge of Chrome extension flows may also help.

The flaws

Let’s skip the ranting about lack of documentation (hint hint) and look at the fundamental flaws in the original Communicating between popup and injected script example. You can download the modified version of it that attempts to display the page title. I also documented the steps to reproduce two bugs in it.

1. There is only one communication channel – and it’s always reset to the page which was loaded last.
2. The above means, that we may not be communicating with the focused tab.
3. The above also means that the channel is not re-established once a new popup opens – even if it’s on the same tab. I suspect that if (port) is supposed to check whether the channel is still active, but (potentially – due to a browser bug) it returns a truthy value, hence the new channel is not sent to the popup.
4. The check inside onconnect only validates that a communication channel was created – it never validates that the connecting script is actually a popup window

The solution

In here, I have a couple of things that are merely assumptions on how things work, and how the API should respond – this is mostly due to lack of documentation (hint hint, again) and is based on experience with Chrome extensions.

The core point of the solution is to avoid storing the communication channel in the background script – instead – store a reference to the popup window. I feel that it is safe to do, since the popup window closes automatically, and it seems that all data associated with it gets destroyed.

The background script still plays an important role – it’s job is to pass the MessagePort from the user script to the popup, but it only does that when requested. As mentioned above, when the popup window closes, we also need to re-establish the connection, so the final flow becomes like this:

1. Browser loads, background script is initialized
2. A page in a tab loads, user script gets initialized
3. User clicks on the toolbar icon for the popup
4. The popup loads
5. Background page receives an onconnect event
6. It then checks the event origin – all widget related files have URLs that start with widget://
7. If the thing that just connected is a popup window, the background script determines the active tab, and sends a getPorts message to initiate messaging connection. It also stores the reference to the popup for future communication.
8. The user script receives the message and creates a new communication channel (it assumes that the previous channel is long dead)
9. It then sends that communication channel back to the background script using establishConnection message.
10. The background script forwards that message to the previously stored popup reference. I feel that it is safe enough to trust that, since the steps 5-9 should really be pretty much instantaneous without any user interaction possible in between.
11. The popup receives the communication channel – it is free to do with it whatever it likes, e.g. request information from the user script using postMessage() and receive that information using onmessage.
12. Once the popup closes, we end up at point 2

Download example code (I release it into public domain, without any guarantees)

The gotchas, suggestions and pleas to the Opera team

Document MessageChannel and MessagePort

While this is an obvious request, I’d also like to mention that I find Chrome’s model of two way messaging much simpler – just pass around a callback function for each message.

Rename port1 and port2 to something meaningful

My initial response to these two properties was that one of them is for sending messages, the other is for receiving. As far as I understand that right now – one is to be used as a “local” communication port, and the other is for the use by “remote” script. They should be named accordingly. However, a much better approach would be to not expose them at all – same as the previous suggestion – it should be possible to just create a MessageChannel with postMessage() and onmessage – which are inversed once they change context.

Clarify if objects are allowed as event.data

I’ll admit – I didn’t read the W3C spec. My example uses simple objects, but the API documentation says the message data has to be a DOMString. While it’s not a biggie, and I’m sure everyone is good friends with JSON.stringify() and JSON.parse(), it either should be documented as allowed or should throw errors when used.

Create an easier way to determine who is the event.origin

At the moment, to check if the message was sent by a popup, I’m testing the URL in the event.origin, but I’d really like to see some methods, such as isBackgroundScript(), isUserScript() and isPopup() for simplicity.

More graphical information

I’m guilty here, since I probably should have included the flow diagram instead of an 11 point list in this blog, but I do find the visual guide to the API very useful. The Dev.Opera article about messaging inside extensions should have included some of that love.

Explain best practices

Having looked through most of the example extensions, I find certain things quite interesting – and they do raise a lot of “why” type questions:

• Why do we need to do stuff on load in the background scripts?
• How does that make a difference as compared to just executing the code in the <script> tag?
• Do we also have to do things on load in the popup scripts?
• Why do some examples check for existence of opera.extension? When it might not be available?
• What are the “dos” and “donts” for the background process? What are the limitations? Considering that it’s a page that’s always active, I’m sure there are plenty.

I hope the time spent with frustration, figuring things out and writing up this article was worth it. I also hope that it’s useful for at least one other person. However, in case of the information in here is already published and the questions are already answered – please – drop me a link in the comments or on twitter @dymonaz.

Results

1. Chris Heilmann’s YUI based approach (136ms)
2. Chris Heilmann’s DOM based approach (247ms)
3. Stuart Langridge’s generated-toc (258ms)
4. Josh Johnston’s solution with jQuery (781ms)
5. My own HTML5 Outliner (3099ms)
6. Chris Heilmann’s RegExp based approach (4440ms)
7. Diogo Vincenzi’s solution with jQuery (9334ms)

Methodology

The numbers above are based on an 1.5Mb file, which has some 200 headings to use for the TOC table. The actual file, was created out of HTML4 specification part on forms, to reflect a more natural usage. The results were a bit different, when I used my own generated file, which had a lot more headings, and a lot less text.

The test runner itself would create an iframe, load the test document inside, inject the required script and call it. The source is available on Google Code (though be aware, that you will need to procure and hack the dependencies yourself).

I ran it on a decent 2.2Ghz laptop, using a vanilla version of Portable Firefox 3.5. With some exceptions (see below), the results were comparable and not unexpected in other browsers.

Insights

• The RegExp based approach was a non-contender from the start, as it doesn’t really work under any browser, other than Firefox.
• Diogio’s solution scored so low because it’s querying the DOM twice inside every loop iteration (I think).
• I am impressed at how well YUI3 performed – on every browser (incl. IE8), except Opera. I seriously need to follow up on the Opera thing…
• Speaking of YUI3 – one needs to go through extra hoops to measure performance, due to YUI loader’s setTimeout(). And make sure that you have all dependencies in on file, to avoid calls to the Yahoo’s CDN.
• IE8 didn’t like 2Mb documents inside an iframe (hence 1.5Mb)
• I have plenty of space for improvement – it will be fun!

It doesn’t do anything, it just sits there!

Now, normally I’m not a complete standards freak (unlike the guys working on Caja). But what does <a href="javascript:void(0)"> really mean? The answer is simple – nothing.

First of, it’s a hyperlink to a resource, which should be accessed over Javascript “protocol”. Here’s the problem – I don’t really feel that “javascript” is a protocol. And it can’t really handle resources. But lets ignore that. What is the actual resource?

The link tells “use javascript” to “retrieve”… void. Why would anyone in the world want to view void in their browser? If anyone ever wants to look at it – they’re much better off achieving that goal on YouTube…

Semantics apart – it’s not comprehensible

Lets suppose, you don’t really care about web standards and semantics. I’d probably agree with you – we’re quite far away from having a meaningful web (if ever). Still, having crap as the URL is no good – apparently, screen readers will read that URL out loud.

Can you imagine anyone discussing this over a pint: “You know, I found this great site at javascript colon void opening parenthesis zero closing parenthesis“? That kind of URL would not make any sense to regular folks.

Accessibility is NOT about screen readers, though

Such a link kills browsing experience for sighted users too. Have you ever tried what happens when you middle-click the void link? Or right-click and then select “Open in new tab”? Here – try it out (mileage may vary if you use a recent browser).

Exactly – you guessed it – nothing meaningful happens. Just as it should!

Solution 1: Use real URLs

There are several ways out of this. My favorite one is to provide a real URL. If you’re following progressive enhancement methodology in your work, you always want to provide alternative links to achieve (near full) functionality even when Javascript is disabled.

This means, that instead of having a <a href="javascript:void(0)">Delete</a> and attaching onclick handler to it, popping out a confirm dialog and then making a background call using XHR, you provide a link to e.g. /myResource?delete which brings up a form, with a real <button>.

The actual backend code doesn’t become that much trickier – you don’t really have to write up a new “delete” routine. By using a confirmation interstitial, you also provide a way to confirm the action, and you can still use a POST request, as this action has permanent effect.

Solution 2: don’t use anchor tag

The above solution doesn’t always work – if you have a really interactive application, you’re not always able to provide links. However, since you’re already using JS – why use the <a> tag where it doesn’t belong?

I did hear some advice, to use <button> for clickable things, which are not really links. You should investigate that, but anyone who has tried to style buttons, knows that it can very easily become a major pain.

Still, you can attach your onclick handlers on anything you want – div, span and so on. In such cases, you should also add tabindex to make elements focusable and make use of ARIA roles to provide guidelines on behaviour. It’s not really that hard, now, is it?

The only really painful thing here is providing :hover and :focus styles on IE6. But IE6 should also die, together with javascript:void(0).