The author justifies introduction of e10s using an example of inter-tab CPU contention. Yes, this is a real problem, I experience it using Firefox. But for that particular issue, a sufficient solution is multithreading.
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.
Have you ever seen the source base of a browser like Firefox or Chrome? You must do small incremental improvements if you want your software to continue to work. The hardest part is disentangling everything from a single process architecture to multiprocess. That's what they're doing now. Switching from a single content process to multiple content processes is significantly easier.
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.
Yes, but few lines below they wrote: "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)."
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.
I'm not aware of any browser that implements "per-tab content processes". For example, Chrome caps the number of content processes and multiple tabs in Chrome start sharing the same content process once enough tabs are open.
Technically speaking, it's a lot easier to do a separate process per tab, and let things crash just like any other running process. If they don't stop there and try to actually manage processes by themselves according to some messed up logic, then yes, I agree with you that there's no point to e10s and probably Mozilla.
> and let things crash just like any other running process
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 stopped using Chrome a couple of years ago because of multiple crashes per day. The browser itself didn't crash, but individual tabs did. Or else Chrome tabs failed to load (giving just a pale blue background) presumably because it had run out of RAM.
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.
e10s will bring some security and stability benefits. If one webpage crashes, all webpages crash, but you can click to reload. Additionally, this enables sandboxing, so that code from webpages can be run with lower levels of access. Sure, it is not perfect, but it is a large improvement from the status quo.
(Even process-per-tab is not perfect for security: a compromised page from one origin could open an iframe to another origin.)
They say that they want to move to multiple content processes, so I guess that their end goal is still one content process per tab.
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.
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...