Brotli in Browsers

Last month I mentioned Brotli for Nginx. On the client side, Firefox is aiming to add support for Brotli in version 44:

If all goes well in testing, Firefox 44 (ETA January 2016) will negotiate brotli as a content-encoding for https resources. The negotiation will be done in the usual way via the Accept-Encoding request header and the token “br”. Servers that wish to encode a response with brotli can do so by adding “br” to the Content-Encoding response header. Firefox won’t decode brotli outside of https – so make sure to use the HTTP content negotiation framework instead of doing user agent sniffing.

Chrome has Brotli support listed as “in development”. I didn’t see any indication of a current timeline for it showing up in a release version.


Chrome 47 has support for mediaDevices.enumerateDevices():

Modern browsers make it possible to select input and output devices including cameras, microphones and speakers.

For example:
– On a phone, select the front or rear-facing camera.
– On a laptop, choose the internal speakers or a speaker connected by Bluetooth.
– For a video chat, choose internal or external microphone or camera.

This has been available in Firefox since version 39 and is part of the W3C “Media Capture and Streams” draft.

I can see this getting lots of play in the “native vs. web” arguments.

Chrome and Older Mac OS X

Google announced that Chrome is ending support for older versions of Windows and Mac OS X:

Today, we’re announcing the end of Chrome’s support for Windows XP, as well as Windows Vista, and Mac OS X 10.6, 10.7, and 10.8, since these platforms are no longer actively supported by Microsoft and Apple. Starting April 2016, Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

Dropping Windows XP support isn’t a surprise, and even Windows Vista is now 9 years old.

What I didn’t see coming was how quickly they dropped support for Mac OS X releases. I’ve got an older Mac system that can’t be updated past 10.7, but it runs fine and still gets reasonable use. Then there is 10.8, which is only 3 years old. That would be the equivalent of dropping support for Windows 8 ( and Windows Server 2012 ).

Firefox 42 still supports Windows XP and Mac OS X 10.6. Looks like it will become the browser of choice for older systems.

Firefox Desperate To Mimic Chrome, Even Their Mistakes

Recently Firefox has been pushing a more aggressive upgrade schedule. There is little doubt that they are feeling the pressure from Google Chrome, which is becoming increasingly popular and has an aggressive upgrade cycle as well.

In the last year Chrome has become nearly as popular as Firefox. Many of the recent changes with Firefox, like the shorter release cycles, make it look like it is trying to play catch up with Chrome. Perhaps desperately so. Unfortunately with release of Firefox 7 it appears they are also desperate to copy the same mistakes Chrome has made.

It is no secret that I really don’t like the way Chrome broke copy and paste in the URL field. That was a horrible decision that irritates me on an almost daily basis. When I select something to be copied I expect to have an exact copy of what was selected, altering that under the hood completely breaks the concept of copy and paste.

So guess what new “feature” was added to Firefox 7? You got it:

The ‘http://’ URL prefix is now hidden by default

And it behaves in exactly the same broken way that Chrome does.

To the Mozilla team: look, I understand that you’re concerned about losing market share to Chrome, but please, please, please don’t mimic their mistakes. Now in order to copy and paste the URL properly I have to copy everything but the first character of the hostname, then manually type in that first character then paste in the remainder. Absolutely horrible. This is one feature of Chrome that no one should ever copy, and I’d be thrilled to see it removed from Chrome as well.

If you want to no longer show ‘http://’ in the URL field, fine, but please stop breaking copy and paste.

UPDATE: Turns out Firefox has an option for disabling this “feature” ( kudos to @ozh ):

  • Enter about:config in the URL field
  • Filter on browser.urlbar.trimURLs
  • Set the value for browser.urlbar.trimURLs to false

Not great that this is on by default, but at least there is an easy way to turn it off. Now, if only it were that easy to turn off this “feature” in Chrome.

Caching and Processing 2TB Mozilla Crash Reports

Mozilla processes TBs of Firefox crash reports daily using HBase, Hadoop, Python and Thrift protocol. The project is called Socorro, a system for collecting, processing, and displaying crash reports from clients. Today the Socorro application stores about 2.6 million crash reports per day. During peak traffic, it receives about 2.5K crashes per minute.

via Caching and Processing 2TB Mozilla Crash Reports in memory with Hazelcast

A peak of 40 crash reports per second and an average around 30 per second! I wonder what the distribution looks like for installs sending in crash reports. Are the majority of the reports coming in from a small portion of users or is it more spread out across the entire install base?


Plenty of talk today about Eric Butler and Firesheep. Remember the mid-90s when the Security Administrator Tool for Analyzing Networks (SATAN) brought down the entire Internet because anyone could down load it and run it against servers? Yeah, didn’t happen.

Hopefully all of this discussion about the potential implications of Firesheep will cause people to take a fresh look at the security precautions they use on their site.

CSS Border Radius Percentages and Elliptical Borders

When using CSS border radius I’ve always specified the radius in pixels (px), something like this:

