(I'm going to write this comment from memory rather than look up all the references I'd need to double-check. This means that it's my memory of technical stuff that happened over the past 20 years. My memory of technical details from 20 years ago isn't perfect, so I'll probably get a few things wrong. I'm also writing it using "we" to refer to groups I was part of at the time -- which in some cases are and in some cases are not groups that I'm part of today.)

The behavior that's being removed here isn't really a "bug". Back in CSS1 and/or CSS2, the spec for floating ::first-letter (or, in CSS1, :first-letter), was much more vague. I think it roughly allowed implementations to do standard inline layout, but said that they had the option of trying to do layout better. Gecko (the engine used in Firefox) was the only browser implementation that took that option.

In particular, Gecko's behavior was to actually use the bounds of the glyph (rather than the font metrics for the whole font) to do layout for a floating first-letter, so that there wouldn't be extra space around it and it would align better. This was a better default behavior, but it was also somewhat less controllable since some of the standard inline layout properties (like line-height) didn't apply.

It also turned out that this better behavior wasn't good enough to really do good typographic first-letter effects. Maybe about a decade after Gecko implemented the glyph-wrapping behavior for floating first-letter, some folks (primarily Dave Cramer) who were interested in doing better initial letters came to the CSS WG and developed (over a period of years, with quite a bit of interaction and discussion in the working group) a new set of CSS properties with a substantial spec (at https://w3c.github.io/csswg-drafts/css-inline/#initial-letter-styling ) to address first-letter typography.

At some point during the progres of that work, one question that came up was whether the spec should continue to have this vague allowance that implementations could try to do something better (as Gecko, and no other browsers, were doing). Given that we knew at this point that the Gecko behavior, while better, wasn't sufficient to do good typography, this seemed like the right thing to do. As one of the Gecko representatives on the CSS WG, I absolutely could have objected on the basis that we *were* doing something better and would like to continue to do so, and such an objection probably would have led to the WG not removing that allowance from the spec. But removing the allowance, and moving towards better interoperability, was the right thing to do, so I supported removing it. (That's also when I commented on and reopened the bug being discussed here.)

That said, it also didn't seem like removing the better behavior from Gecko was the right thing to do until we had implemented the *even better* new spec with the initial-letter-* properties, which would allow Gecko users to see better-quality typographic first-letters in the new way. (Though there's an obvious trade-off there between quality and interoperability. The opinions of standards bodies and implementers for the Web platform have changed a good bit over the past 20 years on how to make such tradeoffs -- generally towards stricter interoperability at the expense of allowing implementations to do "better" things.) So, back when I was working on Gecko, I thought that we should keep it until we'd implemented the new initial-letter-* properties. It seems like the folks currently working on Gecko made the opposite call. But I think both decisions are reasonable -- there's a real tradeoff there (though the inputs into that tradeoff are likely changing over time as well).

So, really, just saying "hey, they fixed a really old bug" isn't that useful a point to make. There's much more history there. (Also, see https://dbaron.org/log/20080515-age-of-bugs which I wrote 14.5 years ago in response to general criticism about the age of bug reports.)

No.

About 600 of them work directly on Firefox.

Correlation does not imply causation. And in this case, it seems like there are pretty good candidates for the common cause. And the article even recognises that - the headline is clickbait.

Sorry, I see nothing about a Mozilla and Microsoft partnership there. Care to be more explicit?

Can you say more about this Mozilla and Microsoft partnership? Thanks.

Not for ever - they are working on a method of doing bridge-based WebRTC which is nevertheless end-to-end secure - see https://datatracker.ietf.org/w... . AIUI, the way it works is that it established point-to-point encrypted tunnels between the endpoints for key distribution so the bridge isn't able to decrypt the data even if it wanted to, and yet, you don't need N->N transmission of streams.

Gerv

WebRTC-based services, in the form of e.g. https://meet.jit.si/, are end-to-end secure and decentralised. Not sure if Windows Phone has any browser which supports WebRTC, though.

web.skype.com lets me log in using Firefox, no problem, so presumably it works there as well.

Gerv

What if "what I want" is to be able to visit the sites that are linking to a YouTube video I'm watching. Today I can't easily do that because YouTube doesn't want me leaving YouTube.

It a load of rubbish from the original author. There's no reason whatsoever that loss of this data would cause problems in IE or Edge. Removing roots from MS's program doesn't happen without human input.

"What I don't understand (and maybe because I haven't looked too hard) is what "Old POS terminals" have to do with Mozilla."

The certificates they are using chain up to publicly-trusted roots, and so are covered by Mozilla's policies. In 20-year hindsight, that was a bad idea, but it was a decision taken a long time ago.

Firefox fixed this issue in Firefox 43, not in 44.0.2. In particular, it was "fixed" in Firefox by updating to a version of libgraphite that did not have the problem, and this happend before the issue was even reported to libgraphite.

Hence no CVE for Firefox 43 or 44, because they were never vunerable, and no CVE for Firefox 42, because it was long-superseded by the time the vulnerability was even reported.

The CVE, if you note, is for Firefox 38 ESR, which _was_ vulnerable until the 38.6.1 release.

Or maybe this is the contest organizers trolling? Because I know for a fact Firefox made serious security improvements in the last year; I reviewed some of those patches.