wanderview

Firefox 52 setTimeout() Changes

2017-03-13T13:30:00+00:00

Firefox 52 hit the release channel last week and it includes a few changes to setTimeout() and setInterval(). In particular, we have changed how we schedule and execute timer callbacks in order to reduce the possibility of jank.

To start, consider the following simple demo site (you may not want to run it yourself):

Demo Site

When you click the “Start” button the site will begin flooding the browser with setTimeout() calls. Each callback will call setTimeout() twice. This results in an exponential explosion of timers. Clicking “Stop” will cause the timers to stop calling setTimeout().

The animated GIF is there so that you can visually see if any jank occurs. (This is a great technique I am stealing from Nolan Lawson’s IDB performance post).

Traditionally, browsers will begin dropping frames when this sort of thing happens and the GIF will stop animating. For example, this video shows Firefox 45 ESR running the demo:

In Firefox 52, however, we have made changes which allows the browser to mostly survive this use case. This video shows that, while there is a brief pause, the animated GIF continues to play fairly smoothly in spite of the timer flood.

How Does It Work?

Firefox achieves this by implementing yielding between timer callbacks. After a timer callback is executed we allow any other non-timer event pending in the queue to complete before running the next timer callback.

For example, consider the case where we have a number of timer callbacks that want to run at the same time as a vsync refresh. Its a bit of a race which events will get to run first. The refresh, however, is often considered more important because if it’s delayed then the site’s frame-per-second will drop.

With this in mind, consider the “best” case and “worst” case for scheduling the events:

In the best case the refresh runs first and is not delayed. In the worst case the refresh is delayed until all the timer callbacks have executed. In extreme cases, like the demo above, this delay can be quite long.

Yielding between timer callbacks changes the situation so that the worst case looks like this instead:

Now, the refresh will be delayed by at most one timer callback.

In reality we don’t actually re-arrange events in the event queue. Perhaps a better way to think of it is that timers are stored in a separate queue. Only a single timer is allowed to be scheduled on the main event queue at any time.

So after “callback 1” completes here “callback 2” will be placed on the main event queue at the end. This allows the refresh event to execute next.

Is This Throttling?

No. Typically “timer throttling” means introducing some amount of delay into each timer. For example, if you call setTimeout(func, 5) in a background tab most browsers will delay the timer callback for at least one second.

Yielding is different in that it allows timers to run at full speed if the main thread is idle. Yielding only causes timers to be delayed if the main thread is busy. (Of course, if the main thread is busy then timers have always run the risk of being delayed.)

That being said, if we detect that the timer queue is backing up we do begin throttling timers. This backpressure helps avoid exhausting memory when a script is generating more setTimeout() calls than can be executed. This back pressure is tuned to only trigger in extreme cases and most sites should not experience it.

Is This Prioritization?

Again, no. Timer yielding is not quite the same as using a priority queue and marking timer callbacks low priority. In a strict prioritization scheme it would be possible for low priority events to never run. That is not the case here.

In our timer yielding approach the next timer callback is run at the same priority as all other events. It may execute before other work. It is also guaranteed to be executed at some point.

What’s The Catch?

While our general approach is to yield between timers, our end solution doesn’t actually do that. We actually allow a limited number of timer callbacks to run without yielding. We do this to mitigate impact to sites that use timers while saturating the main thread.

For example, consider a site that is:

Running an animation through a large number of timer callbacks.
The animation is saturating the main thread with painting.

In this case the timer callbacks will be throttled by the rate at which the paints can happen. When the browser cannot execute the paints at 60 FPS, then you will get at most one timer callback between each refresh driver event.

This is not a problem for “closed loop” animations where you measure how long things are taking to run and adjust your changes to match. It can, however, dramatically increase the overall animation time for “open loop” animations.

For example, consider this animation demonstration site:

“Open Loop” Animation Demo

Here the site pre-computes all the animation steps and schedules a separate setTimeout() for each one. Each timer callback simply modifies the DOM for its step without measuring to see if the animation is behind.

This demo site will cause pretty much every modern browser to drop to zero frames-per-second. The total animation, however, will run quite quickly.

In Firefox 52, however, we end up delaying many of the timers due to our yielding. This keeps the browser running at 30fps, but the animation takes much longer to complete:

