JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge
blogs.windows.com
blogs.windows.com
Also, I am not sure if it is Google breaking standards or if some feature not interpreted correctly in Edge but, Gmail still has some bugs on Edge (e.g., keyboard shortcut to add label doesn't automatically get the textbox in focus. In previous version, the text would be printed outside the box)
I hope more sites test on Edge and not just on Chrome.
Congrats to the team! Hope to see Edge decouple from Windows releases soon (as announced during Windows 10 launch)!
"Look for your friends, but trust not to hope. It has forsaken these lands."
Seriously. I use Firefox as my main browser and I'm at the point where I'm surprised if anyone tests anything in anything except Chrome, or if they even realize such test-targets exist at all.
Standard response to bug-reports? "Just use Chrome. Works for me!", "It's just Firefox. Low importance." Etc.
From the glory days of web-standards following IE's demise, this profession has sunk gutter low.
This has been a meme for years now. I remember John Resig suggesting this in 2013—ironically, right before the Blink fork that ended mainline WebKit dominance.
I don't think this is so self-evidently awful. There are a number of big open-source projects in this sort of position, like git, TeX, linux, GHC.
What is special about browsers that we need multiple competing implementations of the standard?
I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.
Mercurial has a more sane way of referring to commits and traversing the history. They now also have different kinds of branching models. You can even maintain multiple checkouts of a repo using a single clone which is great and saves me from having to checkout branches when I want to work on another feature. (Imagine checking out 3.5 mn files each time you wanted to change branches).
In, my opinion, Mercurial scales better but suffers from the unintuitive names and lack of enough people talking about it.
Then you live in a very small bubble.
What could happen with Chrome if they were the only ones on the market, I wonder.
- Play Store website threw you out if you were using Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=1131601
- Gmail delivered an inferior mobile version to Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=668275
- Actually, Google fucks with Firefox on Android all the time https://bugzilla.mozilla.org/show_bug.cgi?id=668288
- Inbox is still Chrome only
- Youtube refused to serve webm to Firefox for a while | https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
Is that enough for now?
Google is no better than old Microsoft/IE team often. But hey, since you get a shiny browser that implements non standard things, it's okay, right?
Even with the NaCL thing I was able to find and implementation [1] of it that was under a open source license when I was trying to find a NaCl spec. NaCl existed because webassembly didn't, Google wanted other browsers to implement it.
Bugs happens, Technologies don't get adopted; Google is made of people and mistakes happen. Your disingenuous crying of anti-competitive wolf dilutes real claims of anti-competition.
[1] - https://chromium.googlesource.com/native_client/src/native_c...
The problem with this is that Google solicited feedback on Pepper on the plugin-futures mailing list early on. The other browser vendors correctly pointed out that Pepper was unnecessary. Google completely ignored the feedback and did it anyway. Years later, it is obvious that the unanimous consensus of the other browser vendors was right. PNaCl is dead, and Web Assembly uses the Web APIs instead of Pepper, which is precisely what everyone else had advocated early on.
The lack of adoption of PNaCl is Google's problem. As is obvious with Web Assembly, nobody has any problem with adding a portable low-level IR to the browser. The biggest problem was the insistence on Pepper. If they had listened to feedback, maybe we would have had Web Assembly much sooner.
Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.
I hate microsoft but I still don't give them flak for not releasing Linux versions of office and excel. They are allowed to not do that. Where it steps into anti-competitive is when they start breaking other's people things or maliciously manipulating standards. Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
It sure is when combined with Google releasing NaCl-based software, such as Google Earth.
> Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Not with Dart, which followed a very similar trajectory (see my other comments). Not with -webkit prefixes. Etc. etc.
> Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
I was unaware even of the existence of a web based version of Earth. The last time I used Google earth was as a desktop client. That was back when I worked in the Air Force Weather Wing almost a year ago. Have they done away with the desktop client?
Starting over with whether or not this is anticompetitive; who are they repressing by giving away free software that runs on other free software? Does this software need to be used?
This all seems to hinge around this part of what you are saying:
> When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
The option to lose users here is huge. How is this different than microsoft making excel and only supporting it on windows? I choose not to use excel at least in part because it doesn't run on any platform I care to use. I feel I should clarify here, I don't condone this obnoxious behavior from microsoft or Google. I think it is wrong from the stance that all software should inter-operate smoothly and be open source, but it doesn't seem illegal or even unethical.
The answer for a users to both Earth and excel seems to be to use some other competing software. For mapping software something like openstreetmap or even some other Google software like Google maps (or even a pay for solution). For spreadsheets I use libreoffice.
Even if this is anti-competitive it seems so minor that it dilutes the meaning of the term. Lumping this in with things like the Dr DOS fiasco just doesn't seem right. For reference in the Dr DOS times there was a DOS competitor to microsoft's DOS. Dr DOS was a relatively bug free DOS and it worked fine with windows until the 3.0 release (I think). Until this specific version/patch started intermittently causing windows to not run if Dr DOS was detected even though it was advertised as working. The end result was Dr DOS being run out of business because it looked like a bug in Dr DOS and sometime ms even claimed such. The Dr DOS team was very overtly fucked by ms.
Nothing about most of the things brought up in this thread seems overt. No money is being paid for web browsers or this mapping software. Having users takes significant effort to monetize. It seems detached from web standards in any direct way (I agree it indirectly relates to webassembly, but not in a way that seems legally relevant). Most of it seems like engineers being engineers and fixing their own little slice of the world and hoping everyone works with their stuff because they don't want to change. Shortsighted and imperfect just like most humans.
Thank you for taking the time to explain (and listen) to me in a rational and level headed way. I won't be checking my messages here again until I start another build or boring process tomorrow. Have an upvote.
http://i.imgur.com/FDM5DQ9.png
k
You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
>when they start breaking other's people things
They are! They actually are! These bugs I listed aren't "bad engineering". They're "When UserAgent is detected send shitty version". In what world is that not deliberately breaking people's things? Users access Inbox on Firefox, see that their friends on chrome that sent him the link can actually access it, they're not going to blame Google, they're going to say that Firefox is a piece of crap and dump it.
> maliciously manipulating standards.
chrome.* javascript APIs
Bluetooth API
FileSystem API
-webkit CSS prefixes
not manipulating standards, just implementing half assed things on their side of things and leaving the blame on other browser manufacturers when they don't implement them.
>They didn't force it on anyone else.
"Company with 50% of desktop browser share and 80% of mobile browser share only unilaterally did something non standard and screwed everyone over. But that's not forcing everyone's hand I swear, they're only the biggest players on the market."
k
You know, when pcwalton keeps proving you wrong over and over again, you might want to rethink your opinions. It's not as if he knew what he's talking about or anything, right? :>
If you must pick an example of them breaking stuff, please pick one that they didn't already apologize and fix.
> http://i.imgur.com/FDM5DQ9.png
My mistake on confusing google earth with google maps, that is an important point that issue. It does suck that doesn't work on firefox, but no one is forcing any one to do anything. Its not like you paid for any of this, or there is some law that says companies have to give stuff away for free.
> You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
I am not reversing my stance or saying anything self contradictory. I am attempting to define nuanced boundaries around some who would rather bludgeon things into a simple categories whether or not it fits. So far all I hear are complaints about company giving away huge amounts of value for free, but isn't doing it the way you (or I) want.
I never said Google was paragon of anything and I admitted they could do better (I really do wish they would do better), the only line I am taking is that their behavior is not "anti-competitive", which is not a high bar. Which has not been disproved or this case even rationally approached. I am open to having my mind changed, but I would need well thought out discourse and evidence to change it.
If you respond again so thoughtlessly or with such poor grammar I will not be responding again.
...Okay then ? ¯\_(ツ)_/¯
It's not as if we were having a meaningful discussion anyways, each of us camping on his positions.
You... Clearly just want me to agree with you without applying any critical thought of my own. You implicitly my experience, personal and professional, while presuming your stance to be the only valid one on a subjective topic. That is not how you have a constructive conversation, goodbye.
Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?
I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.
A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
No, because:
1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.
2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.
3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.
> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
The FUD is strong...
If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument?
> rationalize it with some technical bullshit.
If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}.
Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)
They don't have to be free of security vulnerabilities either, but it would be very nice. What's your point?
As far as making money off of their own software written in Rust, that advantage is actually stronger if they convince everyone else Rust is stupid and not worth their time.
Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.
When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.
Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.
OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)
> everyone now has an incentive to refactor it into something nice.
My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.
Do you honestly think Google would be likely to collaborate on that?
Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.
> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?
Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
See: the Linux kernel.
The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!
> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
No, the organization that didn't like the change would fork the project. This already happened with WebKit!
> See: the Linux kernel.
Linux gets forked over and over and over again, every time some organization wants to ship a device running it.
Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)
It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)
It gives the incentive to create a black market.
Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.
What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?
Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.
Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.
For the old IE, Firefox happened (and other as well).
My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?
IE did not force anyone doing anything, even if it had a de facto monopoly, therefore Firefox was created, because people chose to.
In this scenario I'm discussing it would not be allowed to create a Firefox, because everyone was forced to use Chrome, hence a black market is created.
I would not, however, wish it to be the only thing available.
The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening.
The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.
HTML is supposed to be an actual standard for interchange of hypertext.
Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.
> What is special about browsers
Nothing. We need multiple implementations of all software that is relied upon for anything remotely important. It still amazes me that so many businesses critically depend on something that is only available from one source. Without a second source[2], the business lives or dies at the whim of the company they depend on.
[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....
While a web monoculture isn't ideal, it's rational that people might have differing comfort levels between an OS-tied, closed-source project actively used to undermine the web, and an OS-agnostic, overwhelmingly open-source project that has been a principal contributor to the web moving forward (and arguably delayed or prevented the wholesale app-ification of the industry).
I want to be cynical about Google and Chrome. But thus far I have absolutely nothing to actually criticize them on. They literally have kept the web alive, and their attempts to try to clear up the advertising market is yet another example. Or just be cynical about it while everyone migrates to apps.
NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others.
Anything else?
Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless.
And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM.
NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place.
A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.
Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree.
> Dart actively ignored outside feedback
Again, on the language or just having the vm in browsers?
There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.
Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough.
Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.
That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.
Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act.
The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]:
>> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform."
[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
[2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/...
>Yes, we did.
My phrasing wasn't as clear as I thought - what I meant to say "We didn't blame Microsoft for 'lock-in' due to 3rd parties creating IE-only websites, we blamed the 3rd parties." Implementing non-standard extensions was par for the course during the browser wars (Netscape did the same), and I doubt there was a real expectation of achieving lock-in via the browser by either party: Windows achieved lock-in via Windows, Office and legal threats. Not IE.
And yes, there was very much expectation of achieving lock-in via ActiveX. And it worked in some cases.
It's Chrome's fault that it's shipping non-standard things. Not like any browser is blameless here, but let's not pretend they're innocent either.
It's _Google's_ fault that it's shipping non-standard things in its browser and then using them in its other products to lock out other browsers.
> We didn't blame Microsoft for "lock-in" back in the IE-only website days
We sure did. And it wasn't even Microsoft creating the IE-only websites!
I challenge you to name one non-niche browser that didn't ship "non-standard things"
In the case of NaCl, Google got around their own pledge by declaring NaCl "not part of Blink" and therefore not subject to the Blink rules, which was a cop-out if I've ever seen one.
Chrome has done a lot more promotion of its non-standard things and of course Google as a whole has been using Chrome's non-standard things quite a bit, which is a large part of the problem.
Also, Chrome is not usually right in my experience. A lot of times they don't even manage to implement the specs they themselves write correctly... Then someone else has to come along and file bugs on them, and maybe they fix them. Sometimes.
All of which is anecdote. Actual data would be much better, of course.
Could you specify some issues you ran into on Chrome that affected user space this directly or took anywhere near this long to fix? I've been doing all of my development in Chrome for ~6 years and have done very, very few Chrome-specific workarounds. On the other hand, I ran into both the Firefox bugs mentioned in the last half year.
You can find the oldest unfixed bugs for Chromium here (https://bugs.chromium.org/p/chromium/issues/list?can=2&q=&so...).
A lot of those issues are from 2008 (that's when Google Chrome launched) and hence means that have been there since the beginning and most of them affect user interaction.
Throwing dirt doesn't help anyone. If you have the skills and time, contribute a browser of your choice.
Yes, you will. Take the border-collapse bug I mentioned: it doesn't affect other engines, to my knowledge. Border-collapse goes back to, like, IE5.
You mean like not supporting high-contrast themes on Windows, literally the first thing on the list at https://bugs.chromium.org/p/chromium/issues/detail?id=92 ? Not a problem for web devs obviously, just for users, which I guess is partly your point.
Or https://bugs.chromium.org/p/chromium/issues/detail?id=2016 which is about XHR not providing progress notifications properly and at filing time was working correctly in Firefox 3 and IE 7?
Or the lack of sane text rendering behavior, having to at best opt into ligature support, if you can get them at all, etc? That's something they finally fixed recently, after 8+ years of it being a problem.
Or missing MathML support? Granted, some other browsers are pretty bad on this too.
Seriously, there's lots of stuff Chrome couldn't and can't do that other browsers can do. They're just much better (not least due to spending way more money on it) at steering web devs to never try the things Chrome is bad at and focus on the things the Chrome dev team has been focusing on...
It depends on priorities, obviously. That bug was fixed in various cases that were most-commonly hit (e.g. translate-only transforms) much earlier than now. Fixing it in the scale case more or less required completely rewriting how <select> is implemented, and there was always other stuff that needed to get done that was a bigger problem in practice.
I'm not saying this is good, obviously; it would be great if there were more people working on Gecko bugs and triage were not so critical. But there weren't and it was. I'm sorry that it's caused you problems; I'll see if I can get some progress to happen on the option label thing.
> Could you specify some issues you ran into on Chrome that affected user space this directly
Off the top of my head, https://bugs.chromium.org/p/chromium/issues/detail?id=352144 is a pretty glaring CSS layout bug. Is that direct enough?
Or how about https://bugs.chromium.org/p/chromium/issues/detail?id=269500 which has been around forever (it existed in WebKit long before Chrome was even announced)?
Or https://bugs.chromium.org/p/chromium/issues/detail?id=353580
Or https://bugs.chromium.org/p/chromium/issues/detail?id=286672
Note that all these bugs were filed in the WebKit bug system for a while before I went and refiled them in the Blink bug system after Blink forked off from WebKit. So they are much older than the dates you see on those reports.
To this day, the versions of IE in use by actual people are awful. MS finally has Edge, which isn't awful, but absolutely no one uses it.
If I tell an end user to get Chrome or Firefox, that's the end of the problem, whatever system they have it will work. If I try to tell someone to update their IE or to get Edge, I'm stepping into a black hole of trying to divine which version of Windows they're on and how recent their updates are. None of my mac loving coworkers can easily test against IE or Edge and headless unit testing against IE isn't a thing.
IE wasn't awful at the time it was built. It was ahead of its time in some areas. It became awful because of tech debt: people building for it and only it. Companies having key line of business apps built solely for IE that locked everyone into a compatibility nightmare.
It is the same thing with the "Just install Chrome" crowd. If all anyone uses is Chrome, then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility. How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs? (That Fortune 500 company could even be Google at this point, because they very much seem to have invested in an internal monoculture.)
(Your Mac coworkers can find free Edge testing VMs from Microsoft. There's also "headless" tools like BrowserStack.)
Too late. This has already been happening for years in the mobile space. It's why WebKit refuses to remove -webkit prefixes, and other browsers are now forced to implement them.
I don't think this has much to do with Chrome - I suspect the iPhone's dominance of the mobile browser share is a big factor.
The web has a long history of post-facto standardization where implementation comes before standardazation (see browser wars).
Chrome is evergreen, cross platform, open source.
That makes a big difference. Chrome gets bug fixes, implements new standards, etc.
It's a different crowd, I think.
Installing a new OS to view a webpage was a tall order.
The only issues Firefox has are when you get to media handling and non-standard APIs from Chrome. 99.9% of websites "work" on all browsers though and I haven't seen any need to run Chrome for a specific website (Google Docs used to be a case but not anymore).
This is a behavioral difference with Firefox. Chrome is currently blocking scrolling on the JS inside the wheel event handler which appears to be very slow on the linked website. Firefox is only blocking on the JS for the first event inside the scroll gesture and asynchronously scrolling after which hides the very slow JS handlers.
This is an interesting case because the Chrome behavior lets sites implement certain effects without lagging behind scrolling while the Firefox behavior favors smoothness of scrolling over JS effects synchronized with wheel handlers. In any case, Chrome is currently working towards switching to the Firefox behavior which will make sites like this scroll much more smoothly.
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.
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 ...
12% of desktop, ~5-6% of total. 3 years ago it was ~18% of total, there is certainly a consistent downward trend in usage.
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
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.
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.
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.
No one I know develops on Firefox, mainly because of how amazing Google Chrome's developer tools have become over the years.
It's not even close. So yes, developers use Chrome because Google has an entire team dedicated to make their tooling cutting edge for developers.
I remember wanting to use Italki, but their website wouldn't let me input my credit card details when using firefox. I mentioned it to their support team, and they just suggested I use chrome.
I guess they're big enough that my lack of custom won't hurt, but I figured that since "inputting numbers into a field" was already a solved problem in front end web development, that they might as well sort it out.
The hyperbole in your comment kinda kills me though. The glory days of web standards that you are talking about were largely glorious because Firefox came out from left field and started implementing standards and new features at a high velocity compared to Microsoft's IE. Firefox started to beat IE in tooling and platform features, and it was open source to boot. Firefox even had the edge on IE with regards to security (to be fair the bar was low in those days).
All of these details greatly endeared Firefox to me. As a web developer, I loved Firefox for what it stood for and also what it enabled me to do.
Chrome is "winning" the web browser game by taking the pages out of Firefox's playbook. Chrome is open source. Chrome is heavily involved in the standards process. Chrome takes a lot of credit for pushing browsers towards evergreen release cycles. Chrome offers the best developer tooling. Chrome implements standardized web platform features at a rapid clip.
I hate that Chrome is dominating the market. But I don't hate Chrome, and I definitely don't think the status quo today is worse than the one during the Internet Explorer regime. I hate it because it shows that there is a tremendous imbalance in the resources spent on other browsers compared to Chrome. I hate it because I don't think that the ecosystem is as great as it could be if the developer mindshare was more distributed across different browsers.
It's easy to forget that the "bar" for "gutter low" was set a long time ago by a company (M$) that decided the web was boring and could die for all it cared. I think it's simplistic and misleading to suggest that the situation today comes close to that.
Except Mobile.
This article goes into more depth: https://www.scirra.com/blog/173/just-how-evergreen-is-micros...
(I ask as somebody that is unaffiliated with Microsoft, but uses Edge as the daily driver.)
- The tabs are way too small
- The console input is super awkward
- HTML element viewer could show registered events (like Firefox does)
- It can be better looking