.round-box {
    border-radius: 5px;
    -moz-border-radius: 5px;
    -webkit-border-radius: 5px;

This got me to wondering, does it support percentages as well? So I tried this:

.round-box {
    border-radius: 5%;
    -moz-border-radius: 5%;
    -webkit-border-radius: 5%;

This worked in Firefox 3.6 but not in Chrome. Some searching around revealed the Mozilla -moz-border-radius page. For border radius it specifically mentions that it supports length units as well as percentages:

A percentage, relative to the width of the box (the percentage is relative to the width even when specifying the radius for a height).

That page also mentioned support for elliptical borders. To do that you add another radius value separated by a slash:

.round-box {
    border-radius: 15px / 50px;
    -moz-border-radius: 15px / 50px;
    -webkit-border-radius: 15px / 50px;

The elliptical border worked on Chrome as well. If you bend this tight enough you can get pretty close to a circle.

I wanted Internet Explorer to add support for border radius before; now that I’ve got even more radius toys to play with I’m practically begging. I’m sorry Internet Explorer users but I’m tired of various border hacks when there are simple and clean CSS methods available.

Browser Stats and Five Years of Firefox

There’s been a lot of talk about Firefox turning 5 years old today. Seems like a good time to take a look at web browser market share. One place for this data is the Global Stats page for

Top 5 Browers

Top 5 Browsers, Bar Chart

Internet Explorer has 57.15%, Firefox 32.03% and then a virtual three way tie between Chrome (4.46%), Safari (3.58%), and Opera (2%). Here’s the bart chart version of this graph:

Top 5 Browsers, Line Chart

Browser Versions

Browser Versions, Line Chart

IE 7 at 22.73%, IE 8 at 19.46%, Firefox 3.5 at 19.32%, IE 6 at 14.94% (Ug!), Firefox 3.0 at 11.22%, Safari 4.0 at 3% and Firefox 2.0 at 1.28%. Everything else is below 1%. Here’s the bar chart version:

Browser Versions, Bar Chart

The good news is that IE 7, IE 8 and Firefox 3.0+ accounts for 72% of the browser market. The bad news is that IE 6 is still holding on at nearly 15%.

It would be great it other stats services like Google Analytics and Quantcast offered this view on the global browser market. Matt posted some browser stats for, which gets a pretty wide audience.

The only real browser stats that matter of course are the ones for your own site. Here’s the browser stats for (from Google Analytics):

Browser Stats -

Firefox at 58.34%, IE at 19.86%, Safari at 10.70%, and Chrome at 6.92%. The really good news is that IE 6 accounts for less than 4%. Here’s the breakdown for operating systems:

Operating System - visitors

Windows at 70.75%, Mac at 20.94%, and Linux at 7%. Out of the Windows users XP accounts for 65.33%, Vista 27.59%, NT (Seriously?) 4.84%, and Server 2003 at 1.52%. That’s a lot higher percentage for Mac and Linux than StatCounter Global Stats, which isn’t too surprising considering my blog posts skew more towards Mac and open source topics.

XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?

A recent Think Vitamin article, The Definitive Guide to GET vs POST, mentioned something that I hadn’t seen before about XMLHttpRequest (XHR). Their Rule #4 states:

When using XMLHttpRequest, browsers implement POST as a two-step process (sending the headers first and then the data). This means that GET requests are more responsive – something you need in AJAX environments.

The claim is that even the smallest XHR will be sent using two packets if the request is done over HTTP POST instead of HTTP GET. I don’t remember ever having heard this claim before.

Let me first say that performance issues for POST vs. GET probably shouldn’t be your top factor for deciding which one to use. Make sure that you understand the implications of each and pick the right method for your request. For most people I suspect the biggest factor will involve caching, not performance. I was going to leave a comment on the article about this, but Simon beat me to it.

I wasn’t the only one who wanted to find out more about XHR POST using multiple packets. Fortunately someone else already asked that question and the author replied:

2. My claim is based on research done by Iain Lamb, cofounder of the Oddpost webmail startup that was acquired by Yahoo! and eventually became the basis for the all-new Yahoo! Mail.

His research showed “rather baffling finding: POST requests, made via the XMLHTTP object, send header and body data in separate tcp/ip packets [and therefore,] xmlhttp GET performs better when sending small amounts of data than an xmlhttp POST.”

That is why Yahoo includes the use of GET instead of POST as one of their high performance speed optimisation rules.

Simon Willison did some looking around and found more links for this. It was mentioned here and here, so it looks like Iain Lamb did do this research, even though I couldn’t find a first person account of it. This was enough information to make me curious, but not enough to answer all of my questions. It was time to run some tests of my own.

So I updated my install of Wireshark on Windows XP, turned off all of the packet reassembly options for HTTP decoding and started testing browsers. My very simple XHR POST test page looked like this:

<button type="button" onclick="$.post('hello.txt', {name: 'Joseph'})">XHR POST</button>
<script src=""></script>

When the button is clicked an XHR POST request is made to hello.txt with the name=Joseph for a tiny amount of data. The domain I tested on sent along some cookies as well, but still left enough room for the tiny POST payload to fit in a single TCP packet.

Here are the results of the tests that I ran:

  • IE 6 – 2 packets
  • IE 7 – 2 packets
  • IE 8 – 2 packets
  • Firefox 3.0.13 – 1 packet
  • Firefox 3.5.2 – 1 packet
  • Opera 9.27 – 2 packets
  • Safari 4.0.3 – 2 packets
  • Chrome – 2 packets

The short version of this is pretty easy to see, all of the browsers except for Firefox will use at least 2 packets for an XHR done over HTTP POST. When I saw that Safari sent 2 packets I figured that Chrome would as well, but I tested it anyway just to make sure.

I looked at the data size of each packet in IE 6; the first packet had 575 bytes of data and the second packet had 11 bytes of data. This lined up with the POST request which indicated that the content length was 11 bytes. The second packet consisted only of the POST data. Because Firefox sent less data in the user-agent string I increased the POST data so that it would exceed the combined total of the two IE packets to make sure I wasn’t running into any odd packet fragmentation. The second packet in Opera, Safari and Chrome was also only the 11 bytes of POST data.

If this were Myth Busters I’d call this myth confirmed. While it is true that not ALL browsers will always use two packets, it appears that the two packet process is the rule, not the exception. And with IE still the most widely used browser it’s very likely that a large portion of your users fall into the two packet category. If on the other hand 95% of your users happen to be using Firefox, then sure, you can skip thinking about this.