This is an extreme case that we don’t think reflects the typical behavior on most sites. There are many ways to implement this animation without scheduling hundreds or thousands of simultaneous timers. Its very likely that sites are using these alternate methods to avoid triggering the poor FPS performance caused by this technique.

That being said, we still want to avoid breaking existing sites if we can. This is why we are not enforcing a strict yield after every timer callback. We hope that by allowing a few timer callbacks to run without yielding we can mitigate the impact to these kinds of workloads while still improving performance on sites in general.

What’s Next?

These setTimeout() changes have just hit our release channel with Firefox 52. We will be on the look-out for any compatibility problems in the wild. So far we have only had a single bug report in the four months since this landed in nightly.

If you believe you have a problem on your site in Firefox due to these changes please file a bug and add me to the CC list.

Barring large-scale problems we plan to continue refining this approach. We will likely change our limit on “timers allowed before yielding” to use a time budget approach instead of a fixed number. In addition, the Quantum DOM project will be experimenting with more changes to event queue scheduling in general.

Update (3/30/2018)

NOTE: We implemented a time budget approach to yielding in Firefox 55. By default Firefox will now execute consecutive timers for up to 4ms before forcing a yield.

Patching Resources in Service Workers

2015-10-13T14:30:00+00:00

Consider a web site that uses a service worker to provide offline access. It consists of numerous resources stored in a versioned Cache.

What does this site need to do when its code changes?

It clearly needs to update its cache. Thanks to the service worker life cycle, this is relatively straightforward. As described in Jake Archibald’s Offline Cookbook, the site simply needs to cache.addAll() the new resource in the install event and caches.delete() the old Cache in the activate event:

self.addEventListener('install', function(evt) {
  evt.waitUntil(
    caches.open('v2').then(function(cache) {
      return cache.addAll(resourceList);
    })
  );
});

self.addEventListener('activate', function(evt) {
  evt.waitUntil(caches.delete('v1'));
});

This is nice and simple, but it does have one downside. It requests the entire resource list from the browser’s network stack on each upgrade.

This can be mitigated pretty easily For unchanged files. Simply set the correct cache control headers on the server so you hit the HTTP cache. Or even copy the resource directly from the old v1 cache to the new v2 cache.

That being said, we normally only update when things change. Is there anything we can do to improve the situation for modified resources?

Can we do better?

Consider this demo site (source code). Open it with your devtools network panel visible. It should work in both Firefox and Chrome release channels. (There is an issue with Chrome on windows, though.)

The buttons let you simulate upgrading a cache as the service worker would. Each version of the cache stores two resources; JQuery and Bootstrap. The contents of each resource is shown in a separate div so you can inspect the final loaded resource.

So, to model the typical upgrade process you would click:

Load v1 Resources
Clear All Resources
Load v2 Resources
Clear All REsources
Load v3 Resources

This creates the following network traffic.

However, if you click the load buttons in sequence without clearing, then we can see an optimization at work. So:

Load v1 Resources
Load v2 Resources
Load v3 Resources

Which gives us:

In this case the v2 and v3 network traffic has been reduced by a factor of ten.

What is going on here?

The demo site is using an optimization called delta encoding to request only the changes in each resource. In this (admittedly contrived) case, both JQuery and Bootstrap are only being updated across minor versions, so the changes are quite small.

While the demo is using relatively small updates, delta encoding is still useful for larger changes. For example, sending the gzip’ed differences between JQuery 1.11.3 and 2.1.4 still only requires 8.6KB.

Of course, delta encoding is not a new concept. We use it every day with git and other tools. It was even proposed as an HTTP standard in 2002 in RFC 3229. It never caught on, however, because it requires extensive server resources to implement in a general way. For example, see this article on the CloudFlare blog.

The nice thing about service workers is they let us implement this algorithm in a site-specific way that is tailored to our use case. We determine where it makes sense to use delta encoding and skip it for resources where its not feasible. This lets us use the optimization without dealing with the complications of making it general purpose across all web sites.

Diff’ing and Patching

When I first considered delta encoding, I searched for a good diff/patch algorithm implemented in javascript. At the time I didn’t find much that was suitable. It seemed most libraries were either focused on creating traditional UNIX diff output or wrappers around native code. I needed a patching algorithm solely implemented in javascript, however.

In order for delta encoding to be useful the patching algorithm in the browser must be small. We can’t just use emscripten to compile a C patch program, because the size of the resulting library would dwarf any advantage gained from the delta encoding.

