The JavaScript blog.


chrome extensions browsers

Live Reloading Chrome Apps, Chrome Extensions with React, sendMessage Tutorial

Posted on .

Live Reloading Chrome Apps

The Chrome Store itself is a pile of rubbish apps with very few exceptions.

Working with Chrome extensions and apps is pleasant enough in some ways -- the JavaScript APIs are generally intuitive, and you can make native-feeling UIs without too much effort. However, the development experience feels a little bit dated and painful in places.

Konstantin Raev sent in Live Reloading Chrome Apps, an article about using Gulp with Chrome apps. It shows how live reloading isn't as easy as it could be, and how to fix it. There's also a full example on GitHub: bestander / clock-chrome-app-livereload-example.

Creating Chrome Extensions with React

Brandon Tilley sent in Creating Chrome Extensions with React:

If you're into client-side web development to any extent, you've probably heard of Facebook's React library. I was working on a Chrome extension, and decided to see how well React fit in to the development I was doing.

He also uses Browserify as well, which I'm interested in because I tried using RequireJS for sharing code between Chrome extensions and Firefox add-ons, and I struggled to get it to work in Firefox. My Firefox add-ons are using the Jetpack SDK rather than the old XUL way.

Passing data around in Chrome extensions

Passing data around in Chrome extensions by Erica Salvaneschi is an introduction to using chrome.runtime.sendMessage and addListener:

We wanted to get data from the current web page and then use it to populate a form that appears in a new window. It was easy to create a context menu item that triggered an event, but sending data based on the current page to the new window wasn't obvious.

You might find this useful if you're just getting into Chrome extensions and want more concrete examples than what Google provides.


firefox browsers

Multiprocess Firefox

Posted on .

Multiprocess Firefox

I know a lot of DailyJS readers who use Chrome and Safari as their main browsers, partly due to iOS and Android's popularity, and partly because Chrome's initial performance gains enticed them away from Firefox. The big issue over the last few years has been the fact browsers are switching to using multiple processes, the idea being that resources can be shared better and fallout from crashes can be mitigated.

If Firefox isn't your main browser, you probably use it for testing or just try it out every few months to see what's been going on. The thing most of us have been looking for is Chrome (and apparently IE)-style multi-process support. Bill McCloskey has written a post about this very topic: Multiprocess Firefox. Bill is a programmer at Mozilla, and you may remember his post about incremental GC in Firefox.

Although the work so far sounds promising, there are some major technical hurdles. These partly relate to the nature of how JavaScript interacts with the DOM, and how Firefox handles add-ons:

JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we've considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).

Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.

You might not realise it, but Firefox itself uses a lot of JavaScript:

Content scripts. IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes.

We decided to do the message passing in JavaScript instead, since it's easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we're using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

If you're an add-on author, you'll be pleased to hear add-ons are being taken seriously. However, Mozilla may need your help in the future:

We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons. At the same time, we feel strongly that users will appreciate the security and responsiveness benefits of multiprocess Firefox, so we're willing to work very hard to get add-ons on board. We're very interested in working with add-on developers to ensure that their add-ons work well in multiprocess Firefox.

It's hard to imagine Firefox OS not using multiple processes, and Bill mentions this early on in the post:

Firefox OS relies heavily on the multiprocessing and IPC code introduced during Electrolysis.

Electrolysis was a project to use multiple processes, but the focus was tighter than changing the desktop browser. Firefox's layout engine, Gecko, supports multiple threads, and the "Gecko platform" supports multiple processes. But, as the Electrolysis wiki page points out, the Firefox frontend does not currently use multiple processes.

Will we see a browser share increase when Firefox is updated to support multiple processes? I don't know, but as a front-end developer I'm excited about seeing this feature released sooner rather than later.