(Well, currently. There are proposed APIs that could change that, but they aren't implemented in Firefox yet and even if they are, it would be a long time before they're widely used.)
If you try the test page in the original article in Chrome, and switch to and from the test page's tab, you can see that Chrome is actually doing exactly that, and it has a huge problem. When you switch to the test page tab, it renders its old version of the page, and then there's major lag (on my Linux system at least) while it renders the up-to-date version of the page (which is animated), then it jump-cuts to the new version of the page. It looks extremely laggy and jarring. Tab warming avoids this problem.
And as others noted, caching images of all tabs is quite memory-hungry (especially if you have lots of tabs and a 4K display). This is one reason Firefox is less bloaty than Chrome.
A huge amount of work was done to stop the Firefox UI from blocking on the activities of content processes, as part of the multiprocess work that shipped up to and including FF 57. It's pretty good now although there are probably a few lingering bugs.
What makes you think loading is "poorly optimized"? A lot of modern Web pages are bloated, but that isn't Firefox's fault.
Most users only ever have a small number of tabs. Unlike you, Mozilla has actual data on this. So in fact it is more likely they are switching tabs.
Showing the tab title on hover doesn't require any interaction with the content process so it's unlikely that would be affected by tab warming, for better or worse.
I'm not talking about page-load speed specifically. It's all about how people perceive the performance of the browser. A lot of people switch browsers in response to that, from Firefox to Chrome, and lately from Chrome to Firefox.
Your speculation about Mozilla's goal-setting is wrong. Success is simple: get more people using Firefox, which means making Firefox superior to the competition in the ways most people care about. Those things don't change much over time: performance, Web sites working properly, maybe security if someone credible tells them a product is more secure, in some cases UI features or ad blocking. Mozilla has no choice but to compete in those areas to remain viable long-term. It would make no sense to stop working on something people care about just because "Chrome did it first". There is no reason why Firefox can't match or surpass Chrome in those areas and win users because of that.
Of course it makes sense to *also* introduce innovative new features, though it's hard to come up with features Google can't easily copy if they prove successful. But Tracking Protection is one such feature.
The "goodwill" you go on about, which I presume is the goodwill of people who wanted nothing to change in the Firefox UI or addons ecosystem, is neither necessary nor sufficient for Mozilla to be successful. (For any proposed change to the Firefox UI, there is a set of die-hard Firefox users who loudly oppose it, even the change *back* to square tabs.) Mozilla has made a completely correct decision to keep improving Firefox for the mass market and refuse to be paralyzed by the demands of do-nothingism.
It's unclear what you think of as "copying Google" in terms of paths Mozilla should not follow.
If you mean "make a fast browser" then you're wrong. For long-term survival, Mozilla absolutely needs Firefox to be as fast or faster than Chrome, and that is achievable, and has been partially achieved; many people have switched to Firefox 57 from Chrome because they feel Firefox is faster.
If you mean "secure the browser using content process sandboxing" then that's wrong too. Without that Firefox has been running a long-term security deficit compared to Chrome, and that is neither sustainable nor responsible. That gap has now been mostly closed.
However, those goals required abandoning the XUL extensions model. Feel free to keep using Pale Moon, but its performance and security will fall further and further behind.
Also you're completely wrong about the development model. Doing a big-bang release once or twice a year was a terrible way to ship a browser. It meant we were unable to react quickly to changes on the Web, changes made by competitors, or changes in underlying operating systems. It created huge pressure for half-baked features to ship before they're ready, since if you missed the deadline that meant 6+ months of delay.
I've been programming in Rust full-time for nearly two years and disagree entirely with everything in this statement. In particular, I have never had to give any thought to the code of conduct. But maybe that's because I'm not a troll.
I'm sure it has been discussed, but it's a very difficult business to get into. Look at how Microsoft search quality has struggled for years with a much greater investment than Mozilla could ever afford.
Actually it's quite irksome to read trolling like this given I spent most of my long, paid employment at Mozilla fixing bugs, including security issues and worked with hundreds of dedicated colleagues also doing that.
Firefox's security record is not much different from other Web browsers, and better than some. And it's getting even better now that the latest Firefox releases have quite good content-process sandboxing.
WebAssembly programs have access to exactly the same set of APIs that JS programs do. They just run some things faster. There is no change in security (except slightly more attack surface in the form of the WebAssembly compiler, and even that's minimized since browser WebAssembly implementations reuse existing JS compiler backends).
WebAssembly is no more obfuscated than minified Javascript.
Having an application platform that isn't controlled by a single vendor, has no gatekeeper, and can run on any device --- and actually has a huge number of apps --- is incredibly important. The Web is that.
People who don't want the web browser to be an application platform are welcome to disable Javascript in their browser. I'm happy to leave it on.
Actually Web browsers need to implement a standardized speech recognition API (WebSpeech --- https://developer.mozilla.org/...), so this work could and probably will become part of Firefox. We wouldn't want speech-dependent Web applications to suck in Firefox on Linux because Firefox doesn't have access to a quality recognizer on free operating systems, would we?
The vast majority of Mozilla's money is spent on Firefox. You just made up "most of their money is spent on community projects" out of thin air, didn't you?
So you feel that your theory that Microsoft was secretly running Mozilla is not in the least undermined by Mozilla exiting the Yahoo deal and no longer receiving money (indirectly) from Microsoft?
That's totally wrong. It's incredibly important to Google that they maximise their search market share. Not only do they monetize search directly but controlling search feeds all kinds of other Google strategies like directing people to Maps etc.
I don't know about currently, but I've been told that at times Microsoft and Google each had over a thousand developers working on their browsers.
Apart from the difficulty of implementing the client software and its various axes --- security, compatibility, performance, platform porting, and so on --- these days a significant server-side component is also needed. Downloads, updates, addons, crash collection, telemetry, push notifications, and so on. And for developers, CI, massive test farm, telemetry/crashes analysis and viewing, etc.
Then you've got people writing tools and frameworks for the above teams. E.g. the rr project was born at Mozilla to improve life for Mozilla's C++ developers.
Then you've got people doing standards work (at Mozilla, usually part of the developers' jobs), Web site evangelism and other external relationships.
Then you've got Mozilla Research building stuff like Rust and Servo exploring technology that may eventually become part of Firefox.
Then of course you have the overhead --- HR, PR, lawyers, accountants, logistics, office managers, event organizers, personnel managers, executives.
I worked at Mozilla for a long time. Over the last five years headcount was at about the same level, even during the FirefoxOS years. We were *always* butting up against headcount limits, more work than we had people to do it. It's not like the stories you hear about Google where people are wandering around underemployed.
I worked on it for years. Given the size and the age of the code, and the problem domain, it's not bad. As for "elite", well, almost any of Mozilla's C++ developers could get a job at Google/Facebook/Apple/Microsoft easily. Many have.
Slashdot Mirror
No. Page rendering does not run Javascript.
(Well, currently. There are proposed APIs that could change that, but they aren't implemented in Firefox yet and even if they are, it would be a long time before they're widely used.)
He means uploading the rendered parts of the page to the GPU for presentation. Nothing to do with any network traffic.
If you try the test page in the original article in Chrome, and switch to and from the test page's tab, you can see that Chrome is actually doing exactly that, and it has a huge problem. When you switch to the test page tab, it renders its old version of the page, and then there's major lag (on my Linux system at least) while it renders the up-to-date version of the page (which is animated), then it jump-cuts to the new version of the page. It looks extremely laggy and jarring. Tab warming avoids this problem.
And as others noted, caching images of all tabs is quite memory-hungry (especially if you have lots of tabs and a 4K display). This is one reason Firefox is less bloaty than Chrome.
A huge amount of work was done to stop the Firefox UI from blocking on the activities of content processes, as part of the multiprocess work that shipped up to and including FF 57. It's pretty good now although there are probably a few lingering bugs.
What makes you think loading is "poorly optimized"? A lot of modern Web pages are bloated, but that isn't Firefox's fault.
Most users only ever have a small number of tabs. Unlike you, Mozilla has actual data on this. So in fact it is more likely they are switching tabs.
Showing the tab title on hover doesn't require any interaction with the content process so it's unlikely that would be affected by tab warming, for better or worse.
A strange response to an article about making Firefox faster for users.
I'm not talking about page-load speed specifically. It's all about how people perceive the performance of the browser. A lot of people switch browsers in response to that, from Firefox to Chrome, and lately from Chrome to Firefox.
Your speculation about Mozilla's goal-setting is wrong. Success is simple: get more people using Firefox, which means making Firefox superior to the competition in the ways most people care about. Those things don't change much over time: performance, Web sites working properly, maybe security if someone credible tells them a product is more secure, in some cases UI features or ad blocking. Mozilla has no choice but to compete in those areas to remain viable long-term. It would make no sense to stop working on something people care about just because "Chrome did it first". There is no reason why Firefox can't match or surpass Chrome in those areas and win users because of that.
Of course it makes sense to *also* introduce innovative new features, though it's hard to come up with features Google can't easily copy if they prove successful. But Tracking Protection is one such feature.
The "goodwill" you go on about, which I presume is the goodwill of people who wanted nothing to change in the Firefox UI or addons ecosystem, is neither necessary nor sufficient for Mozilla to be successful. (For any proposed change to the Firefox UI, there is a set of die-hard Firefox users who loudly oppose it, even the change *back* to square tabs.) Mozilla has made a completely correct decision to keep improving Firefox for the mass market and refuse to be paralyzed by the demands of do-nothingism.
It's unclear what you think of as "copying Google" in terms of paths Mozilla should not follow.
If you mean "make a fast browser" then you're wrong. For long-term survival, Mozilla absolutely needs Firefox to be as fast or faster than Chrome, and that is achievable, and has been partially achieved; many people have switched to Firefox 57 from Chrome because they feel Firefox is faster.
If you mean "secure the browser using content process sandboxing" then that's wrong too. Without that Firefox has been running a long-term security deficit compared to Chrome, and that is neither sustainable nor responsible. That gap has now been mostly closed.
However, those goals required abandoning the XUL extensions model. Feel free to keep using Pale Moon, but its performance and security will fall further and further behind.
Also you're completely wrong about the development model. Doing a big-bang release once or twice a year was a terrible way to ship a browser. It meant we were unable to react quickly to changes on the Web, changes made by competitors, or changes in underlying operating systems. It created huge pressure for half-baked features to ship before they're ready, since if you missed the deadline that meant 6+ months of delay.
I've been programming in Rust full-time for nearly two years and disagree entirely with everything in this statement. In particular, I have never had to give any thought to the code of conduct. But maybe that's because I'm not a troll.
1) It could be the fault of a Web site that you have open. A browser can't easily distinguish "valid" from "invalid" Web site resource usage.
2) It could be a Firefox bug, but if it is, it certainly doesn't happen for everyone or even most people. If it did, it would have been fixed already.
I don't think they've put much/any effort into optimizing the recognizer yet.
I'm sure it has been discussed, but it's a very difficult business to get into. Look at how Microsoft search quality has struggled for years with a much greater investment than Mozilla could ever afford.
Another example of just making stuff up.
Actually it's quite irksome to read trolling like this given I spent most of my long, paid employment at Mozilla fixing bugs, including security issues and worked with hundreds of dedicated colleagues also doing that.
Firefox's security record is not much different from other Web browsers, and better than some. And it's getting even better now that the latest Firefox releases have quite good content-process sandboxing.
WebAssembly programs have access to exactly the same set of APIs that JS programs do. They just run some things faster. There is no change in security (except slightly more attack surface in the form of the WebAssembly compiler, and even that's minimized since browser WebAssembly implementations reuse existing JS compiler backends).
WebAssembly is no more obfuscated than minified Javascript.
Having an application platform that isn't controlled by a single vendor, has no gatekeeper, and can run on any device --- and actually has a huge number of apps --- is incredibly important. The Web is that.
People who don't want the web browser to be an application platform are welcome to disable Javascript in their browser. I'm happy to leave it on.
Actually Web browsers need to implement a standardized speech recognition API (WebSpeech --- https://developer.mozilla.org/...), so this work could and probably will become part of Firefox. We wouldn't want speech-dependent Web applications to suck in Firefox on Linux because Firefox doesn't have access to a quality recognizer on free operating systems, would we?
This sort of thing is why building and maintaining Firefox is tremendously expensive. http://robert.ocallahan.org/20...
I believe this is a speaker-independent test so you shouldn't expect results to be as good as a system that has learned your speech.
In the article they say that humans have about a 6% error rate on the same test.
The vast majority of Mozilla's money is spent on Firefox.
You just made up "most of their money is spent on community projects" out of thin air, didn't you?
So you feel that your theory that Microsoft was secretly running Mozilla is not in the least undermined by Mozilla exiting the Yahoo deal and no longer receiving money (indirectly) from Microsoft?
That's totally wrong. It's incredibly important to Google that they maximise their search market share. Not only do they monetize search directly but controlling search feeds all kinds of other Google strategies like directing people to Maps etc.
You have no idea how complicated a browser is.
I don't know about currently, but I've been told that at times Microsoft and Google each had over a thousand developers working on their browsers.
Apart from the difficulty of implementing the client software and its various axes --- security, compatibility, performance, platform porting, and so on --- these days a significant server-side component is also needed. Downloads, updates, addons, crash collection, telemetry, push notifications, and so on. And for developers, CI, massive test farm, telemetry/crashes analysis and viewing, etc.
Then you've got people writing tools and frameworks for the above teams. E.g. the rr project was born at Mozilla to improve life for Mozilla's C++ developers.
Then you've got people doing standards work (at Mozilla, usually part of the developers' jobs), Web site evangelism and other external relationships.
Then you've got Mozilla Research building stuff like Rust and Servo exploring technology that may eventually become part of Firefox.
Then of course you have the overhead --- HR, PR, lawyers, accountants, logistics, office managers, event organizers, personnel managers, executives.
I worked at Mozilla for a long time. Over the last five years headcount was at about the same level, even during the FirefoxOS years. We were *always* butting up against headcount limits, more work than we had people to do it. It's not like the stories you hear about Google where people are wandering around underemployed.
Only Google can build and distribute Widevine.
"Hard to program in C++" can be written in another way: "C++ is error-prone". And that's a problem with the language.
I worked on it for years. Given the size and the age of the code, and the problem domain, it's not bad. As for "elite", well, almost any of Mozilla's C++ developers could get a job at Google/Facebook/Apple/Microsoft easily. Many have.
People use bare pointers all the time: "this". They also use references, which are semantically equivalent.
"Modern C++" with smart pointers etc doesn't come close to protecting you from use-after-free bugs. See for example https://github.com/isocpp/CppC...