(It occurrs to me now that the projects like js-git might have patching code I could have borrowed, but I didn’t think of it at the time.)

In the end I adapted Colin Percival’s excellent set of bsdiff tools.

At first glance, bsdiff seemed like a good fit. Its an extremely effective diffing tool that works well on both text and binary resources. Whats more, bspatch is a single small C file that I could transcribe to javascript.

Then I ran into bzip. It turns out bsdiff works by creating file segments slightly larger than the original file, but with a large number of zeros for unchanged content. It then internally uses bzip to compress these segments. The result is a compact difference file.

Porting bzip seemed like a daunting task and likely to require a large library.

It occurred to me, however, the browser already knows how to decompress gzip natively. Could we instead strip the internal bzip compression out and just serve the resulting files with gzip encoding?

The answer is yes. The demo site uses exactly this technique.

In fact, if you look closely at the delta encoding network traffic, you will see devtools reports the resulting uncompressed file as being slightly larger than the original resource. This is bsdiff’s internal segment algorithm at work.

The u(ncompressed) bsdiff code is on github as ubsdiff. In addition, I’ve published ubspatch as a separate npm module. Currently the ubsdiff code is only available in C, but it could also be ported to javascript.

Should I Use This in Production

Probably not with this specific code. I wrote a lot of it while my kids were throwing legos at my head.

The technique, however, seems suitable for service worker updates using the install event. The install event runs in parallel with any currently active service worker, so you will not create problems for the current page.

For read-through-caching, though, its less clear. In these cases you will often need to patch the resource on-demand in a fetch event handler. This is problematic because the patching can take a non-trivial amount of time. Since its not streaming yet, it will just block the worker event loop while it runs. If there are additional fetch events waiting to be serviced, this will cause network jank.

Ideally, service workers would allow heavy workloads like patching to be offloaded via a worker. The spec really needs to be extended to allow workers to be accessed within the service worker.

(You could bounce a postMessage() through the fetch event source document to a worker that does the patching and then back, but that seems a bit convoluted to really recommend.)

Frameworks and Tools

Ultimately I think this technique probably needs client-side frameworks and server-side tooling to really shine.

A framework could transparently handle a number of things:

Automatically include currently cached resource versions in outgoing requests.
Dynamically determine if using delta encoding makes sense for any given resource.
Automatically patch differences returned from the server.
Provide integrity checks on the final resource after patching. This is a crucial step for any production system, but not something I included in the prototype here.

Service Workers Are Delightful

At the end of the day, though, I find service workers exciting because they let web developers implement features that had previously been the sole domain of the browser. The browsers are old, creaky, and have lots of constraints. Web sites can break free of these constraints by using service workers.

Service Worker Meeting Highlights

2015-07-28T20:30:00+00:00

Last week folks from Apple, Google, Microsoft, Mozilla, and Samsung met in San Francisco to talk about service workers. The focus was on addressing problems with the current spec and to discuss what new features should be added next.

The minutes for the meeting are online. We covered a lot of ground, though, and these notes are thirty pages long. It seems many people will simply throw them in the “tl;dr” bucket and move on.

The goal of this post is to try to distill the meeting into a few highlights that are a bit more readable and still reflect what we accomplished.

The group came to agreement (more or less) on these items:

Integrating Fetch Event with Other Specs
Fall-through or Foreign Fetch
No-fetch Optimization
Coordinated Updates
Service-Worker-Max-Age Header
Meeting Planning

This list mainly focuses on the decisions that came out of the top level agenda items. There were many other discussions that did not resolve to any immediate decision. In addition, a lot of good work was done addressing many of the open v1 issues. Please see the minutes if you want to delve into these topics.

Integrating Fetch Event with Other Specs

The group decided to investigate and document how the fetch spec should be integrated into pre-existing specs.

Currently service workers are defined in two specs:

The service worker spec defines how to register and message the worker objects. It also defines the life cycle of service workers.
The fetch spec defines how network requests are performed. At a particular point in these steps it calls out to the service worker spec to perform fetch event network interception.

Unfortunately, the majority of the other pre-existing specs do not currently use the fetch spec to perform network requests. Instead they use their own algorithm or no specific algorithm at all.

This is a problem because many of the security checks in the fetch spec require that attributes are set properly on the request. Each spec must set the appropriate Request context and mode.

In addition, its unclear if certain specs should not intercept at all. For example, it seems appcache requests should never produce service worker fetch events, but what about things like CSP violation reports?

