{"id":82,"date":"2011-06-06T15:58:58","date_gmt":"2011-06-06T15:58:58","guid":{"rendered":"http:\/\/alexrock.com\/blog\/?p=82"},"modified":"2017-10-10T13:52:10","modified_gmt":"2017-10-10T13:52:10","slug":"differences-between-firefox-and-chrome-extensions","status":"publish","type":"post","link":"https:\/\/alexrock.com\/blog\/archives\/82-differences-between-firefox-and-chrome-extensions.html","title":{"rendered":"Differences between Firefox and Chrome Extensions"},"content":{"rendered":"

This entry was written during my time at IBM for a Firefox extension I had developed related to bookmarks<\/p>\n

I’ve been using Google Chrome<\/a> more often lately. I still prefer Firefox in a lot of ways, but you can’t beat the speed of Chrome.<\/p>\n

One thing I miss in chrome is a lot of my extensions, including my project. I decided to take a look at how hard (if even possible) it would be to port my project to Chrome. It turns out, not as bad as I thought (though certainly not trivial).<\/p>\n

Chrome’s approach to extensions is fundamentally different than Firefox. In Firefox an extension has pretty much full access to the entire browser – you can monitor and change every request the browser makes<\/a>, you can modify the way tabs work<\/a>, heck you can build the best javascript debugger on the planet<\/a>. Chrome extensions are far more limited in what they can do. They run in their own sandbox, apart from the rest of the browser. You’re limited to a button with a dropdown (popup)<\/a> display, an i con on the URL bar <\/a>(also with a potential popup), adding items to context menus<\/a>, and that’s about it. While you can get access to the websites the user accesses, and even modify them, you can’t fundamentally alter the browsers UI or behavior the way you can do with Firefox. This is not necessarily a bad thing – simplicity has it’s virtues – but it makes a big difference in the approach you take to the extensions.<\/p>\n

Despite the differences in approach, the differences in writing an extension for one app or the other is not quite as big as I expected. Firefox extensions (for the most part) have their UI written in XUL<\/a>(XML User Language), are scripted with JavaScript, and is themed with CSS. Chrome extensions have their UI written in HTML, are scripted with JavaScript, and themed with CSS. Well, hey, we have 2 out of 3, right? And while XUL and HTML are pretty different, they’re not that<\/i> different, especially when talking into account the HTML5 features chrome supports.<\/p>\n

\n

Writing an extension for Chrome is very similar to writing a website. In fact, it’s pretty much identical. The only difference is that you have access to the chrome.* API<\/a>, giving you some control over browser tabs, windows, history, etc. The downside is that you don’t have a rich featureset of widgets like you do with firefox ( trees, autocomplete, date controls, etc)<\/a>. On the other hand however, you can use javascript libraries like jquery <\/a>or dojo<\/a>, and not pollute or mess up the browser namespace. If you’re experienced with developing web applications, then it’s pretty easy to dive into creating an extension for chrome. Writing an extension for Firefox takes a bit more getting used to, learning a new UI language (similar to, but still different from HTML), new set of widgets, new set of quirks (although projects like jetpack<\/a> are making it easier to write Firefox extensions).<\/p>\n

Here’s a list of things I’ve found different going through and porting my project.<\/p>\n

\n

No for each<\/span> loop<\/h4>\n

One of the nice things about writing a Firefox or Chrome extension is that both browsers are fairly standards compliant, and both support modern versions of javascript ( Version 1.8.1<\/a> as of Firefox 3.5. Chrome supports ECMA Script<\/a> Edition 3, + roughly Javascript 1.7<\/a> ). This means stuff like properties<\/a>, fun array methods<\/a> and other little goodies. One of the things that Firefox supports is the for each<\/a> loop, which is actually part of the E4X <\/a>standard. This is a handy little item, it lets you loop through all of the items in an object, rather than the properties in an object. The catch? It’s not supported in chrome. I had to remove all of these loops in the my project’s code in order for chrome to even load my JavasScript.<\/p>\n

No Preferences System<\/h4>\n

Firefox has a fairly nice preference system<\/a>. Accessing it is a bit clunky, but the nice thing is that you can place an observer on any preference branch and get updates as soon as it changes.<\/p>\n

In chrome there’s no such thing. There is localStorage<\/a>, which you can use to store preferences, but if you want the observer functionality, you have to build it yourself.<\/p>\n

I wrote a wrapper around localStorage to present a similar interface to Firefox for preferences, and added methods for registering observers. Because all of the pref changes that need observing are made by only by my project, I didn’t have to worry about observers getting updates if they changed through some other means.<\/p>\n

No Password Storage<\/h4>\n

Firefox has nsILoginManager<\/a> for storing passwords. By default these are stored unencrypted, but you can set a master password <\/a>to encrypt them. In chrome, the only option for storing password is localStorage, which is unencrypted.<\/p>\n

Different way to get the current window information<\/h4>\n

my project needs to know the URL of the current window so it can bookmark it. The way to access this information is different in each browser.<\/p>\n

Firefox:<\/p>\n

var info={url:getWebNavigation().currentURI.spec,\n  title: getWebNavigation().document.title}<\/pre>\n
In chrome the method is asynchronous, and requires additional permissions in the chrome.manifest:<\/div>\n
        chrome.tabs.getSelected(null, function _getWinInfo(tab){\n                var info = {\n                        url:tab.url,\n                        title:tab.title\n                };\n            });<\/pre>\n
Different logging<\/h4>\n
My project has a bunch of built in logging. Much is for diagnostic purposes, but some is for important errors. For the most important errors Components.utils.reportError<\/a> is used. This reports the error to the built in Firefox Error Console<\/a>. It’s possible to report other errors to this console, but it’s more complicated<\/a>.<\/p>\n
The rest of logging in my project is provided by a home-grown logging service. Extensions in Firefox can write to disk, so that’s what the project’s logging service does. Chrome doesn’t allow extensions to write to disk. It does have a console object however, that can be used for logging at various levels (a la firebug).<\/p>\n
To prevent having to change a bunch of code, I created a bridge to reportError:<\/p>\n
\/\/Fake out the report error method so we can still use it in code\n\n    Components = {\n            utils:console\n    }\n    Components.utils.reportError=console.error;<\/pre>\n
Different system for localization<\/h4>\n
Chrome’s localization system sucks.\u00a0 The FF version isn’t great either, but I really hate the chrome one.\u00a0 In FF you have two different ways to localize strings – in XUL, you can use DTDs<\/a>.\u00a0 This is a very strange use of DTD, but in practice it’s pretty straightforward.\u00a0 In your XUL, you reference some string with an entity reference like &confirmButtonLabel;<\/b>.\u00a0 In your DTD you will have an entry like so:<\/p>\n
<!ENTITY confirmButtonLabel “Do It!”><\/div>\n
<\/div>\n
\n
The other method is through javascript, using stringbundles<\/a>.\u00a0 You create a .properties file with strings (similar to java), get reference to the bundle, and then call<\/p>\n
somebundle.getString(\"somekey\")<\/pre>\n
You can also call getFormattedString <\/code>to fill in placeholders in a string.<\/div>\n
<\/div>\n
\n
In chrome, there is only one localization system<\/a>.\u00a0 You create a weird JSON formatted messages.json for each language, and pull strings from that file.\u00a0 You get a string by calling<\/p>\n
chrome.i18n.getMessage(\"somekey\")<\/pre>\n
The reason I say this sucks is that there’s no way to automatically substitute strings in an HTML file.\u00a0 You have to do it all with script.\u00a0 If your popup is just some fixed HTML, you have to figure out your own substitution system.\u00a0 This is annoying, and a feature sorely lacking from chrome.\u00a0 The messages.json format is also weird, and there’s no existing tools that I could find to work with it.<\/div>\n<\/div>\n<\/div>\n
No Prompt Service<\/h4>\n
Firefox has the nsIPromptService<\/a> which makes simple dialogs easy.\u00a0 You can crate things from a simple alert<\/a> (with control of the title) to a more complex dialog with multiple custom labeled buttons<\/a>.\u00a0 I haven’t ported the functionality needed to do this just yet, but when I do, I will probably use jQuery UI.<\/p>\n
No Built In Widgets<\/h4>\n
Firefox has all kinds of built in widgets.\u00a0 The main one I was missing was a typeahead <\/a>and search textbox<\/a>. I used jQuery UI<\/a> for the typeahead, and wrote a custom search textbox to emulate the behavior of the FF version.<\/div>\n
getElementsByTagName is not scoped to the default namespace<\/h4>\n<\/div>\n<\/div>\n
In Firefox, when dealing with a namespaced document (like an atom feed), doing feed.getElementsByTagName<\/span> is limited to the default namespace of the document. In chrome, it looks in all the namepsaces. This is a problem, because in dogear feeds there are two link elements. They’re not really the same element, because they’re in different namepsaces, but apparently that doesn’t matter to chrome.<\/div>\n
\n
<link href=\"http:\/\/signature.innovate.ibm.com\/index\" \/>\n<snx:link linkid=\"9a18b409-3188-41be-a87c-815d4de784ec\"\/><\/pre>\n
To be fair, the dom spec doesn’t say which way browsers should implement this method. I can’t really think of an instance where the chrome behavior would be useful. While both those things above are in a tag named link, they have completely different meanings. That’s the whole reason for having namespaces in the first place.<\/div>\n
\n
Fortunately the solution isn’t that difficult, you just have to call getElementsByTagNameNS<\/span>, passing in the default atom namespace. It’s an annoying thing to have to change, however.<\/p>\n
Less tolerance for twice defined variables<\/h4>\n
Another problem I quickly encountered was issues with variables defined twice. Javascript only has two levels of scope, function or local scope, and global scope (JS 1.7 now has block level scope<\/a>, but never you mind that). No mater how nested it might be, once a variable is defined in a function, it exists throughout the entire function. This means that it’s actually wrong to declare it again (though you’ll get no error if you do so). Firefox and Chrome behave differently if you do so. Here’s an example of an issue I had<\/div>\n
if(someCondition){\n    var something=\"xyz\";\n}else{\n    var something=\"123\";\n}\nalert(something);<\/pre>\n
\n
In Firefox, if someCondition <\/span>is true<\/span>, the result is the alert will display “xyz”. This is valid because once something<\/span> is defined, it’ll exist throughout the function.<\/p>\n
In chrome, the value of something<\/span> ended up being undefined<\/span> (actually, if you run this example, chrome will say xyz. Mine must have been more specific, but was similar in concept). The reason wasn’t clear until I looked in fireb <\/span>Developer Tools. What was happening is two<\/span> something<\/span> variables were being defined, and chrome decided to use the second, uninitialized one. One way to fix this is to remove the second var:<\/p>\n<\/div>\n
if(someCondition){\n    var something=\"xyz\";\n}else{\n    something=\"123\";\n}\nalert(something);<\/pre>\n
alert(something);but this makes the Java\/C++ developer in me cringe. Instead, I did a more proper looking:<\/p>\n
var something;\nif(someCondition){\n    something=\"xyz\";\n}else{\n    something=\"123\";\n}\n\nalert(something);<\/pre>\n
(Note I couldn’t actually come up with a sample that replicates this problem — maybe it was really another issue and I just thought this was the issue.)<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
This entry was written during my time at IBM for a Firefox extension I had developed related to bookmarks I’ve been using Google Chrome more often lately. I still prefer Firefox in a lot of ways, but you… Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-82","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/posts\/82","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/comments?post=82"}],"version-history":[{"count":3,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/posts\/82\/revisions"}],"predecessor-version":[{"id":85,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/posts\/82\/revisions\/85"}],"wp:attachment":[{"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/media?parent=82"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/categories?post=82"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alexrock.com\/blog\/wp-json\/wp\/v2\/tags?post=82"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}