Firefox 48 Beta, Release, and E10S
asadotzler.com
asadotzler.com
You can manually enable it, though[0]: However, if you want to permanently opt-in, you can do so with a simple pref change. Just go to about:config and toggle browser.tabs.remote.autostart to true. On your next restart, e10s should be active. To verify that it is active, go to about:support and look for a number higher than 0 in "Multiprocess Windows".
I didn't realize they had this kind of fine-grained control over A/B-testing in their Firefox beta population, as Asa puts it: We have all the knobs. I understand where they are coming from, but it feels a bit weird to have a piece of software running on my computer checking in with a remote server to enable/disable functionality.
It might be worth downloading Firefox Developer Edition (which uses a separate profile) and installing your usual suite of extensions to check they all still work.
The only extension I personally know is weird under E10S is "It's All Text", where the edit button doesn't appear on textareas until you switch to a different tab and back. Other extensions like uBlock Origin, Tree Style Tabs, Open In Browser, HTTPS Everywhere, Document Font Toggle all work fine.
https://addons.mozilla.org/en-us/firefox/addon/lastpass-pass...
I'm running:
Lastpass
uBlock
Zotero
I hope that gets fixed. That's one of the most useful extensions I have installed, and about the first thing I install when starting afresh in Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=1100918
The Vimperator developers are working on it here:
http://www.tomshardware.com/news/firefox-improves-security-n...
I wonder if they're isolating E10S to stock-Firefox as means to avoid too many interactions while debugging or some other reason. I don't even wanna ask why they're still supporting Windows XP...
Here’s what that looks like. When we launch Firefox 48, approximately 1% of eligible Firefox users will get updated to E10S immediately. The 1% of release users should get us up to a population similar to what we have in Beta so we’ll be able compare the two. About ten days after launch, we’ll get another round of feedback and analysis related to the release users with and without E10S. Assuming all is well, we’ll turn the knobs so that the rest of the eligible Firefox users get updated to E10S over the following weeks. If we run into issues, we can slow the roll-out, pause it, or even disable E10sS for those who got it. We have all the knobs.
I'm asking because I might have a bit of a problem with my tab addiction (my phone regularly reaches 60+, my laptop or desktop probable sit around 2-3 times that for weeks at a time) and I don't think that'll translate well into a process-per-tab model.
Yes, I know about bookmarks, read-later tools and that this isn't the healthiest habit.
More info in the e10s-multi bug and its dependencies:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=e10s-...
(also a nice way to look for known issues that might affect you if you're interested in trying out e10s-multi)
The main advantage is that browser chrome is still responsive during rendering. You can switch tabs, open menus, resize windows etc. Also, rendering is a little faster since you don't have to interrupt it constantly to keep the UI responsive. And if the content process dies, all your tabs are still "open" and you can reload the content.
Now that everyone has a multi-core cpu, it makes more sense to not really worry too much about scheduling. The OS will just move stuff off a busy core and onto a less busy core dynamically. So why not just separate the UI front end from the rendering and call it a day? Why bother with so many processes when you have cpu cores to spare? The UI and renderer will run in their own cores when they get too cpu hungry. Also, if the renderer crashes, no biggie, the UI just re-renders everything.
Also, you gain memory savings as you aren't spawning all those processes which have redundant libraries and such loaded.
It has a model of one process per tab until you have enough tabs, then tabs start sharing processes based on various heuristics.
If it's as messed up as it was back then, it looks like I'll be having to switch broswer. I have a similar usage pattern as yours, with the added disadvantage that I group my tabs in windows, and every window seems to carry a big overhead.
Btw, I'm not "memory constrained", I always have 2 to 5 GB free memory, but once the firefox process is over 1,5 GB then trouble begins, at 2 GB it's about to crash, and over that it can sometimes survive as large as 2,5 GB, but I've never seen it use more -- it always crashes before reaching 3 GB.
Was this for a 64-bit build of Firefox?
It's 2016 now so maybe it's time to upgrade your box and it's 4 GB of RAM.
EDIT: How is Firefox eating up to 3Gb of RAM on your machine? I never seen mine go over 1.5GB and that's been after a week of not closing it (64-bit version/no Flash installed).
Personally, I would reevaluate how you use browser.
I just restarted FF an hour or so ago, and haven't even had it reload most of the tabs that used to be open (FF restored them, they're just not loaded yet as I haven't tabbed to them), and I'm already at 1.5GB resident with probably 15 active/loaded tabs.
They also go on to say that "After that, we’ll be working on support for multiple content processes.", so I assume the plan is to have one perocess-per-tab eventually. I'm surprised they aren't there already though, considering this has been in the works for a few years now.
As for process-per-tab, I can't find anything official about it on the bug tracker. The problem with that option is it leads to quite high memory usage, and hides the existence of memory leaks (chrome really likes to eat my ram). We'll have to see how memory usage goes as they experiment with multiple content processes.
source: https://www.reddit.com/r/firefox/comments/4hmii4/firefoxs_ap...
They're first going to do two processes, probably for debugging without too many moving parts, then multiprocess. See https://wiki.mozilla.org/Electrolysis#Schedule_and_Status and https://wiki.mozilla.org/Electrolysis/Multiple_content_proce....
According to the wiki page you linked, it doesn't seem to be the goal for them:
"The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either."
If this is true, I don't see any advantages of e10s introduction.
Basically, beforehand when you turned your scroll wheel, Firefox first sent a scroll event to the webpage, then the webpage could execute whatever it needed to execute on scroll, and then Firefox actually scrolled the page. With APZ, that's now handled in parallel, i.e. it already scrolls what's there and alters it at the same time with whatever the webpage wants to do on scroll.
This also applies for zooming the page, as you might have guessed from the name, and as far as I can tell also to resizing the window.
Other than that, all animations in the browser UI are a lot smoother, too. For example, I can now just hold down Ctrl+T (which opens new tabs) and it happily chugs through playing the tab-animation hundreds of times with seemingly the only limiting factor being my screen's refresh rate. (And that's on a below-average laptop.)
That said, memory usage isn't my biggest concern, I generally have no shortage of memory, and don't particularly care if my browser is using 1GB of RAM. If this improves stability and performance (which seems to have gotten much worse recently on OS X in particular), then it's a fair trade off.
How do people get work done WITHOUT having 50 tabs open? It's a pretty regular occurrence for me, between having MSDN, the PostgreSQL handbook, documentation for a half dozen libraries, my "read later" list, etc., there's almost never a day I am not drowning in tabs. Thankfully, the Tree-Style Tabs extension saves the day here!
It is a breeze. http://kb.mozillazine.org/Browser.sessionhistory.max_total_v...
https://it.slashdot.org/story/16/02/12/034206/pwn2own-2016-w...
Chrome is at best visible source – Google controls development, not the community – and the others are even fully proprietary
Great fucking world.
Which is hard to do when Google competes unfairly, even illegally – which they did, for example with using AdSense for Chrome ads everywhere, and not paying website owners where the ads were displayed the normal rates, or by adding fraudulent banners "Your browser (Firefox) is outdated, upgrade to Chrome now" to Google Search.
You could say that without many users, there won't enough real-world exposure, but at the same time, Firefox will also be targeted far less, so you wouldn't have to worry about security vulnerabilities as much.
And while yes, if at some point Chrome becomes Internet Explorer 2.0 and webpages target nothing else anymore, that could cause Firefox to be hardly usable, but that's then an entirely different nightmare and not anymore relevant to the current situation.
With no devs, you can’t implement those features or the security easily.
And especially for security you’ll want fulltime employees.
Also, you’ll have to pay more than Google pays their Chrome devs to ensure the people will keep working for you.
But maintaining a whole OS with a whole virtualization layer, a whole sandbox system, several supported scripting systems, its own scheduler, its own graphics stack, and support for compatibility with any bug a competing system has?
Modern browser are reaching complexities we’ve only seen in whole operating systems before. You don’t see a bunch of volunteers maintain everything from Linux to KDE at once, it’s hundredthousands of people working in a very different way.
To be able to compete against Google, be able to force them to implement features you pioneer, and force them to avoid implementing other features, to be able to keep up with them and reach better security than them, the current Firefox team is not enough.
Chromium is open source, Chrome is open core. Chromium may also be cathedral (rather thean bazaar) development model, but that's only distantly related to open source or not (bazaar is facilitated by open source, but not required for it.)
Google even openly discourages forks, or any contribution that doesn’t fit their ideals.
It’s only truly open if development is controlled by a democratic community, or if it’s easily possible to be forked and competed with.
Which isn’t the case.
And for users open development is a lot more important than open source: Being able to get their own changes into the browser, ensuring the browser is made by the users, for the users.
Google may discourage forks, but there's nothing they can do to prevent one, and forking Chromium is no more difficult than forking any other project its size.
... or any contribution that doesn’t fit their ideals.
That's one of an OSS project maintainer's more important jobs. I used to maintain some decent-sized open source projects, and part of my job was to say "no" when someone wanted to add something I didn't think belonged (for whatever reason).
Forking Chrome would be like fighting against Embrace, Extend, Extinguish after you’ve already lost (which we have with Chrome, compared to what KHTML used to be like)
Regardless, though, there's nothing that says the hypothetical developers of a Chromium fork couldn't devote some time to merging reasonable fixes & new features from upstream.
https://it.slashdot.org/comments.pl?sid=8737473&cid=51495357
No major changes means that there will also likely not be any new security vulnerabilities and therefore they would almost certainly not find anything new.
This does not mean that Firefox is less secure, it just means that Mozilla has not innovated much. And if you look at actual statistics, you'll see that Firefox is not behind at all.
You could maybe make a separate case that this will lead to bad security in the future, as some innovation is inevitably going to be necessary, but with addon signing, E10s, WebExtensions and Servo all up and coming, you'll have a hard time to actually defend that case.
But not talking about development. How can you use a browser that does not allow for tabs to be displayed on the side? Tree Style Tab[2] on Firefox makes it the best browser for me.
[1]: https://www.mozilla.org/en-US/firefox/developer/ [2]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
e10s = electrolysis
i18n = internationalization
l10n = localization
k8s = kubernetes
Origin:
"A DEC employee named Jan Scherpenhuizen was given an email account of S12n by a system administrator, since his name was too long to be an account name. This approach to abbreviating long names was intended to be humorous and became generalized at DEC. The convention was applied to "internationalization" at DEC which was using the numeronym by 1985."
wtf?! It loads fully loads in around 4 seconds for me (Chrome stable x64, Windows 10)
I'm also running uBlock Origin and Ghostery, which is blocking 7 trackers....
The most important one is that firefox opens new windows a few hundered milliseconds too slowly (on Mac OS X). Just a little bit too slowly for me to just hit Cmd+N and blindly start typing a url. I have to stop and pay attention to when the window is ready, hundereds of times a day.
Another annoyance, a much less important one, is that Firefox wastes a lot of screen real estate at the top.
There are OSes with potent window managers. Ideally tabs should even be part of the WM itself† and not be reinvented across each app††, or disappear altogether (e.g Chrome on Android, Exposé/Mission Control per app window grouping)
† possibly even allowing tabs to be a mix of apps
†† features such as pinned tabs, the defunct Firefox tab groups/overview, Vivaldi are especially egregious examples.
And I don't keep windows or tabs open because they are hard to find again and start to pile up. So I open and close them a lot.
I don't use the bookmarks menu directly. I just open a new window and start typing. Either the page I'm looking for is in the auto complete or I hit enter and it goes to the search engine.
To sum it up, I have trouble remembering hierarchies and various navigation and UX ideas that web designers come up with. I have trouble visually grasping what's on a page (it's a kind of disability I always had). So instead I search.
In fact, that's also one of the great things about Firefox. Typing in its location bar lets me find other open windows and tabs. I love that.
Prefix with % and it will return only that kind of result.
Open a new tab, type the address (or clic the thumb) and go.
If you do it on a current tab, you are always in danger to erase your current tab by mistake from mistyping the open in new tab shortcut.
Another thing is that if you have your hand on the mouse, it's faster to click + than to type said shortcut.
What's more, FF can't hold as many opened tab as I wish without slowing down. So I have to clean regularly, and so I reopen tabs I closed 10 minutes ago.
This allows you to ensure that you open new tabs when you want/customises tab behaviour.
That's one of my biggest complains about ff, using chrome somehow feels clean because of this.
Even now looking at the two makes me feel as if ff is some how bulkier, I am looking at the same page, and ff look really huge EVEN IF ITS NOT!!...
That's really odd.
- Firefox: 79px
- Chrome: 72px
- Safari: 61pxThat's about 90% of my browser windows and it makes Safari use only half as much space as the other browsers.
You probably won't have to kill anything new.
If the "Web Content" process is killed while the main Firefox process is running, Firefox asks if you want to restore the tabs - which is half the point of e10s.
"killall firefox" would be easy to do anyway.
Finally. Every browser I use does this when I load a huge reddit thread while RES in enabled.
Well, for that particular problem, there is a much simpler solution than splitting application into two distinct processes. It's called multithreading. Moving UI into a separate thread would not only be simpler than moving it into a separate process, but also wouldn't result in 20-50% memory usage growth.
Multiple threads run in the same process address space. This creates security and stability issues. One website can affect the complete experience. That's exactly the problem they're trying to solve, the same way Chrome did, by using multiple processes. That way, for example, when one process misbehaves and gobbles up too much memory, the OS won't kill the entire browser but just the offending tab. (The OS won't kill individual threads.)
That's shifting goalposts. GP quoted that it's about responsiveness and resource consumption. And resource consumption is obviously lower with multi-threading since more data structures can be shared.
You seem to be throwing a lot of technical terms. Could you elaborate on where exactly do you see overhead coming from in a multiprocess vs. multithread architecture? And which data structures can be shared between threads but not between processes?
Scheduling overhead is identical and pure OS memory overhead is slightly higher for processes (they need more "accounting" data), but everything else can be optimized at the application level. Furthermore, shared memory lets you share data structures between processes just fine (heck, some data can be shared between processes and the kernel!), and since I assume the content processes will be dynamically linked, you're not even going to load shared libraries multiple times.
In theory maybe. In practice data structures contain pointers, which you can't just shove into cross-process shared memory. Which in turn results in copying things and serialization/deserialization overhead when doing IPC.
With multi-threading you can just share regular data structures (think std::map) and put them under locks or copy-on-write logic if they need to be modified.
Of course you can share some large blobs, like pixel data or loaded files. But the major data churn consisting of many small, nested data structures involves copying and (de)serializing.
As you wrote, separating each tab into a different process will bring security and stability benefits. But blog post author does not mention any of them. The only justification for e10s he brings up is CPU-UI blocking problem (which is not a justification for e10s at all, because it can be solved with multithreading).
And there is a reason why he doesn't mention security and stability benefits: They do not plan [1] (at least for now) separating each tab into a different process. All tabs will still share the same content process. This means that e10s would not bring any security and stability benefits you wrote about.
So one may ask: what's the point in introduction of e10s at all? I ask myself this question as well, not only regarding e10s, but also many other Mozilla decisions from last few years.
[1]: https://wiki.mozilla.org/Electrolysis/Multiple_content_proce...
Also, another reason for e10s is to decouple the rendering engine from the UI parts, in order to a) get rid of XUL and b) offer a path for replacing Gecko with Servo once Servo's ready for primetime.
And the same time break tens thousands of extensions (which are the main reason why most Firefox users still use this browser).
I don't understand how you conclude that "they do not plan separating each to into a different process" from the link you posted given it opens with "After e10s is enabled for all users, the next step is to introduce multiple content processes." To answer your question, then, the point of introducing e10s is to make it easier to switch from a single process to multiprocess architecture.
So per-tab content processes (which btw is the only way e10s can result in security and stability benefits) is not a realistic goal for them.
People always say that as if crashes would be a regular thing happening every few minutes. I don't experience browser crashes for days, so I find it kind of odd that such a relatively rare failure case is considered a good justification for using a process per tab.
I used OneTab for a while, to reduce memory use, but still found Firefox more efficient and more stable with hundreds of tabs, mainly because the vast majority weren't actually loaded until I needed them.
It's not hard to crash Firefox -- just keep loading an infinite page of gifs etc. But once you know that, you don't do it.
Under normal working conditions, I agree: none of the main browsers crashes often enough for it to be a problem.
(Even process-per-tab is not perfect for security: a compromised page from one origin could open an iframe to another origin.)
IPC, shared memory, and credentials/descriptor passing are common patterns that exist in tons of software today. OpenSSH, Postfix, probably every iOS app.
Multithreading is great, but it's not suitable for a browser that may be fed malicious code and has a huge attack surface.
Yes, in those simple terms, it would be 1) simpler to coordinate multiple threads in the same process compared to multiple processes, and 2) more efficient too.
1 is true because any system you might use to communicate between processes would involve an IPC layer and with a single process, you could use an identical system with the IPC removed.
2 is true because multiple threads in the same process can communicate directly without requiring IPC (which requires data serialization, shared memory for performance, and more system calls). i.e, sharing data has much higher cost using IPC. You can skip some serialization if you use shared memory, but you still need to set that up and manage shared buffers. (Different applications might share data in different ways so that the IPC overhead becomes negligible, but non-IPC could always be implemented faster.)
But the benefit gained from using multiple processes for a web browser (that is essentially a VM for running untrusted JS/web code) is security in the face of bugs. It comes from how operating systems provide tried-and-tested process isolation. If sites from separate origins are rendered or parsed in their own process, some types of browser bugs are harder to exploit to gain access to data from other origins. And for bugs that just cause crashes without security implications, you can crash a single tab and let other tabs continue, let the main UI continue.
On its own, that is good, but not great.
The big benefit is that the big 3 operating systems that browser developers are concerned with provide some level of per-process sandboxing. For example, one can launch a process with a limited set of privileges such that the only thing that process is allowed to do is communicate via IPC and compute stuff. The operating system enforces this for you. Provided you have a strong IPC layer, a process with such limited privileges can do very little damage if it is compromised.
Developing a strong IPC layer is not extremely difficult as it essentially boils down to reading a stream of messages from an untrusted source and detecting invalid messages without compromising yourself.
> And for bugs that just cause crashes without security implications, you can crash a single tab and let other tabs continue, let the main UI continue.
That's using non-security bugs as an argument for increasing memory footprint. It would be preferable to have those bugs fixed instead.
> Developing a strong IPC layer is not extremely difficult as it essentially boils down to reading a stream of messages from an untrusted source and detecting invalid messages without compromising yourself.
That's implementation complexity. But you also have to consider the performance overhead of proxying method access to arbitrary objects and bouncing each method invocation and its results back and forth. That's needed for backwards compatibility with addon code unaware of the process separation.
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Fir...