These questions are not currently answered by the available specs.

At the meeting last week, however, Google’s Matt Falkenhagen offered to help us at least determine what Chrome currently ships. We plan to examine each network request call site to methodically determine the correct behavior and attributes. We will then document the result in the fetch spec until it can be properly moved integrated into the other specs.

This is great news for Mozilla because the potential security holes here are the main reason we chose not to ship in Firefox 41.

Fall-through or Foreign Fetch

The group decided to pursue a fetch oriented design for communicating with cross-origin service workers.

For a while now Google has been working on an addition to the spec to allow service workers for different origins to communicate with one another. This would support use cases such as:

Offline analytics
Cloud storage APIs
Efficiently sharing fonts

The solution was originally envisioned as an RPC-like API called navigator.connect().

Over time, however, the effort migrated to a system based on FetchEvent. The idea is to permit a service worker to intercept fetch events to its own origin. So, for example, Google could register a service worker that receives fetch events for analytics.js and instantly returns the script from the offline Cache.

In general, we prefer this fetch event based system better for a number of reasons:

Its more “webby” using HTTP requests instead of RPC-like messags.
As a consequence its easy to provide offline support for REST APIs build on top of HTTP verbs like GET and POST.
Its progressive. If a browser does not support this new system, then the requests simply go to the server as they used to.

While there is general agreement with the direction, we still need to work out the details. Google has proposed fall-through fetch, while Mozilla has proposed foreign fetch. They are very similar, however, and we don’t currently anticipate any difficult issues.

No-fetch Optimization

The group decided to provide an API during the install event to explicitly opt-out of fetch events for a particular service worker.

Currently the registration API assumes that a service worker is going to be handling fetch events. You must provide a scope to identify the service worker. If a network request matches that scope, then you are going to get a fetch event. If you don’t actually intend to handle the event, this adds needless delay to network requests.

Many options were discussed, but the final solution we settled on is to provide disableFetch() and enableFetch() methods on the install event.

Coordinated Updates

The group decided that we need to support coordinated updates for sites with multiple service workers.

Currently its difficult to use multiple service workers for the same site. When you update their code, one will always update before the other one creating the potential for bugs.

We need to spec an extension to the API to allow multiple service workers to update together coherently.

Service-Worker-Max-Age Header

The group decided to support the Service-Worker-Max-Age header.

Currently the update algorithm only examines the top level service worker script to determine if there is a new version. Code within imported scripts is not examined. This can make it awkward to trigger service worker updates when one of these dependent scripts has changed.

The Service-Worker-Max-Age header provides a way to opt-out of this behavior by setting a maximum time to run any single version of the service worker.

Meeting Planning

Finally, the group decided to have more frequent face-to-face meetings. The next one will be held at TPAC at the end of October.

Highlighter image courtesy of photosteve101.

Evaluating the Streams API’s Asynchronous Read Function

2015-06-19T18:50:00+00:00

For a while now Google’s Domenic Denicola, Takeshi Yoshino, and others have been working on a new specification for streaming data in the browser. The Streams API is important because it allows large resources to be processed in a memory efficient way. Currently, browser APIs like XMLHttpRequest do not support this kind of processing.

Mozilla is very interested in implementing some kind of streaming data interface. To that end we’ve been evaluating the proposed Streams spec to determine if its the right way forward for Firefox.

In particular, we had a concern about how the proposed read() function was defined to always be asynchronous and return a promise. Given how often data is read() from a stream, it seemed like this might introduce excessive overhead that could not be easily optimized away. To try to address that concern we wrote some rough benchmarks to see how the spec might perform.

TL;DR: The benchmarks suggest that the Streams API’s asynchronous read() will not cause performance problems in practice.

The Concern

Before we describe the benchmarks, let’s discuss what our concern was in a more detail.

The spec currently defines the read() function as returning a promise. When data is available in the stream, then the promise resolves with the data.

So a typical read loop might look like this with the proposed spec:

var reader = stream.getReader();
reader.read().then(function handleChunk(result) {
  if (result.done) {
    return;
  }

  processChunk(result.value);

  return reader.read().then(handleChunk);
});

This API was ultimately chosen after much discussion in order to support certain optimizations.

In contrast, other streaming APIs often provide a synchronous read operation with some way to determine when data is available.

Consider what a read loop using node.js streams looks like:

