News for hackers. Stuff that matters.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by mbell on Thursday April 20, 2017 @03:15PM (#14159882)
> It's just Firefox. Low importance.

Well, the reality is that it is low importance. Firefox is down to ~2.5% of our traffic, Firefox is bleeding users badly.

It's also not always a simple fix. In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397

So it tends to come down to whether or not it's worth carrying a bunch of technical debt to support a dying browser, not a simple choice and not a matter of sticking to web standards.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @04:53PM (#14160759)
> In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397

In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior, because it makes more sense. https://github.com/whatwg/html/issues/1813

Re:JavaScript performance, WebAssembly, and Shared Memory in... by mbell on Thursday April 20, 2017 @11:31PM (#14162907)
> In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior

The problem in FF isn't that they don't perform layout in the hidden iframe, it's that `getComputedStyle` returns `null`, which happens to be a side effect of not performing layout in Gecko.

If you read through the various related issues in your link I think you'll find that they are moving to standardize on not performing layout in hidden iframes, but `getComputedStyle` returning `null` is still a bug that Gecko intends to fix.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by hutzlibu on Thursday April 20, 2017 @04:41PM (#14160645)
"to support a dying browser"

Wow, this is the first time I read FF being described as a "dying browser".

Even though I don't think so and other sources https://www.netmarketshare.com/browser-market-share.aspx?qpr... say about 12% market share, the fact alone that someone describes it like that, is very sad ...

Re:JavaScript performance, WebAssembly, and Shared Memory in... by mbell on Thursday April 20, 2017 @11:43PM (#14162957)
> say about 12% market share

12% of desktop, ~5-6% of total. 3 years ago it was ~18% of total, there is certainly a consistent downward trend in usage.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by hutzlibu on Friday April 21, 2017 @04:36AM (#14163929)
No doubt about the down thing, I also rarely use FF nowdays, but a downtrend is a different thing from "dying". Plus, I am optimistic about servo ...
Re:JavaScript performance, WebAssembly, and Shared Memory in... by gnaritas on Thursday April 20, 2017 @06:48PM (#14161588)
It used to be much higher than 12%, so it is actually a dying browser.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by hashhar on Thursday April 20, 2017 @06:27PM (#14161460)
How is that a bug when they say that's what the spec says. Also, both Edge and WebKit are going to adopt that behaviour since it makes sense.

I think there's one more reason people see less of Firefox. I know a LOT of people who have set their user agent string to Chrome to stop the idiotic banners on websites telling me to use Chrome even through the website works perfectly on FF. I hate it even more when websites simply won't allow me to load the page when I'm on FF.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by Vinnl on Friday April 21, 2017 @03:15AM (#14163660)
> In our current code base we have more workarounds for FF bugs than any other browser

This can have several reasons. The one you're aiming at, "Firefox has more defects/divergences from the standards", is probably true to some extent. Another, also likely true, reason, is that your code base is dogfooded in Chrome, and hence, defects/divergences there are less likely to be noticed since they appear to be the standard/correct behaviour.