Chrome 45 Regression Bug: MP3 audio seek stopped working

It’s been about 10 days since Chrome 45 (45.0.2454.85) was released and I really don’t know how come no one has noticed such a substantial bug, influencing millions of users of major and minor sites – virtually every site that provides playable audio via the HTML5 <audio /> tag.

HTTP supports the idea of “seeking”: instead of fetching a whole file/resource from a server, the browser can send a request for a partial range of bytes, get them from the server and display/play/show partial content. This is very useful for large files, mainly ones that provide audio and video features.

The latest versions of all major browsers including Firefox, IE 11 and Edge support this. You can jump to an advanced point of an audio file (using the progress bar on the <audio /> element, for instance), and since the browser already knows the map of the file (MP3 frames), usually by reading its relatively short header, it knows what position of the content to ask the server for. The server then starts streaming from this position onwards, the browser plays almost immediately, and everyone’s happy.

This has also worked in Chrome up until its previous stable version: 44.0.2403.157. The latest version, released about 10 days ago, has broken it.

This is the behaviour now – I’m seeking to an advanced position in a 52.5MB podcast MP3 file and in the Dev Tools’ Network tab you can see that audio is not being played while the browser is downloading all those megabytes, and once it reached a certain point, audio starts playing (while the browser continues to receive a stream of more audio). Sorry for not having a responsive version of this animated GIF:

The Chromium dev team has been contacted, and as for the time of this writing they forecast a solution in the next-next major version of Chromium, 47. Given the time difference we see between Chromium and Chrome releases, we’re talking about a December time frame. That means about 3 months of this severe regression bug staying around.

The existence of this bug means:

1. Downgraded experience for Internet users all over the world, as people now can’t fast-forward/seek to a specific position (this is much more noticeable in large audio files, like podcasts, and with lower Internet bandwidth).
2. Increased data usage costs, for those who pay for bandwidth usage.
3. Increased data transfer costs for web server hosting.

I guess we all need to be louder, approaching the Chromium team and urging them to issue a hotfix ASAP.
I understand that being on the bleeding edge (“help move the web forward” is in Chromium’s slogan) is prime, and that’s the cost we pay, as the alternative would be the known Internet Explorer saga. But we should also urge Google and the Chromium + Chrome teams to fix this issue, which has severe experience and monetary implications on everyone.