stream.on('readable', function handleReadable() {
  var chunk = stream.read();
  while (chunk) {
    processChunk(chunk);
    chunk = stream.read();
  }

  stream.on('readable', handleReadable);
});

These loops have a lot in common. They both use an async callback to iteratively process chunks of data. The difference, however, is in how much work they can perform for each async callback.

The node.js streams can completely drain the stream on each async callback. In the Streams API loop, however, there is one async callback per chunk even if there are many chunks already buffered up in memory. In addition, it allocates an additional object each read for the promise.

We were concerned that these additional async callbacks and promise allocations would introduce a noticeable performance penalty.

In order to try to assess if this possibility we wrote a couple benchmarks. These benchmarks are not perfect. The spec is essentially conceptual at this point without a full concrete implementation. In addition, we want to compare to possible implementations. This is difficult to do without fully implementing the spec. Therefore, these benchmarks are very much speculative and may not reflect the final performance. Currently, however, they are the best that we have available.

Micro-Benchmarking

The first benchmark we tried was a micro test. It essentially executed the loops above for different numbers of “buffered chunks”. A version of benchmark.js was then used to repeat the tests and get stable, significant results.

In addition, the micro benchmark was executed using both native and Bluebird promises across a variety platforms and browsers.

The code for the micro benchmark is available on Github. You can also run the micro benchmark yourself.

So, what kind of results did this benchmark produce? First, lets compare native promises to Bluebird promises.

Here we can see that Bluebird promises are currently significantly faster than native promises in this test. This is not terribly surprising as there are known areas for improvement in both Firefox’s and Chrome’s promise implementations. In the long term, though, we expect both browsers’ native promises to be competitive with Bluebird performance.

Based on these results, we’ll just focus on the Bluebird results from now on.

With that in mind, lets see how things look on a desktop platform.

This shows that on both Chrome and Firefox the synchronous read loop achieves greater throughput than the async read loop. In addition, the sync read loop has a shallower slope and does not degrade as quickly as we increase the number of buffered chunks in the pipe.

Now lets look at performance on a Nexus5.

This shows a similar story, although the throughput is greatly reduced (as we would expect for a such a device). The drop off for the async read is significant enough that at 128 chunks in the pipe both Chrome and Firefox require more than 1ms to drain a pipe with the async read. Given 60fps time budgets, this is a significant amount of time.

At this point I’m sure some of you are saying “wait a minute, I thought the TLDR was that the async read was not a problem!” These results certainly do look grim.

Domenic, however, correctly pointed out that streams performance will typically be dominated by source or sink I/O. The micro benchmark does not capture the overall performance of a system using streams. What we really care about is how streams will perform in real systems and not in artificial benchmarks like this.

Approximating a System

So next we attempted to write a macro level benchmark that compares the impact of async read on a system using streams. This was much more difficult. We finally settled on a Rube-Goldberg setup like this:

Here we have a node.js server that responds to an HTTP request by echoing back time stamps in a stream. The browser receives these time stamps using the Fetch Response body stream that has been implemented by Chrome. The time stamps are then individually parsed out and sent back to the node.js server via websocket. The node.js server then compares the time stamps to determine round-trip latency. The total numbers of time stamps are also counted to measure throughput.

The key part of this setup is where the Response body stream provides a buffered chunk of data containing multiple time stamps. A wrapper stream is used to parse the chunk into individual time stamps. Each time stamp is represented as an object. This means that a single chunk from the network-oriented Response body is translated into many smaller chunks. This is similar to the “buffer chunks in a pipe scenario” in the micro benchmark. These smaller chunks are then read using either a sync or async interface.

Switching between these read interfaces at this point gives us the difference we are looking for and lets us compare the impact of sync vs async read on the system.

The code for the macro benchmark is available on Github. You can also run the macro benchmark yourself by checking out the repo and running the node.js server on your local network.

It should be noted, however, this benchmark is not particularly stable. Since the Chrome Fetch Response body stream does not currently support backpressure, the test had to manually implement this in the node.js server to avoid simply swamping the browser. This manual backpressure mechanism then creates a possibility for deadlock with the buffering algorithm within the Response body stream. Its a bit fragile and I did not take the time to fully fix it. In the interests of time I instead restarted the test when this occurred.

For this test we did not vary any settings. Instead we simply measured the throughput across 20 executions and took the mean.

