/dev/nikc/blog

I spent today debugging strange JavaScript behaviour in Firefox. The scenario was as follows:

The main interface of the app I’m working on loads document fragments on demand. These fragments contain script blocks. We use jQuery to load these fragments.

When jQuery.appending a new fragment into the DOM jQuery cleverly extracts all script nodes from the fragment and then synchronously executes them in the order they appear, regardless if their source is external or inline, and only after all scripts have been evaluated returns. A blocking operation, which in our case is what we want.

The script handling the main interface (and pulling in the needed bits) depends on this behaviour —(which might be silly and could be avoided by redesigning the architecture, but that’s a different story)— and today it broke for no apparent reason. After some hours of peeking and poking I found the culprit to be Facebooks’ loader script which appends more scripts with external sources into the DOM. The fact that the script came from Facebook is irrelevant here, the injected script nodes aren’t¹.

Safari and Chrome handles this elegantly, leaving jQuery’s behaviour unchanged, but in Firefox it caused jQuery to return prematurely. In Firefox, it looks as if the dynamically injected externally sourced script node is forcing asynchronous evaluation to all dynamically injected script nodes, including the ones with inline source code.

The solution was simple enough: keep the Facebook share script at the bottom, but locating the issue was a pain. Whether or not this is a Firefox bug, I don’t know, but I couldn’t find anything on the issue so I thought I’d give it my 2 cents.

A simple demo, for those who are curious. Latest production version to date of all mentioned browsers were used in testing.

When Chrome was released, I was thrilled. Well, not about everything, but mostly it was great. It’s speed was praised high and low and I was no exception. Lot’s of things I criticised have since been fixed, but one thing still remains:

There is no hint of an available feed in the address bar omnibox, or anywhere else either as far as I can see. What’s going on here, really?

Being a feed junkie (if you couldn’t already tell), I was very surprised to learn from Camendesigns’ blog post RSS is dying that Firefox is about to go down that same road in its upcoming version 4. Of course, the functionality is not going anywhere, as Asa Dotzler states in his retort, but will be moved inside the bookmarks menu.

Maybe it’s just me, but I think having to open up a menu just to discover whether a feed is present or not is hardly a step forward. In my mind this is the same as if a car manufacturer decided to move the fuel gauge from the dashboard to inside the glove compartment. Sure, you can still check the fuel level but you have to make an effort instead of being able to do the same with just a glance.

Naturally, webmasters can still flaunt their feeds themselves, just like I do, but I dislike duplicating browser functionality – in my defense, I’m doing it to justify the presence of the link to whatisrss.com with which I thought I could advocate and educate about feeds, optimistic as I am.

I’m glad that for Chrome the lack of feed hinting can be fixed with a plugin. One can always hope a similar Addon will be available for Firefox as well.