I attempted to switch to Firefox earlier this year, as part of a personal exodus from Google. I ended up switching back to Chrome because I couldn't tolerate the poor performance.
I'm giving it another shot now that Electrolysis is there. I've only been using it for half an hour now, but my initial experience has been promising.
Welcome back! Fair warning, legacy add-ons can perform worse under multi-process Firefox, since any synchronous APIs now require cross-process locking. To the greatest extent possible, try to limit yourself to add-ons badged with "Compatible with Firefox 57+" on addons.mozilla.org, which are guaranteed work well under Electrolysis.
I wish there was an easy way to see which of my currently-installed addons are not compatible with Firefox 57+, instead of having to look at which I have installed and searching for each of them individually on addons.mozilla.org.
I did search and it looks like HTTPS Everywhere, LastPass, and RescueTime aren't compatible. Privacy Badger is compatible, which may satisfy people looking for an ad blocker.
Hah, every one of my addons is legacy. FireGestures, LastPass, Session Manager, Tab Mix Plus, and uBlock Origin.
LastPass and uBlock Origin have Chrome versions so I have some degree of confidence they will be ported over.
FireGestures is absolutely essential to me, and no confidence there. Once Mozilla stops supporting XUL extensions I guess I'll use a Firefox fork or switch to Vivaldi. After... geez... 13 years of using Firefox. They finally forced me away.
Hopefully Vivaldi supports customizable mouse chord gestures by then.
I'm dubious, because after nearly a decade, Chrome has exactly zero mouse gesture addons that I consider remotely usable. None of them work consistently. Not a single one is comparable to FireGestures.
But thanks for the link to Foxy Gestures-- I'll give it a shot!
Edit: Tried out Foxy Gestures. Not usable. First, no support for mouse button chording. Second, every single gesture pops up the right-click menu. Third, gestures don't work maybe 75% of the time-- difficult to tell if that's due to the right click menu popping up or if it's just plain broken.
Seems like it's this bug at fault. Mouse gesture Webextensions are broken on MacOS and Linux.
We're still nearly half a year away from Firefox 57's release, so many add-ons, like Foxy Gestures, are still going to be a bit rough. There's no harm in sticking with FireGestures for now, knowing that replacements are in the works.
(Though it's probably worth letting the Foxy Gestures author know what bits seem to be missing as a FireGestures user.)
Use Firefox ESRv52 with XUL support until June 2018 https://www.mozilla.org/en-US/firefox/organizations/ Pale Moon started a fork of the current XUL-based Firefox. Hope it will be popular. I hate XUL but a lot of people love it. I hope it will live with Pale Moon. Why would you use Vivaldi? A browser is a very personal tool, why use proprietary software for it?
What particular change is responsible for the performance improvement seen in that benchmark? Not anything related to Quantum/Servo surely; I expect those benchmarks to reflect Javascript performance exclusively, and I haven't heard anything in a long time from Mozilla regarding Spidermonkey improvements.
This work has been ongoing; a bunch of it landed in 53, more in 54, and more has been landing since. What makes it a bit harder to advertise is that it's aiming at reducing performance cliffs and improving the chance that real-life code lands on fast paths, not on improving the performance of those already-fast paths. WebAssembly is where the "make the fast bits faster" action is, mostly.
With 30+ extensions installed, It would be nice to list incompatible extensions in the about:addons page. From about:support page, I see Multiprocess Windows 0/1 (Disabled by add-ons)
> switch to Firefox earlier this year ... I couldn't tolerate the poor performance
Everyone still seeing poor performance in Firefox 54, I personally would recommend to do a Refresh: https://support.mozilla.org/en-US/kb/refresh-firefox-reset-a... because usually it is an old add-on or wierd setting that causes it. At least it was in my case, and after Refresh firefox was running very fast
I don't understand what you people are seeing who make these performance complaints. I switched to Firefox last year because Chrome was giving me a lot issues (often hanging and crashing when I had many tabs/large pages open). So far Firefox has been working like a dream for me.
On a core i7 with 16GB and a completely fresh Windows 10 install that has never had Firefox on it (so we can't blame an old profile on the machine), Firefox with a single plugin (Keefox) is noticeably slower than Chrome. Just logging into my Google account I saw surprising amounts of basic UI stuttering. Something like Inbox (which is admittedly a pig) loads slowly and scrolls sluggishly.
Chrome, by comparison, is responsive and snappy.
I wish it were different. I really want to like Firefox, but on this machine, with some very basic tests it's clear that, for me, it simply does not compare...
I've often read FF is faster, HN is one of the few places I see Chrome being called faster. Maybe it depends heavily on the number of tabs and which sites are loaded? For me FF, whenever I tried switching, was always way slower and prone to freezes. But then I have 32GB Ram, 5 tabs always open (pinned), between 3 to 20 extra tabs at the same time and quite the number of extensions.
I've switched to Firefox full time (unless using F12 tools) - Electrolysis helped a lot. It has gotten very much faster and snappier, while Chrome feels laggy, particularly when closing or switching tabs. I've tried disabling all extensions, but it didn't help.
What about Chrome's dev tools do you find preferable? I tend to find myself hampered by lack of functionality like easy replay of network requests, and don't spend a lot of time in Chrome's toolset for such reasons - I'd be interested to hear a different perspective.
At least for my case, I found that Firefox debugger would sometime hang for a bit. It was slowing me down. I'll definitely give it a shot on my next JavaScript heavy project.
I had the same trouble with complex applications in Firefox 45, but haven't encountered it since then - 51 and since have been much more performant in general, and that goes for devtools as well. (I suspect it may have something to do with https://wiki.mozilla.org/Electrolysis/Release_Criteria/Jank#... - but that's just a guess.)
I've been using e10s for quite a while now. Yes, its great that they have reduced memory consumption by a huge margin. Unfortunately, I still feel page load times, scrolling, overall snappi-ness of chrome (I use ungoogled chromium) or overall browsing experience are way better than Firefox.
Servo looks super fast, but they don't seem to want to just rip-out Gecko and put Servo in there, just replace bits and pieces over time. I think that's a mistake, despite the hurdles of doing that, and especially if the end result in terms of performance is something like 60-70% of Servo as opposed to 100%.
It would have been hard for us to get the real-world battle testing needed to get Servo's style system into shape without rolling it out in Gecko.
https://github.com/servo/servo/pull/16971 is an example of Bobby Holley, a Gecko developer (who's awesome, by the way) landing almost a full rewrite of the multicore scheduler, making tons of sites faster in Servo.
Car analogies (and generalizations in general) are not so useful.
I've seen many cases (and been frustrated) working in a corporation where high levels of caution end up creating much more total work to make changes incremental. And when you do finish, the code is often not is nice as if it had been all done at once (at which point it probably gets left as is as more important things than refactoring, in the eye of business people, come along).
Features like the updater / appmanager, which is borderline malware and one of the reasons I uninstalled Chrome (and boy did it take some effort). Regardless, Chrome is not fully opensource, so there is no way to "calculate" the % you mention. Google might be running a bitcoin miner in Chrome and you would have no way of knowing.
The degree of trust required to run Chrome is equivalent to the one you need to run Vivaldi; the only difference is who you trust (Google vs a bunch of ex-Opera developers). If you don't trust anything that is not opensource, you shouldn't run Google Chrome - you should run Chromium or Firefox builds published by trusted parties.
But that would prevent Google releasing the closed source Chrome.. And if khtml had been GPL apple couldn't have released the closed source Safari browser based on it - which would have meant that webkit might never have become mainstream - and chromium probably would have never even existed.
This isn't the entire source code. It's just the changes that they've made directly to Chromium. They can still bundle all kinds of closed-source stuff alongside that, just like Google does with Chrome.
For a more detailed, albeit less well organized, view of functionality yet to be added to the WebExtensions API, there's also the relevant Bugzilla whiteboard [1].
The tl;dr: is that, compared to the XUL API, WebExtensions provide a very limited set of functionality, such that many existing XUL add-ons can't easily be reimplemented in or ported to the new API. On the other hand, it's early days yet, and there appears to be a reasonable amount of interest and developer support devoted to extending the new API so that it offers capabilities comparable to the old. I'd imagine it'll probably be next year this time, more or less, before the dust has largely settled.
It baffles me that they would force-disable legacy extensions without having supplied feature parity in the API. There are major extensions like Self-Destructing Cookies that are one of the reasons that I still use FF that don't have WebEx equivalents. Without these Firefox is Chrome with inferior performance.
Is there a config switch for enabling legacy extensions in 57+?
As far as I'm aware, 57 won't include the XUL API at all, whether behind a config flag or otherwise. I'm not sure how updates from 56 will be handled - one hopes users on the Release channel, who have add-ons the update will break, won't just find themselves hosed by surprise. I haven't heard much of anything about how that actual process will be managed, though.
(Self-Destructing Cookies looks like it could be reimplemented on the WebExtensions API, but the dev doesn't seem to have any interest in doing so. That's a shame, but it doesn't mean no one else will do it.)
I don't blame Mozilla for pulling the trigger this way, though. Opening the roadmap for general community discussion and veto would result in endless bikeshedding, and users unwilling to abandon XUL add-ons in November have the option of sticking with 52 ESR or just not updating past 56 for a while. Conversely, waiting for feature parity with XUL would mean probably another three or so years before e10s hit stable, and Firefox is already three or more years behind in that regard - that much more delay might well not be survivable.
It's not a great situation to be in, but I can't see how Mozilla could've found a better option than the one they chose, and I say that as one who will lose some cherished add-ons in the transition - but if it's that or switch to Chrome because Firefox is too slow to be usable, I'll take the former, and I was strongly contemplating the latter before e10s became a thing. I doubt I was the only one.
Content scripts can access the window object of the page in which they're injected, so that shouldn't be an issue, I don't believe - if the page in which a content script is running can remove data from localStorage, the content script itself can, too.
One of the reasons I use that extension is that it deletes things a short while _after_ the last tab for a site is closed (so they undoing the close lets me keep going). In that case there's no content in which to run scripts.
It's not at all baffling seeing the recent history of firefox dealing with extensions.
Back in the day, when xul extensions were the way to go, things were great, for years the api was reasonably stable.
Then xul extensions were to be replaced by things created by the addon-sdk. To make things more interesting the addon sdk used a python based tool first, later to be replaced by node-js tooling. So (minor)rewrite needed, even though legacy xul extensions still worked as well.. But not for long, noo, for no good reason (because there was already talk of webextensions in firefox), extensions suddenly had to be signed and often MANUALLY reviewed, xul no longer allowed, perfectly fine extensions would not pass automatic review and would not be manually reviewed for no other reason than using legacy code that was hard to review.
So this meant extensions had to be rewritten to use the addon-sdk and jump through hoops to avoid using javascript libraries that caused the automatic review process to break. This all happened a good year ago.
Now, all these addon-sdk extension have to be rewritten once again, because webextensions.
This whole extension review process for addon-sdk, imho, should never have happened and should simply have been postponed till webextensions are ready (they aren't now, they are buggy as hell, yet currently extensions have to be webextensions in order to be published...). As a matter of fact, the whole addon-sdk should never have happened and mozilla should have moved to webextensions immediately.
To me firefox greatest strength was how moddable it was. Not only is this advantage lost by moving to webextensions, the horrid process from xul to addon-sdk to signing and broken review to webextensions must have cost them much goodwill from extension devs. And yes, it has tainted my view on mozilla, i think they honestly mean well, but they desperately need better management that doesn't jump on any hype laden bandwagon, right now they seem to be pushing out new toys that are watered down half functional versions of what used to available. Google might have a name to abandon their projects, i now have the same level of fate in the continuance of any mozilla project.
> As a matter of fact, the whole addon-sdk should never have happened
I agree, but there's a bit of hindsight there. Several years ago, basically, Mozilla people looked at the explosion of Chrome extensions and thought "we are too slow, making an extension is too hard, we need easier onboarding". Hence the addon-sdk project, which itself had a few false starts iirc. It might have had to coordinate with work on FFOS, so that might be the reason it took too long to come to fruition. Whatever the reason might be, by the time the SDK was ready Chrome had run away, making WebExtensions a de-facto standard, so they had to start all over again.
Agreed, using Firefox without Self Destructing Cookies after all those years would feel like swimming without water. It's going to make the browser way less appealing: having to explicitly logout or clear tracking cookies from any untrusted site (almost all of them) as if that couldn't be automated. Sigh.
Is there a similar extension for any other browser?
If tracking cookies are your concern, I can recommend uMatrix: It's basically a rule-based firewall for requests (like an adblocker on steroids). You can declare rules like "filter all third-party cookies, except $THIRD_PARTY_DOMAIN on $FIRST_PARTY_DOMAIN". It can also be used to block JS, XHR, frames, etc., but if you only need the cookie filtering, you can set the rules for those request types to "allow all".
> AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet.
I'm not familiar with the release timelines, but I hope they keep that up at least until they stop supporting Firefox 52 ESR. I switched to it explicitly to keep my XUL add-ons working longer while the add-on makers/Mozilla catch up with the new API.
A potential problem with the force-disabling in 57 is that the only way to hand over configuration from a legacy addon to its successor WebExtension is to preemptively for the legacy addon to convert their configuration. If you only irregularly use your Firefox, the configuration conversion is not guaranteed to run, as you would have to open your Firefox to trigger that.
Does this include the pausing of videos opened in a background tab until the tab is first focused? I recall that it was held back from the expected FF 53 release and expected in 54, but I'm not seeing anything about it.
Edit: Just tested, and it seems like this is not included yet again. Will it come out in FF 55, in... 6 weeks?
Edit 2: Not sure if this would reach anyone who can fix it, but heads up that both links about the multiprocess firefox point to the Mozilla blog, not to medium as stated in the second link. Is it supposed to be this page linked to from the blog post? [0]
Edit 3: Plenty of people seem to be suggesting this is available already. I think that has been the case for awhile now, but not by default. It was something that was mistakenly specifically called out in the release notes for 53. I thought it was a much large discussion thread, but this is the comment I was recalling [1] with a reply linking to the bug report [2] which claims it was added to the FF54 release notes 3 months ago, but has seen action since including discussion in another bug just two days ago.
I don't know if it is surfaced in about:preferences, but I know the functionality exists in Firefox 53 at least, since that's what I'm using now (32-bit 53.0.3, Windows).
In about:config, look for media.block-autoplay-until-in-foreground.
They really need to work on usability for the regular end user if they want to succeed. So many useful settings are buried deep down in about:config. The auto play settings should be super accessible.
Some buggy video players are broken when the browser doesn't autoplay "autoplay" video because the player's play/pause state doesn't match the browser's. Firefox developers are looking at workarounds like telling the player the video is playing, but not downloading the video.
You can set about:config pref "media.autoplay.enabled" = false to test. YouTube used to be broken. I don't know if it still is.
I'm not sure why "don't autoplay until tab focused" works but "don't autoplay on current tab" does not. btw, I use the "YouTube High Definition" Firefox extension, which allows you to prevent autoplay and tweak other YouTube parameters such as disabling overlay messages and forcing a default video size:
I suspect it's because the transition between one playlist video and the next triggers the autoplay-prevention code path. "Don't autoplay until focused" wouldn't, because if the tab hasn't been focused then the video's not playing at all, and if the tab has been focused, then autoplay is (I think) permitted without further restriction.
I don't know the internals of Firefox but this should be relatively easy to do and have real benefit to the user. Squeezing out 30 percent from from JavaScript doesn't make that much of a difference in comparison.
Surfacing "disable autoplay until tab is focused" benefits those users who care about it. Improving Javascript performance by 30 percent benefits everyone.
It's also unlikely to be worked on by the same group of developers, so this is of the "why don't you do x instead of y" class of comment, where x = {fix media playback,cure Ebola} and y={make JS run faster,send things into space}.
On the other hand, at least it doesn't take installing an extension, the way it apparently does in Chrome and Opera. (Safari, too? Webkit seems the common thread here.) Failing to surface it to the user is an odd decision, but perhaps still preferable to what's apparently the typical alternative.
> at least it doesn't take installing an extension, the way it apparently does in Chrome and Opera
Eh? This has been default in Chrome for ages based on my experience. I was actually surprised that it wasn't the default behaviour on FF when I made the switch a couple months back.
Oh, I see that it is - I'm mixing up "disable autoplay until tab is focused" and "disable autoplay, period".
Apologies for the confusion, and thanks for the catch! I'd edit my prior comment to remove the error, but that would make this subthread incomprehensible, so I'll leave it as it stands.
I've been using Nightly for as long as I can remember, and I'm surprised to hear that this behavior hasn't made it out into stable yet. It's a very lovely feature that makes queuing up dozens of videos a breeze. Frankly I thought it was a change on YouTube's part, not Firefox's.
It's been in stable for a while - I think I first used it in 51, although can't confirm since that's no longer installed on any of my machines. It just isn't in about:preferences.
I have five addons installed (uMatrix, Decentraleyes, vimFx, etc.), and none of them block multiprocess. If you read something like this in your about:support, you better start shopping for multiprocess-compatible alternatives (e.g. I replaced Vimperator with vimFx because Vimperator's architecture and scope is fundamentally incompatible with multiprocess from what I've heard).
I recently switched back and Firefox has been much more responsive. It feels great all the time now. I was using Brave for a while, but suddenly performance took a hard dive.
<input> elements of types checkbox and radio with -moz-appearance: none; set on them are now non-replaced elements, for compatibility with other browsers
This means that checkboxes and radio buttons can finally be styled like regular HTML elements. Goodbye label hacks.
Edit: I believe my comment here was incorrect. Apparently we only rolled back support for `appearance` and `-webkit-appearance` (and a few associated changes), but `-moz-appearance` does still work as described above. Original comment follows:
Looking at the Addon Manager, it's pretty grim. About half of the extensions I need are not compatible with multiprocess. That includes stuff like img2tab, it's all text, live http headers, rest client, tabtrekker, pinboard... I guess the migration will take a while.
You may want to check the detailed reports using the "Add-on Compatibility Reporter" extension. I found that the default indication is very conservative, and I used several extensions that were initially marked as not compatible, but actually worked well.
So for the incompatible ones, particularly if they're rather niche (= not many people tried them with electrolysis), you may want to force multi-process and try them. And don't forget to make a report using the Reporter add-on, whether it went well or not ;)
Go to about:config and add the weirdly-named boolean "browser.tabs.remote.force-enable", set to true. Restart FF.
Addons won't be disabled, but they might not work properly. If you see misbehaving extensions, install the Add-on Compatibility Reporter extension, then report by either:
* going to the Addons/Extensions screen and clicking "Report Issue" near the misbehaving extension
* clicking on the green puzzle piece now in your main toolbar, clicking on the X near the extension name, and then hitting the Submit button at the bottom.
The latter will also send a report saying the other extensions are actually good, so I would do it only after making sure you've somewhat tested all of them.
(All this was learnt today by insistent experimentation; the Addon Compat Reporter could do with some extra documentation or hints on what to do.)
How does Electrolysis perform when compared with firefox with a single process when using many (500+) tabs? Do tabs that have not been loaded yet (such as when using the click-to-load feature for tabs saved from previous seasons) use their own process?
The overhead is minimal since we're not doing process-per-tab: we cap the number of processes to 4 by default. So if you have 500 tabs, loaded or otherwise, you're not going to have 500 processes. I believe we spin up the processes on demand, so if you have 499 unloaded tabs and 1 loaded tab, you should only have one content process, but I'd have to source dive to confirm that.
Please DO process-per-tab. I have a lot of memory. I want you to use it. If it's not enough, I will buy more memory or a stronger device. But please, whatever you do, don't make security or stability trade offs for me. The M:N threading model has never worked out. We know 1:1 works. Please do that. Please, please, please use a process-per-tab.
Why?
You can change the number of processes to e.g. 1000 and you will basically get one process per tab until you reach 1000 tabs, and if you do, you will need really a large amount of memory.
one process per tab is specifically why I quit using chrome, it wasn't working even for small amount of tabs (100) it ate RAM like crazy. Mozillas approach is better, user can control how many processes are created - users have control.
It's simple. There is no way Firefox can guarantee anywhere near the level of stability and security Chrome offers without a process per tab. OS primitives operate in terms of processes (scheduling, memory, sandboxing, and so on) and Firefox will not be able to use any of them. I really want to use Firefox, but I'm almost certain not doing a process-per-tab will be the last nail in its coffin. The code will be more complex to maintain, and no advantages in security or performance will be gained, leading to less users and thus less maintainers.
If there was one thing that caught my attention with Chrome back when it was released (2008?) it was its reliance on OS primitives (processes) as the building blocks for a stable and secure browser. This is essentially the same argument the Varnish folks did when comparing to other proxy solutions like Squid back in the day. I don't understand why Firefox is taking this route.
> There is no way Firefox can guarantee anywhere near the level of stability and security Chrome offers without a process per tab.
It has no security benefit without Site Isolation (which isn't unconditionally a process per origin either for performance reasons). In both Chrome and Firefox, any site can embed another cross-origin site in an iframe, and it will share a process (and a main thread).
Chrome does not use an unconditional process per tab. Nobody would.
Go to about:config and change dom.ipc.processCount to a high number. You'll get the behaviour you want.
Four is a reasonable default, especially given that multi-process is so new. It's possible that the default number may increase in the future, but that will depend heavily on memory usage.
My counter-point. Please DON'T do process-per-tab! I don't have a lot of memory (just 8GB, of which a lot is consumed by other applications running concurrently). I don't want Firefox to become like Chrome (with several processes - not necessarily process-per-tab, as clarified by others) and become all sluggish and slow down the system just because I opened 50 tabs (I open many more tabs normally)! For me, Firefox has always excelled in handling tons of tabs compared to Chrome. I'm also sure that the Firefox team is aware of the trade-offs and has thought through this for a long, long time.
Not to do process-per-tab and 500 tabs. Each browser process is several tens of megabytes, somewhat unavoidably (that's assuming you do some sort of embryonic startup and then forking so const non-relocatable data can be shared; if you don't it's a lot more). So on pretty much any consumer hardware you would be constantly swapping at best.
Which is why there is not a single browser that does process-per-tab. Chrome certainly doesn't: once you have more than a few tabs they start multiplexing them across processes.
>Please DO process-per-tab. I have a lot of memory. I want you to use it.
I hope that you ask them to add it as an option instead of replacing the current model. Firefox already uses my 8GB memory quite easily when I have many tabs open.
It is available as an option. "dom.ipc.processCount" in about:config allows you to set the maximum number of processes that it'll use. Set it to something like 1000 and it'll use a separate process for each tab (unless you actually open up 1001 tabs).
They are also working on a UI for changing that max process count (don't think that's in Firefox 54, but I could be wrong), but that UI currently only offers values 1 through 7, as it's just really unlikely that a normal user would actually want to sacrifice their RAM like that.
We also finally turned on "offline cache" support in Firefox For Android (for 50+ releases) - if you have a page in your cache, and you're attempting to load that page while offline, it should "just work". See https://bugzilla.mozilla.org/show_bug.cgi?id=1232867
Firefox Portable is a portable package for Windows, so you can run Firefox without altering any local browser installs or leaving personal details behind. It's a fantastic way to run multiple versions side by side with independent profiles for testing both websites and extensions. All versions of Firefox are available including the latest Developer Edition, Beta version, Extended Support Release, and Nightly releases. All packages are open source under the GPL and totally free. And you can test alongside portable packages of Opera, Iron, Maxthon, and SeaMonkey as well as the three main channels of Google Chrome (Stable, Beta, Dev).
We have to weigh the potential risks against the potential benefits of a quick rollout and try to come to a balanced decision. If we see a problem from feedback from early installs, then we have a chance to quickly patch it and re-release, sometimes within one day. Staged rollout is fairly standard in the industry. (Speaking as a Firefox release manager)
Indeed, a botched rollout can lead to users disabling automated updates (see: Microsoft's GWX). Even if all you care about is security, you have to balance the risk of not patching quickly enough with the risk of the user disabling your ability to patch in the future.
Patches for many of these issues have been public already for a few weeks, so waiting another day or two won't cause much additional harm. The CVEs do not contain test cases.
There are times when we update users as fast as possible, but that's fairly rare and happens only when there's an exploit disclosed in public (or one definitely being used). So in addition to the security ratings used by Mozilla (defined here: https://wiki.mozilla.org/Security_Severity_Ratings) there are also "incidents" that result in a very fast release to all users (i.e. "chemspill").
Not a single one of those shows a vulnerability. Every one says the bug "could be" exploitable. All software has potential vulnerabilities. The trick is to roll out completely before they become actually vulnerable. That doesn't mean you have to roll out dangerously quickly.
Great work, but unfortunately I had to restart 3 times as the partial update failed and the full update had to be applied. I'm sure this could be done automatically without asking the user to restart 2 more times, right?
I'm curious -- if this is basically a scheduler for tabs onto system processes (which it seems to be), what's the impact on input latency? I've read in multiple places that Chrome's input latency is worse than it could be because of multiprocess, so I'm really interested to see some input latency benchmarks.
Additionally, how are tabs sharing the same process isolated from one another? Chrome uses Linux namespaces for each of its processes, and this keeps tabs separated by a sandbox that requires a kernel exploit to break out of, how does Firefox's sandboxing work within a process?
I'm not familiar enough with our in-process isolation to summarize it, but https://wiki.mozilla.org/Security/Sandbox is an good trailhead for the process-level sandboxing in Firefox.
Love it, after an day of use, feels snappier, more responsive definitely on my "old" 2010 mpb. Also love the new compact theme, feels really slick with these improvements.
Had to give up Chrome on this machine because it kept crashing my machine, and go back to Firefox, but I'm happy of the improvements they are constantly making.
Though managed to crash my browser by runnign a heavy javascript application in one tab already. But that would lock up the previous one also.
Mozilla needs to stop chasing Google in this never ending quest to turn Firefox, quite literally, into the winning combination that is Chrome.
Just because Chrome is a winning formulation, doesn't mean it is the only one. My armchair example is themes... both chrome and ff now look like alien invaders of corporate identity on my desktop. While that makes sense for Google, it hurts Mozilla's image with the community of hackers/tinkers that love Firefox for features just like that one; features that quietly say, "its your browser, you likely know best". Especially because themes worked reasonably well for so long(at least from the users perspective, I'm told the implementation was fragile).
Maybe its time to go all in on the hacker community and make Firefox, a "Linux first" browser. The PC market shrinking, no one is arguing that. Trying to squabble over pieces of an ever shrinking pie is not a recipe for success.
This is especially true for Mozilla. All its competition can simply forget about their browser products and still be profitable. A failed Firefox likely means Mozilla disappearing for the digital landscape.
I propose that the Linux/Hacker community is the logical conclusion of PC itself and, by proxy, the PC browser market. Long after everyone has gone tablet or whatever, the last hold out of the PC market will be the Linux diehards, why not cater to them from the get go? You are going to be catering to them when all is said and done.
As a tangent, a great starting "performance feature", which is what all this e10s stuff is getting at, would be vaapi support for hardware accelerated video on linux. You can't really call your browser fast when it chokes the CPU on any 4k video. The the only browser to currently support it on linux... sigh... chromium.
I don't know, in many ways that's exactly what the original Mozilla was, to little success. When the project steered to Phoenix / Firebird / Firefox and focused on Windows, things improved pretty dramatically. I didn't like the "betrayal" of the suite at the time, but it can't be argued that project velocity got so much better afterwards. "Linux first" would be a step back both technically and commercially (after all, FF pretty much own that entire niche already, there is no growth to be found there).
> Maybe its time to go all in on the hacker community and make Firefox, a "Linux first" browser.
Considering that one of Mozilla's funding sources is tie-ups with Google and Yahoo (and others?) for placement as default search engine and getting money from those searches, a "Linux first" strategy could probably become a financial disaster. I'd rather have Mozilla continue to exist (there's no other company/foundation of equal competence and values to "save the web" to whatever extent possible). I'd prefer Mozilla to focus on providing great native experiences on Windows, Linux, macOS and Android (sorry if I missed other larger platforms where Firefox is available and used).
regarding use of hardware acceleration, that's the reason Mozilla is working on Servo, the (only?) browser engine that runs on the GPU - http://servo.org/
Let's go further; I believe Firefox should compete against ChromeOS. The web is the ultimate platform, Mozilla should know that, but now it's more and more Google's platform.
The reality is that Chromebooks and Chromeboxes are great computers for the masses. They're safe, secure, always up to date, no virus. They're great for the elderly, schools, public libraries, etc.
You can buy a 85$ Chromebit dongle you plug into an HDMI port in your TV and you can browse the web on your big screen, watch Netflix, etc.
Seems like Firefox OS should have been like Mint. Build on someone else's hard work (ubuntu or debian), tune it for an inexpensive platform (like the most popular netbook/chromebook/cheap laptop) and then work on on what makes it easy to use and useful. Things like a nice default desktop, integrate some cloud storage, automatic backups, user friendly tutorials, etc.
Generally being incompatible with whatever platforms applications (iOS, android, or debian/ubuntu) is a kiss of death. People need their apps and developers need aren't going to cater to a new minority platform with approximately zero users.
On the other side, Google now require cast devices to have Google controlled private keys so you can't use Chromecast without using Android or Chrome. This means there couldn't be a compatible "Mozillacast" implementation.
This page causes Firefox Nightly to spike in CPU and Energy Impact. I notice it earlier with pages with animated gifs on it. So, I installed some extension to not autoplay animated gifs. Something on this page causes the CPU to spike.
> Today's release is the first to run Firefox using multiple operating system processes for web page content, making Firefox faster and more stable than ever.
So it's finally not slow and laggy? I hope someday it can be as snappy as Chrome so I can ditch google forever.
The functionality has been available on an opt-in basis for a while now, and I can confirm that it massively improves Firefox's performance and responsiveness. Whether it's "as snappy as Chrome" is a separate question; I've never found that browser as responsive as seems to be the general experience, so I can't really speak to the comparison, but I certainly can say that Firefox itself is much more comfortable to use with e10s enabled.
I've found Chrome as buggy and unreliable as it's been fast and responsive. I actually switched to Firefox on my Windows PC because Chrome just stopped rendering properly (not just rendering HTML, the entire window was broken). I also have to turn off users' hardware acceleration at the office so that their 'my tabs go blank!' bugs stop happening.
I get a lot of weird graphical glitches with Chrome on Windows 7, too - something about the way it draws its windows doesn't always play well with DWM, so they'll leave bits of themselves behind when dragged, or flicker weirdly when dragged across display boundaries, or otherwise uniquely misbehave. Even on machines where the display hardware sucks enough to make graphical oddities relatively common, Chrome stands out in the frequency with which they occur.
I'm giving it another shot now that Electrolysis is there. I've only been using it for half an hour now, but my initial experience has been promising.