We can see a few things here. First, the Nexus5 achieves about 80% of the throughput of desktop. The main exception is the async read case using native promises which runs much slower. This particular result is not too surprising, however, given the native-vs-Bluebird results above.

Again, since we expect native promises to approach Bluebird performance in the future, we will just ignore the native promise results for now.

For the Bluebird cases it appears that there is not much difference between async read and sync read in this test. Indeed, performing a t-test on the data shows alpha values ranging from 0.16 to 0.82. This suggests that there is not enough statistical evidence to detect a difference between async and sync read.

The data for all of these results can be found in this spreadsheet.

Conclusions

The results from the micro benchmark clearly show that in isolation a synchronous read function is faster than an asynchronous read function for a particular kind of buffered work load. The macro benchmark, however, supports Domenic’s contention that this type of work load does not realistically occur in systems performing I/O.

Benchmarking is hard. It’s especially hard when you’re trying to compare non-existent, potential implementations of a specification. The tests we ran are clearly not perfect here, but they are reasonable approximations of future behavior and do provide some insight. In the absence of better data we must decide how to move forward with the information at hand.

Given these results, we have concluded that the asynchronous read function in the Streams API is acceptable and will likely not be a performance problem.

Thank you to Domenic Denicola for reviewing an earlier draft of this post.

Intent to Implement Streams in Firefox

2015-06-19T18:50:00+00:00

In the next few months I intend to begin implementing the Streams API in the Gecko codebase.

Google has been working on this spec for a while and has shipped a small subset of the API for the fetch Response body. Over the last few months I’ve worked with others at Mozilla and Google to try to evaluate if this spec is suitable for Firefox.

This evaluation resulted in three main concerns that I believe have been addressed.

Async Read

The current spec proposes a read() function that always returns a promise. We had concerns about possible performance problems with forcing an asynchronous callback and creating an additional object on every read.

To investigate this issue we implemented a couple rough benchmarks to try to determine what kind of performance could be expected. The details here are a bit long, so I wrote a separate post describing the async read evaluation.

The end conclusion, however, was the the currently proposed read() should not be a problem in practice.

Algorithms Operating on the Public API

As currently proposed, the Streams spec defines certain algorithms in terms of publicly exposed functions.

For example, pipeTo() is essentially spec’d as:

function doPipe() {
  lastRead = reader.read();
  Promise.all([lastRead, dest.ready]).then(([{ value, done }]) => {
    if (Boolean(done) === true) {
      closeDest();
    } else if (dest.state === 'writable') {
      lastWrite = dest.write(value);
      doPipe();
    }
  });
}

This calls the public .read() function on the source stream’s reader and the public .write() function on the sink stream.

At face value this is a fine thing to do. It enables creating duck typed streams. It also allows “JavaScripty” things like monkey patching these functions to observe the stream.

var origWrite = dest.write;
dest.write = function(value) {
  console.log('Writing: ' + value);
  origWrite(value);
};

Unfortunately, providing this kind of feature makes certain kinds of optimizations in the browser exceptionally hard.

For example, consider if the source stream and sink stream being piped together are both C++ implemented streams. Perhaps the source is a Response.body and the sink is a file stream (which is not currently spec’d).

In this case, the browser should be able to perform the data copying on a separate thread. There is nothing that requires actually interrupting the JavaScript event loop with copying operations.

That is, unless JavaScript monkey patches the .read() or .write() functions. In that case, the browser must round-trip each value copy through the JavaScript thread.

Even if we were to add checking for monkey patching vs unmodified public functions, the checks add complexity and introduce performance penalties themselves.

To avoid these kinds of issues, it’s cleanest if algorithms like pipeTo() are instead spec’d to operate on internal data. Instead of calling .read() they would “read from the internal source”. Instead of calling .write() they would “write to the internal sink”.

While the original design was written in terms of public functions, I believe we have consensus to move to an internal object design.

Transferring Streams Between Threads

Finally, we feel it’s important that the spec supports transferring streams from one thread to another. So for example, a fetch Response could be initiated on the main thread in a window, the body stream passed to a Worker to process the data, and finally streamed to storage.

Again, I believe we have an informal agreement on how to move forward. The thread transfer issue outlines how the stream would be locked on the current thread and conceptually drained as the new thread reads it.

For C++ source streams this may not result in any copying, but instead just moving a handle over behind the scenes. For JavaScript streams, the data would be read as normal and copied across to the new thread.

