Firefox version 132.0 is now available [LWN.net]

Mozilla has announced the release of a new version of Firefox. This version has the usual mix of security fixes and new features, as well as a handful of deprecations. The release removes support for HTTP/2 Push, but adds hardware acceleration for SVGs, support for wide color gamuts on more platforms, and restores support for remote debugging via USB.

to post comments

feature removal?

Posted Oct 30, 2024 6:52 UTC (Wed) by aviallon (subscriber, #157205) [Link] (9 responses)

Why was HTTP/2 Push support removed? Is it fundamentally broken or barely used?

feature removal?

Posted Oct 30, 2024 7:46 UTC (Wed) by intelfx (subscriber, #130118) [Link] (2 responses)

Probably because that’s what Google overlords did.

feature removal?

Posted Nov 3, 2024 7:01 UTC (Sun) by Ranguvar (subscriber, #56734) [Link] (1 responses)

Please don't clog comments with simple speculation. Help preserve the signal-to-noise ratio by considering whether you are adding something informative or insightful before posting. Thank you.

feature removal?

Posted Nov 3, 2024 9:54 UTC (Sun) by intelfx (subscriber, #130118) [Link]

There is a signal in my comment, regardless of whether you approve of it. So: yes and yes, respectively.

feature removal?

Posted Oct 30, 2024 8:14 UTC (Wed) by andrewsh (subscriber, #71043) [Link]

A bit of both.

feature removal?

Posted Oct 30, 2024 8:19 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

It is fundamentally broken in that it would require a complete rebuild of web servers from the ground up with a new architecture that isn't based around request/response.

feature removal?

Posted Oct 30, 2024 10:58 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

It is not fundamentally broken but it fundamentally changes how http works (flow directionality) and invalidates decades of investments in the http infrastructure. So it better deliver something worth upending several decades of investments in this infrastructure.
But its main use case has always been garbageware, delivering ads a bit faster without web client requests (remember that HTTP/2 was heavily influenced by Google and Google makes money with ads). However it turns out the advertising overlords do not need http push to thoroughly spam the web, and there is no other compelling use case for the feature. So it is quietly being removed.

feature removal?

Posted Oct 30, 2024 8:24 UTC (Wed) by TheGopher (subscriber, #59256) [Link]

Clients do a lot of cacheing, so push would often push assets that client already had in the cache leading to a slower experience than without push from what I understand.
Push is conceptually only useful in specific cases where you can be very sure that the client doesn't have the resources in question in their cache.

feature removal?

Posted Oct 30, 2024 10:54 UTC (Wed) by excors (subscriber, #95769) [Link]

The reasoning in https://bugzilla.mozilla.org/show_bug.cgi?id=1915848 :

> Recently, we've started seeing some issues that are exclusively related to us supporting HTTP/2 push - See bug 1915830 for a list of such issues, as well as other known bugs in our implementation. It also caused an incident in bug 1909271 when we tried to ship Extensible Prioritization Scheme for HTTP/2.

Some of the linked issues are server bugs ("The JS file pushed by the server has different headers than the one returned by an actual request"; one server that illegally sends uppercase header names in pushes), some are browser bugs (assertion failures etc).

Chrome removed support in 2020 because: https://groups.google.com/a/chromium.org/g/blink-dev/c/K3...

> Almost five and a half years after the publication of the HTTP/2 RFC, server push is still extremely rarely used. Over the past 28 days, 99.95% of HTTP/2 connections created by Chrome never received a pushed stream [...] On top of this, less than 40% of received pushes are used, down from 63.51% two years ago. The rest are invalid, never get matched to a request, or already in cache.

> Akamai publicly shared two studies showing that push over HTTP/2 either does not change performance or improves performance marginally when used with certain restrictions [...] a large experiment done by Chrome to measure the effect of server push on page load latency when using HTTP/2 showed that push increases latency at the long tail

It sounds like it's simply a failed experiment - it was meant to provide significant latency benefits, and it didn't, so now it's a useless feature with compatibility issues and implementation complexity costs. Other features like HTTP 103 Early Hints and <link rel="preload"> can be used instead to get most of the latency benefits without so many problems (because they're just hints for the browser to make some perfectly normal requests and cache the responses).

feature removal?

Posted Oct 31, 2024 18:20 UTC (Thu) by nomaxx117 (guest, #169603) [Link]

A little from column A, a little from column B.

The idea behind it was to allow servers to push files to clients which the servers suspected the clients may need. This was a mistake, as quite often a server would just push down something which the client already had, and when you stop doing server push for cacheable items the value quickly drops to almost nothing.

Early hints ended up being a better approach, where the server can push to clients a signal that the client should probably start fetching a resource which the server thinks it will need. This allows data to still get prefetched, but the client can save the bandwidth for other things if the data is already cached. The extra round trip added here doesn't matter too much in practice.

Early hints and server push were both only really implemented by CDNs, because these are kinda weird HTTP features that break most developers' mental models (and also because they were odd enough that most servers didn't implement them), and the CDNs largely stopped using server push anyways once early hints came out.

So, in a nutshell, the concept of server push was broken, and nobody used it.