Firefox 61 [LWN.net]

Firefox 61

Posted Jun 27, 2018 2:35 UTC (Wed) by josh (subscriber, #17465) [Link] (3 responses)

To me, the most notable features in 61 seem like the faster rendering via further Quantum CSS work, and on-by-default support for TLS 1.3.

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 8:56 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

I'm a little bit wary of the enthusiasm for the TLS 1.3 drafts in actual deployed software. Drafts are deliberately incompatible with the finished specification (a mechanism that will be elided from the final RFC explains how to make yourself incompatible) and so these won't interoperate with actual TLS 1.3 implementations, quite purposefully since the final TLS 1.3 could in theory be entirely different (after all we thought this was almost finished in 2016...)

For web browsers the turnover is very fast, I'm sure Firefox 61 will be a vanishingly small proportion of all browsers by Christmas, but I worry that some idiots in the middle will fixate on a particular draft (like 23 or later since that's when the wire format froze more or less) and then manage to ship products that don't work with the actual TLS 1.3 RFC but do work with drafts. And then what do we do?

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 20:21 UTC (Wed) by xnor (guest, #125308) [Link] (1 responses)

What are you talking about? The last draft has been approved months ago. Previous drafts are incompatible and therefore the protocol handshake will fail, and then the application has to fall back to TLS 1.2.
I've been using TLS 1.3 for months now both server- and client-side and I haven't had a single problem, not even when I was mixing different draft versions on both ends long before that.

TLS 1.3 draft 28 (in practice all drafts 23 onwards)

Posted Jun 27, 2018 21:54 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

The current draft, 28, was approved by the Working Group and is now in the RFC Editor's queue. Nevertheless, until it's actually published as an RFC draft 28 remains a _draft_, and retains the language I described e.g. in section 4.2.1.1

ALL draft versions are incompatible, including draft 28, with each other and with a final TLS 1.3, the deliberate intent is that if you "mix different draft versions" you end up with TLS 1.2 (or an earlier version).

If you aren't expecting this, you are probably going to be badly disappointed.

additional technical details regarding "retained display lists"

Posted Jun 27, 2018 7:39 UTC (Wed) by Felix (guest, #36445) [Link] (7 responses)

I'd like to point out two posts which provide some technical background about the "Quantum CSS" improvements:

short/high-level summary:
https://hacks.mozilla.org/2018/06/firefox-61-quantum-of-s...

in-depth blog post:
https://hacks.mozilla.org/2018/06/retained-display-lists/

additional technical details regarding "retained display lists"

Posted Jun 27, 2018 12:08 UTC (Wed) by jpnp (guest, #63341) [Link] (6 responses)

...the median time spent painting is around 3ms when retained display lists are enabled. Once the feature was disabled on April 18th, the paint time jumped up to 4.5ms. That frees up lots of extra time for the browser to spend on running JavaScript, doing layout...

The sad truth. I'd prefer if it meant more life in my battery, or less heat in my laptop, but that's not the way of web developers.

additional technical details regarding "retained display lists"

Posted Jun 27, 2018 20:23 UTC (Wed) by xnor (guest, #125308) [Link] (5 responses)

What are you talking about? That's exactly what the effect is. It no longer pointlessly recreates display lists from scratch but reuses as large parts as possible.

additional technical details regarding "retained display lists"

Posted Jun 28, 2018 11:11 UTC (Thu) by jpnp (guest, #63341) [Link] (4 responses)

I'm sure it's an improvement, and making things more efficient is a "good thing". But my web browser seems to spend a disproportionate amount of time running at 100% CPU, often when I'm not interacting with it at all.

Ten years ago, on a less powerful system I was able to have over 600 tabs open at once, now a fraction of that has my cpu fan constantly whirring. Of course the blame lies not with Mozilla, who have undoubtedly made their browser more efficient over this period, but with web developers delivering websites as complicated JS driven apps which use cpu/power when I'm not actually viewing them to do things which I almost certainly don't want doing -- even those (almost all) which are from my point of view just open to display static content.

I fear that all the competition to bring out faster and faster versions will only be absorbed by websites requiring more and more on the client to deliver content. I doubt my CPU utilisation will go down.

On a positive note, the same release notes talk of the new tabs.hide() interface, which along with tabs.discard() gives developers the API to build extensions which wrangle many open tabs.

additional technical details regarding "retained display lists"

Posted Jun 28, 2018 12:43 UTC (Thu) by nai9Ahz0 (guest, #112673) [Link]

Setting both dom.min_background_timeout_value and dom.min_tracking_background_timeout_value to a high value (e.g. 1000000) helps a bit in getting the CPU usage under control. Some websites do not like this though, for example Google Hangouts with popped out conversations.

additional technical details regarding "retained display lists"

Posted Jun 28, 2018 18:54 UTC (Thu) by xnor (guest, #125308) [Link]

I can open hundred tabs and my CPU usage still is just about 2%. Maybe the "websites" you're visiting are actually web apps, which are typically quite inefficient?
There's a simple ways to remedy this:
1) Block the offending content (or Javascript), or
2) Just stop using the "website".

additional technical details regarding "retained display lists"

Posted Jun 30, 2018 8:14 UTC (Sat) by ehiggs (subscriber, #90713) [Link] (1 responses)

Sounds like Jevon's Paradox:
https://en.wikipedia.org/wiki/Jevons_paradox

"""
n economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises because of increasing demand.[1] The Jevons paradox is perhaps the most widely known paradox in environmental economics.[2] However, governments and environmentalists generally assume that efficiency gains will lower resource consumption, ignoring the possibility of the paradox arising.
"""

As browsers become more efficient, then web developers see that they can afford to do more work and then they end up using more resources in aggregate.

additional technical details regarding "retained display lists"

Posted Jul 2, 2018 6:41 UTC (Mon) by k8to (guest, #15413) [Link]

I'm sure this is part of it.

But I think it's much more that browsers have added all sorts of things (web workers etc) to enable persistently executing pages, and have not spent much time in features to limit resource waste of behalf of the user.

More or less it seems like innovation in web development is driven by making convenient features for developers, and as a bit of an afterthought, improving security. Making things more comprehensible and usable for users is not really on the list. If I could see the potential problems with resource theft 20 years ago, surely someone within the world of the w3c, microsoft, google, mozilla etc could have spotted it in the time between then and now, but here we are today with cryptojacking as a thing that happens.

Firefox 61

Posted Jun 27, 2018 19:24 UTC (Wed) by another_lwn_reader (guest, #125306) [Link] (3 responses)

Once again the patch list is alarming.

Firefox 61

Posted Jun 28, 2018 3:39 UTC (Thu) by sml (guest, #75391) [Link] (2 responses)

It's amazing that of those 18 CVEs, just using a memory safe language would avoid at least 11 of them. Servo can't come fast enough!

Firefox 61

Posted Jun 28, 2018 15:34 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Isn't this kind of thing a major reason why Mozilla is developing Rust?

Firefox 61

Posted Jul 2, 2018 6:42 UTC (Mon) by k8to (guest, #15413) [Link]

Servo being one of the pieces Mozilla is implementing in rust.