Intra-browser-communication does not often follow a spec though. Of course, replacing a parser (for video formats, or css) is easier because of standards, but how to composite parts of an html site? That's not covered by standards.
Is there an argument that it should be?
True, but the W3C so far has done a horrible job at defining standards, which partly explains why no two browsers can render identically.
Most of the rendering differences I've seen date back to the era before anyone cared about standards. Can you give an example of a modern feature (i.e. not tables) that different browsers render differently due to ambiguities in the spec?
UI for the HTML rich elements such as the spinner.
Punnycode encoded email addresses in email fields.
Numerical keyboard on number fields.
The whole mess with WebRTC.
Video elements codecs.
History API in early mobile browsers.
The various APIs for storing data locally in the browser (particularly regarding blocking and size limit).
Data expiration. This one is so messed up it makes me angry.
Spawning a background task.
And those are just the ones that popped in my head in a few minutes.
There are a lot of bugs out there. They're usually hard to trigger, but you come across them when working on browsers.
For example, the animation of 3d CSS transforms (which needs SLERP) differs in some test cases across different browsers. I don't think any browser displays the correct behavior here, though the spec is a copy of what webkit does so I suspect the spec gets it wrong too. Other engines have an implementation of the algorithm that doesn't match the spec textually. I'm unsure if the algorithms used in these browsers are actually equivalent and it's an implementation bug, or if the algorithm picked is wrong.
However these are just really examples of bugs. There have been cases where the spec itself is buggy, and cases where it is ambiguous, but both get addressed. The specs these days try hard to avoid this. But bugs will happen.
Here's one. http://www.bizcoder.com/how-not-to-write-spec-documents
Most of these bugs will only be found by the people given the task to implement the spec, not users of the implementation.
That's the cool thing about open standards.
As long as individual pieces are to spec, it's completely ok to rewrite modules and components from the ground: People rely on the standard, and not the app.
Add-ons will still work, but only the new WebExtensions. In Firefox 57 XUL extensions will stop working so Mozilla can finally start doing work on the internals of Firefox. Plugins like Java applets and Silverlight stopped working in Firefox 52 (not the ESR)
I wonder if they are driving people away by disabling things that worked for years. At work I have to use Java and Silverlight. In addition our IT department doesn't seem to be able to keep their certificates up to date. With chrome and Firefox being so strict they are almost unusable so I am using IE. In theory this should pressure suppliers to get rid of Java and our IT department should have better certificates but in practice I don't see this happening.
I see people on Reddit saying they'll leave to Chrome if XUL extensions will no longer work since Chrome would be faster than Firefox, but I don't think they understand that Mozilla is removing XUL extensions so that they can finally make Firefox faster again. And even if this wasn't the case Firefox is still way more customizable than Chrome.
I think that as more and more websites will move away from Java and Silverlight I expect that other companies will be forced to do the same as the customers will keep having less reasons to keep a browser with those plugins supported.
Yeah, the other side of all of this is that I'd leave Chrome for Firefox if it did drop XUL and get up to par performance/ security / feature-wise. I'm sure many others feel the same.
Yeah, I think our big bet here is that Firefox will achieve better market share by leapfrogging the competition in performance versus remaining insanely customizable despite lower performance.
EDIT: Added "insanely"
I am not the product manager so I don't know for sure but this can go very wrong. Once you disable something and force a user to go somewhere else they will probably not come back. Especially since Chrome and Firefox and to some degree IE are in a race to almost look the same and have no distinguishable features. It used to be that Firefox's selling point were extensions. With that lost, what's the reason for Firefox? I don't think performance matters enough for most users to switch.
It's not like every Firefox extension will be broken. And I'm an ex Firefox user who switched to Chrome for the sandboxing and multiproc architecture. I'll happy go back to Firefox, I'd much rather use a browser by Mozilla over Google.
Maybe in the short term keeping some users is worthwhile but they'll continue to lose them slowly to Chrome, and browsers aren't fighting a short game. Firefox, Chrome, IE, they're not going anywhere - they've been around for a long time with plenty of market share. It makes sense to be forward thinking here.
> It's not like every Firefox extension will be broken
Every Firefox extension will be broken. Only Chrome extensions will be supported.
Hard to say. Clearly there are two camps.
While we are indeed forcing an abstraction layer onto extension devs, that does not necessarily mean that we are going to use Chrome as the lowest common denominator with respect to extensibility.
Hopefully we can hit a sweet spot with respect to customization. WebExtensions are a superset of Chrome extensions, and do we have an open process for people to propose new APIs.
Some people are never going to be happy, but hopefully others will step forward and build some cool stuff.
> I see people on Reddit saying they'll leave to [X] if [Y] will no longer work
Every major change ever made in any system brings out those comments. Whether the change is good or bad, successful or not, is not related to the existence of those comments.
Just look through Bugzilla; you can find those comments in (it seems) any change that attracts public attention.
But here you have people (myself included) who use Firefox despite of any performance problems because of specific add-ons.
We all want faster more stable software but if that single feature trumps that for lots of people it seems crazy to just dump it. You can make a car faster and better on gas if you remove almost everything that makes it comfortable too. We all want cars that go faster and use less gas but we also like comfortable seats, storage, and air conditioning.
Remember that Google is an advertising company. Chrome is an ad delivery platform, ultimately. Firefox isn't broken because it isn't like Chrome.
That's the boat I'm in.
Firefox's literal only advantage over Chrome is its extensibility, and that baby is being thrown out with the XUL bathwater. It's slower than Chrome, it's less secure than Chrome, and since Mozilla seems hellbent on turning Firefox into Chrome, I might as well just bite the bullet, use Chrome and save myself the headache.
The only other advantages I can see are philosophical, rather than practical, but given their history of shoving irrelevant shit into the default install and ignoring any and all user pushback to their decisions (the "we're forcing addon signing" comment section was unanimously negative), I'm not sure that's worth much either. If I want to use a browser where my input on features and so forth is discarded, again, I might as well use Chrome and gain some speed and security while I'm at it.
I ask this question in complete sincerity: Why would I want to use Firefox?
We're not breaking legacy add-ons for shits and giggles, or in some misguided attempt at "turning Firefox into Chrome." We're breaking them so we can finally land the architectural changes necessary to make Firefox competitive on speed and security, and we're committed to remaining more extensible than other mainstream browsers. The Containers API that landed in Firefox 53 this week is a great example of that.
I'm not going to shed a tear over Classic Theme Restorer or DownThemAll if their loss means a faster, more secure, and still more extensible browser than Chrome.
Mozilla has been committed to a lot of things. "The only browser built for people". "Freedom is personal".
Apparently, "people first" and "freedom" means "You can only install what we okay" (signing crap).
It also means "we will load the browser with utterly irrelevant add-ons whether or not you want them".
Apparently, "individuals can shape their own experience" means "we will outright prevent you from visiting sites configured a certain way" (see the dupe SSL cert handling bug that's been languishing for nearly a decade)
It also means "all that stuff you spent a decade getting used to gets thrown out, so sorry".
Mozilla, for all their talk of high-minded user-first ideals, sure doesn't treat their users like their time is valuable or their tasks are important. Perhaps I'd find this merely odious, rather than outright offensive if your company didn't continually talk like they wanted to be different and then behave in literally the opposite way.
Call this post gratuitously negative if you want to, but every time I give Firefox another try, I find another slap in the face. At least I know where I stand with Chrome.
Who exactly are you "competing" against? This isn't a competition. Linux is not inferior because it isn't Windows.
The early days of Firebird were not spent trying to match the features of Internet Explorer!
Internet Explorer offered some superior features that Mozilla could never match. It even had awful custom CSS rules, that let websites do things like change the color of scrollbars.
Firebird focused on making a fully standards compliant browser, and then success found it, when the public got sick of Microsoft. And maybe that won't happen this time around, but so what?? This is just hubris on the part of Mozilla, at this point.
I'm horrified at what would have happened, if in 2006, everyone had rolled up their sleeves to bring ActiveX support to Firebird on par with IE6. Is that what you think would have worked?? Microsoft would always be several steps ahead of you.
This is tilting at windmills.
I don't think it's logically possible to make Firefox as extensible as it is, and also "secure" as Chrome.
Chrome is crippled in many ways. Extensions are second class citizens, merely along for the ride. They can be removed remotely at Google's whim, and you can't rely on them to run reliably. They also don't have full access to the browser the way Firefox add-ons do.
Among my different profiles, I have profiles to slice and dice the web. I can do a ton of web scraping without having to write any scripts. I can do a ton of cool stuff, and customize Firefox the way I want. Firefox gives me cheatcodes to the web.
Who the hell said extensions had to be sandboxed? That's an overly cautious decision that makes sense for Google. It's a WEAKNESS. It's a COMPROMISE that Google had to make with Chrome. It is not a strength.
The iOS app store makes money for Apple. So does that mean we must copy the weaknesses of the iOS app store? That's cargo cult thinking.
They toss out one advantage to gain flexibility to try to improve in other areas.
For a site that has people who go on and on and on about the innovators dilemma this argument seems pretty shortsighted.
Ultimately I think someone has to else people will never stop using Java and your IT department will never improve. At least currently it seems like all the main venders are unified in progressing so maybe one day we can instead start complaining about something else, like how outdated html5 is.
Do you think someone will approve that developers rewrite the Java/Silverlight app or the alternative to use the old/LTS browser and have devs work on current bugs and new features(that could be on a different project not the Java/Silverlight one that is currently in maintenance mode)?
I think the second option will be used in most cases.
Alternative, is it worth it to try to cater to users like "you" vs just leaving them behind?
Java and Silverlight I get, but not upgrading certs I consider to be pushing it. When we cater to users who have no interest in upgrading technology we hold everyone else back.
I prefer the technique of saying "It's done on this date. Ignore us at your peril". The view that technology can just be bought and then never maintained is ridiculous and should die. Nothing else operates like this. You buy a machine and you know it's going to include ongoing maintenance costs. Software is no different and trying to pretend it is just ends up with you paying stupid amounts of money and resources to maintain an ancient tech stack decades later. Or worse you have a stack where the people you are paying big money to maintain it are starting to retire or die.
I discovered now you need to have your extensions sign by Mozilla, we had such an extension that worked only with our product, you needed an account and we did not had many users, but now the extension will not work(you can make it work only on dev version of Firefox) until we get it signed by Mozilla.
You can automatically sign your add-on by calling `jpm sign` (SDK add-ons), `web-ext sign` (WebExtensions), or by manually hitting our API: https://developer.mozilla.org/en-US/Add-ons/Distribution#Sig...
Requiring signing of web extensions is still ludicrous. It makes sense for Google to do it. It makes zero sense for Mozilla to do it.
Google wants to make money by developing a platform.
Mozilla (should) want to make technology that empowers people. Mozilla does not have to provide technical support. Mozilla isn't making money off of it. I think that the only reason they did it was because Google did it.
Should emacs or Autocad require signing of extensions? Why not? Because it would go directly against the grain of what those tools are for. And users should be smart enough to handle their own security.
I would like someone to justify Firefox extension signing, while also explaining why nobody cares if other software has signed extensions.
Because web browsers are the single largest and most common attack vector on every end-user device, and emacs and autocad aren't. I'm not in a position to say whether Mozilla's implementation of extension signing makes any sense, but it is practical to hold web browsers to higher standards.
I'm also not sure how extension signing makes Google any money?
Extension signing makes Google money because it supports their platform infrastructure. It supports things like Google Play. Microsoft also made money from Internet Explorer, even though they didn't charge money for it. They benefited from controlling the platform.
Mozilla has no such incentives. And they also don't have any larger strategy that Firefox supports.
Yes, new stuff will work, but not the stuff we have been using for years (which for a time will be much more capable than the WebExtensions add-ons). That would be noticeable, unlike what the title suggests.
Instead of crying about it, WE can add suggested APIs to be included in the WebExtensions extension Firefox is using. They recently added the Sidebar API which allows a form for vertical tabs but nobody has implemented trees yet.
Perhaps before doing such a major change, Mozilla, who hosts and awful lot of the extensions, could have done some code analysis on said extensions to determine what APIs were needed to make a smooth transition. Saying WE can add suggestions is a foolish thing to ask users when they had a community of developers and the actual code to do an analysis on. Blaming users is poor form.
They've shown themselves to be quite reluctant to accommodate the needs of vim extension authors (such as Vimperator). They can get bent.
Theres also been quite heated discussions (and hostility from Mozilla devs, to be frank) around the Zotero plugin, see e.g. Dan Stillman's 2015 blog post and email-list-threads linked there.
Edit: for those who don't want to dig, a random quote:
"Shortly before we left AMO [Firefox's integrated addon channel], an AMO editor publicly told someone asking a technical question about Zotero that Zotero was “evil”, adding, “They submit a new version every week, with thousands of lines of changes, nearly always additions. Every time I review it I hope they’ll go bankrupt”"
It seems (from many signals) very much like Mozilla would prefer it if most Firefox addons were tiny 200 line hobby projects that got updated once a blue moon.
Many AMO Editors are volunteers, and all are human. We've significantly adjusted the AMO review guidelines and processes to avoid that sort of mishap in the future, as acknowledged at the end of that post.
We're working hard on further changes to the process to reduce the stress and delays associated with manual review, including moving the review process to a post-publication check, instead of a pre-publication requirement. The heavy-handed review process was necessary with the old model of add-ons which had unrestricted access to the browser and to the host system. The new, permissions-based WebExtension model is dramatically easier to audit.
Well, maybe this failure should be taken as a signal that you're doing something wrong.
Google will always beat you at this, always. They can afford to pay far more people than you have volunteering for you, ever.
There is no justification for Mozilla's extension policy. Mozilla is just LARPing as Google. They are superficially copying some features of Google's platform, in the hopes that they will magically inherit Google's success.
Microsoft still sells their software in boxes in retails stores. Perhaps Mozilla should spend money pressing discs, but instead of selling it, they should give away Firefox discs in stores. That's a good analogue to what Mozilla is doing.
This is a colossal waste of time that nobody asked for and nobody wants.
well, thousands of lines of changes nearly always additions sounds like it should be a code smell / integration smell.
that's not the topic though.
As someone who hasn't followed the actual specifics here, do you happen to have any links to those discussions/issues or other places these things happened? I'd really like to see their reasoning.
Only to the few people who use those extensions. Most user's don't use any extensions at all.
What are you basing that on?
A quick google suggests that at one point 85% of users used extensions.. and as of last year it was still 60%
And how many of those 60% just use ublock or something similar, which will continue working, and no other extensions?
That really wasn't the point of my post. The claim made by the parent post was that "Most user's don't use any extensions at all."
My apologies, I didn't mean to come across as disagreeing with what you said, but just to put it in better context for the larger discussion of how noticeable disabling non-web extensions will be to the average user.
You're moving the goalposts.
I'm pretty sure having plugins no longer working going forward is quite noticeable.
A reminder that Quantum is the name of the project, not the engine. The result of Quantum is still Gecko.
It won't be here until at least Firefox 57.
I believe its referring to the compact theme(s) that have been a part of nightly (and developer edition) for a long time.
Nope, they're referring to a new UI called Photon.
there are new themes available in 53 when you go to add-ons > appearance.
What's this about a new Firefox UI? I'm on nightly (55) and it's still Australis for me.
Quantum is the name of the new web engine for Firefox. It started landing in the current release, and will land piece by piece over the next several releases. Servo is related because several of the big parts of this new engine are taken directly from Servo.
I don't know that any Servo code is shipping today, but a few little things will happen like the url parser.
The first big pieces will be the style system (Quantum Style or Stylo) and WebRender (Quantum Render), in that order. Once the style system is done, it probably makes sense to figure out how to get Servo's layout engine into Quantum, although that is a larger project since it requires us to implement a few large bits of layout that aren't done in Servo yet.
There's a lot of main things in Servo, but if we had style, layout, and WebRender, that would be a sizeable chunk. Our DOM engine and basic architecture is also pretty interesting, but it's unclear how to move that over incrementally.
Adding more info on what's shipping:
Quantum Compositor (an architectural improvement written in C++) just shipped.
Quantum Render/Webrender (Servo's pure rust renderer that uses the GPU a lot) is in nightly, off by default (there's an about:config prefer, though it may not work depending on your drivers. about:support has more info). The current version of quantum render actually kind of renders twice -- first using webrender and then the regular one to fill in the missing bits. So don't expect it to be fast just yet.
Quantum Style (Stylo), servo's pure rust styling system, can be enabled at build time. We're discussing making it a preference in nightly, there are a couple of blockers for that.
The Rust URL parser (rust-url) can be enabled via network.standard-url.enable-rust. This will parse URLs using both rust-url and the regular parser, and complain about differences. I believe it's on by default in nightly and Aurora. It will fall back to the result of the regular parser if there is a difference, though there's a build time option to disable this. There are still some discrepancies which need fixing (most of them are actually gecko side bugs, we've fixed most if not all of the rust-url side spec issues), and this project is on the back burner for a bit since I'm busy with Stylo, but I hope to get back to pushing this soon!
On nightly, regardless of prefs, IPV6 URLs will always be serialized using rust-url. There were some spec bugs in geckos implementation and we decided to just use the rust stuff since we had bindings for it already. This landed a month ago, and should be in the Firefox 55 release in august.
The MP4 metadata parser in rust has been in Firefox releases for a while now.
For those playing along at home, metajack is the Servo project lead.
From Servo Stylo, the style system and WebRender, the renderer are used in Quantum.
Stylo is more parallel which will bring a big performance improvement, especially on multi-core and mobile devices while WebRender uses the GPU to render websites which will also bring a huge performance improvement to mobile devices and computers with an (integrated) GPU.
Well yes I know that servo is about to make use of multi core but looking at its issues its far from ready for displaying websites correctly. So I am confused about this still as you have not really addressed what parts of servo are in fact in Firefox right now and what parts are not. I am not sure how "Rendering" is defined the way I understand it, its the part where servo has a looong was to go until its ready.
Servo is still far from ready to use as a complete browser, but Servo is modular, and some modules are far more mature than others (intentionally so, because Mozilla wants to integrate those bits into Firefox ASAP, and so focuses most development there).
If you have the time there is a nice talk about WebRender: https://www.youtube.com/watch?v=BTURkjYJ_uk
Here is another great talk: https://www.youtube.com/watch?v=an5abNFba4Q At ~25:30 he'll also talk a bit about Quantum.
In a nutshell WebRender is used to send a web page to the GPU which will paint all divs, borders, shadows, images etc. Currently WebRender is the only component I'm aware of that is inside Firefox Nightly. It's still behind a config though.
IIRC the first part to be used in Firefox is the URL parser: https://bugzilla.mozilla.org/show_bug.cgi?id=1151899
Note that the parser is off by default unless on nighty or aurora, and even in those cases it will run both rust-url and the regular parser to figure out what differences exist.
In nightly currently IPV6 urls are unconditionally serialized with rust code, and this will ride the trains to a release without being turned off.
Here's the Quantum page on MozillaWiki: https://wiki.mozilla.org/Quantum
And a recent blog post about the first piece of the project landing in Firefox: https://blog.mozilla.org/blog/2017/04/19/first-big-bytes-pro...
Can someone explain to me in a few words what exactly from servo is already in Firefox and how quantum is related to servo exactly? Some CSS processing is already in Firefox I think. But the main thing of servo is the rendering right? That seems to be pretty far away from ready.
I think we all noticed Edge and how great it is.
WebAssembly you mean?
From the ground up, hey? Are they going to include an actual proper modern execution environment, or even one that would have been proper in the 1970's?
Don't be ridiculous, Chrome didn't even exist a decade ago.
I didn't say Chrome existed back then, you pedant.
You implied it, especially by talking about all major browsers except IE. There weren't multiple major borwsers besides IE a decade ago, there was only firefox with 20% market share.
You probably missed the back then just before the part you quoted. So, the all major browsers is modified by the indication of time I had given two words before it. I feel like two pedants meeting each other is like an unstoppable force meeting an immovable object.
Pedantry is Computer Science 101, it's literally just saying the words that describe the thing that you're trying to communicate (not unlike programming languages). It's trivially easy! :)
I love how everywhere on the internet, the Edge DOM upgrade is portrayed as something great and novel when really it's computer science 101, making a proper tree structure - something that should have been done at least a decade ago, and has probably been done back then by all major browsers except IE.