This generally needs many of the same things required for off-main-thread pipeTo(). For example, in addition to the internal object design mentioned above, the spec also uses a locked reader design which further supports these kinds of optimizations.

Looking Forward

With these concerns in mind I intend to begin implementing Streams in Gecko.

In addition to providing an implementation, I believe this will allow me to be more active in shaping the spec itself. Many parts of the spec are stable, but things are still changing. Work is proceeding on writable streams, byte streams, and transforms. It’s in everyone’s interest to have more browser vendors actively engaged in working with the spec to find issues early.

Shipping code will depend on how things finalize in the spec and the code, of course. My hope, however, is to have an implementation of the fetch Response body stream shipping by the end of the year. This is the same subset of the spec currently shipped by Chrome.

Please let me know if you have any questions or concerns.

Thank you to Domenic Denicola and Andrew Overholt for reviewing an earlier draft of this post.

Service Workers Will Not Ship in Firefox 41

2015-06-18T15:15:00+00:00

In my last post I tried to estimate when Service Workers would ship in Firefox. I was pretty sure it would not make it in 40, but thought 41 was a possibility. It’s a few months later and things are looking clearer.

Unfortunately, Service Workers will not ship in Firefox 41.

While Service Workers are largely feature complete, we’ve had issues with the network interception code. It’s become clear that implementing this feature has introduced a number of security risks. We need to perform a fresh security audit before the code can ship.

This was a difficult decision to make, but we feel it was the right one given the security implications.

That being said, it’s still possible we will ship parts of the Service Worker spec in Firefox 41:

Specifically, push notifications are very close and may make it into the release. If this occurs we will add a preference to disable fetch event while exposing the rest of the Service Worker API. This will allow push-based Service Workers while the network interception goes through its security audit.
In addition, it seems likely that the Cache API will ship in Firefox 41. While this feature is not as useful without the fetch event, it’s a large piece needed to support offline web pages. Getting it released moves us that much closer to full offline support and will let us focus more people on polishing network interception.

As always, we appreciate your support and patience. Please don’t hesitate to contact us if you encounter any problems.

Service Workers in Firefox Nightly

2015-03-24T15:15:00+00:00

I’m pleased to announce that we now recommend normal Nightly builds for testing our implementation of Service Workers. We will not be posting any more custom builds here.

Now that bug 1110814 has landed in mozilla-central, Nightly has roughly the same functionality as the last sw-build. Just enable these preferences in about:config:

Set dom.caches.enabled to true.
Set dom.serviceWorkers.enabled to true.

Please note that on Firefox OS you must enable an additional preference as well. See bug 1125961 for details.

In addition, we’ve decided to move forward with enabling the Service Worker and Cache API preferences by default in non-releases builds. We expect the Cache preference to be enabled in the tree today. The Service Worker preference should be enabled within the next week once bug 931249 is complete.

When Nightly merges to Aurora (Developer Edition), these preferences will also be enabled by default there. They will not, however, ride the trains to Beta or Release yet. We feel we need more time stabilizing the implementation before that can occur.

So, unfortunately, I cannot tell you exactly which Firefox Release will ship with Service Workers yet. It will definitely not be Firefox 39. Its possible Service Workers will ship in Firefox 40, but its more likely to finally be enabled in Firefox 41.

Developer Edition 39, however, will have Cache enabled and will likely also have Service Workers enabled.

Finally, while the code is stabilizing you may see Service Worker registrations and Cache data be deleted when you update the browser. If we find that the data format on disk needs to change we will simply be reseting the relevant storage area in your profile. Once the decision to ship is made any future changes will then properly migrate data without any loss. Again, this only effects Service Worker registrations and data stored in Cache.

As always we appreciate your help testing, reporting bugs, and implementing code.

Initial Cache API Lands in Nightly

2015-03-09T15:30:00+00:00

Its been two busy weeks since the last Service Worker build and a lot has happened. The first version of the Cache API has landed in Nightly along with many other improvements and fixes.

The Cache landing is nice because it was the largest set of patches blocking users from testing directly in Nightly. Finally getting it into the tree brings us much closer to the point where we don’t need these custom builds any more.

We’re not there yet, though. The custom builds will still be needed until the following two issues are fixed:

Cache.put() current does not work. In order to fix this we must integrate Cache with the CrossProcessPipe. These patches have been in the custom builds from the start, but we must complete the work in order for most Service Worker sites to be usable on Nightly. | bug 1110814
Service Worker scripts and their dependencies are not currently saved for offline access. Obviously, we must fix this in order for Service Workers to provide true offline support. This feature is in progress, but unfortunately is not in the custom build yet. | bug 931249

Once these two bugs are fixed we will begin encouraging the community to test with Nightly directly.

This week’s build was updated as of yesterday, March 8:

Firefox Service Worker Builds

This build includes the following feature changes in Nightly:

Cache API bug 940273
FetchDriver channel stalls when Service Worker returns from fetch event too early | bug 1130803
remove Service Worker Cache “prefixMatch” option bug 1130452
ServiceWorkerGlobalScope.close() should throw InvalidAccessError | bug 1131353
ServiceWorkerClients API spec changes bug 1058311
Remove ServiceWorkerGlobalScope.scope bug 1132673
ServiceWorker: client.postMessage should be dispatched to navigator.serviceWorker.onmessage | bug 1136467

It also includes these bug fixes:

navigator.serviceWorker.controller does not track underlying state | bug 1131882
Fix registration persistence in some activation cases bug 1131874
Don’t persist registrations that fail bug 1132141
FetchDriver should check content load policy before proceeding | bug 1139665
Use correct principal for channel which updates ServiceWorker | bug 1137419
Seg Fault when calling cache.matchAll without parameters bug 1138916
Crash in ActorChild::SetFeature bug 1140065
Fix -Winconsistent-missing-override warnings introduced in Cache API | bug 1139603
disallow creating nested workers from ServiceWorker bug 1137398

Finally, a number of testing changes were made:

Replace getServiced() with matchAll() in a couple of ServiceWorker tests | bug 1137477
Various ServiceWorker test fixes bug 1139561
Remove activatingWorker warning in ServiceWorkerManager bug 1139990
Remove a couple of unused test functions on ServiceWorkerContainer | bug 1140120
nice to have a test-interfaces.html for ServiceWorkers bug 1137816

Many thanks to all the contributors:

Please let us know if you find any new issues. Thank you!

That Event Is So Fetch

2015-02-23T15:00:00+00:00

The Service Workers builds have been updated as of yesterday, February 22:

Firefox Service Worker Builds

Notable contributions this week were:

Josh Mathews landed Fetch Event support in Nightly. This is important, of course, because without the Fetch Event you cannot actually intercept any network requests with your Service Worker. | bug 1065216
Catalin Badea landed more of the Service Worker API in Nightly, including the ability to communicate with the Service Worker using postMessage(). | bug 982726
Nikhil Marathe landed some more of his spec implementations to handle unloading documents correctly and to treat activations atomically. | bug 1041340 | bug 1130065
Andrea Marchesini landed fixes for FirefoxOS discovered by the team in Paris. | bug 1133242
Jose Antonio Olivera Ortega contributed a work-in-progress patch to force Service Worker scripts to update when dom.serviceWorkers.test.enabled is set. | bug 1134329
I landed my implementation of the Fetch Request and Response clone() methods. | bug 1073231

As always, please let us know if you run into any problems. Thank you for testing!

A Very Special Valentines Day Build

2015-02-14T19:26:52+00:00

Last week we introduced some custom Firefox builds that include our work-in-progress on Service Workers. The goal of these builds is to enable wider testing of our implementation as it continues to progress.

These builds have been updated today, February 14:

Firefox Service Worker Builds

This week’s build provides a number of improvements:

Andrea Marchesini landed bug 984050 in Nightly implementing peristent Service Worker registrations. Previously registrations would be forgotten once the browser was closed. Obviously, persistent registrations is a key feature necessary to implement offline web apps with Service Workers.
Nikhil Marathe has a patch in bug 1130065 that fixes some of the trickier aspects of activating a Service Worker for a document.
The Paris team has also been investigating using Service Workers on FirefoxOS. With Andrea’s help this work is being moved into the tree and is also included in this build.
As a result, this build now includes a FirefoxOS build for the Flame device based on the v18D firmware.

Also, some patches that were included in last week’s build have landed in the tree for Nightly:

As mentioned above, persistent registrations landed in bug 984050.
Improvements to gecko’s stream infrastructure to support cloning also landed in bug 1100398.

As always, please let us know if you have any questions or run into any problems. Thank you for your assistance in testing this new feature!