71–80 of 107 posts
I tried it myself. Most of the bugs that are there explained in that wiki page aren't really occurring (I guess they were fixed in the meantime), but I noticed creating and destroying new tabs was much much slower, and that made me disable it.
There are certainly some performance things to iron out. Right now, we're just trying to make the base browser functions work properly, and then we'll start tackling the performance problems.
Realistically Speaking, I think this is still at least another 6 months to 1 year away from moving to Aurora or Beta Channel.
I'm really glad Mozilla has been working on this. A lot of comments here talk about UI responsiveness being the key benefit, but another huge win is that it limits the damage a browser zero-day can do. With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. This of course assumes a compromised tab can't go on to compr…
> With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. ... assuming those tabs are cross-origin. > This of course assumes a compromised tab can't go on to compromise the browser kernel Also assumes that a compromised tab can't go on to compromise the OS kernel.
Not sure why this has to be a condition. Perhaps tabs loading pages from the same origin will both have read/write access to some shared data in the browser kernel (like the site's cookies), but they still run in separate address spaces regardless. A compromised tab won't be able to directly access another tab's RAM, as is the case with single-process browsers.
> Also assumes that a compromised tab can't go on to compromise the OS kernel.
Very true. However, my argument was that a multi-process model limits (but obviously does not eliminate) the impact of zero-days. In the single process model, the attacker could compromise any tab and have all tab state available with no additional effort. In the multi-process model, the attacker would have to compromise the right tab, compromise a different tab and trick the browser kernel to performing the requisite operations, or somehow bypass the OS's memory protection. Each of these require more work than before.
Earlier quoted context omitted.
This makes sandboxing possible which is a huge security win and the reason I still use Chrome where I can. RAM is cheap and browsers 64-bit so a bunch of extra memory in the name of security is not a big deal really. At least that's how I see it.
>RAM is cheap Great, buy me another 32GB then please . People shouldn't have to have high end gaming rigs to run a sodding browser. Mozilla (and google) are deluding themselves in thinking that their particular software is the be all and end all of a computer, and should be introduced to this strange concept called 'multitasking'. Firefox: 1.5GB Thunderbird: ~1GB OS: 1GB (conservative estimate) Various background pro…
Here's a thought for developers: Next time you find yourself saying "RAM is cheap" (or any variation thereof) thwack yourself about the head multiple times with a big stick, then go rinse your mouth out with soap and water.
Earlier quoted context omitted.
I am not questioning reasons to have 200 open tabs, but wonder how do you manage it? I would imagine tab bar become very long?
It helps that Firefox offers to change to an existing tab when you try to open the same page in a new tab. Another suggestion is to not manage it. I create tabs all the time, and often have many similar tabs. There's no need to manage it, only to clean up once in a while. (I like many tabs. A few weeks ago I performed some tab-cleaning -- 550 tabs were a bit much, as it made Firefox start slower.) Personally i just u…
I find it essential to manage the mess that is my Chrome tabs.
Earlier quoted context omitted.
> With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. ... assuming those tabs are cross-origin. > This of course assumes a compromised tab can't go on to compromise the browser kernel Also assumes that a compromised tab can't go on to compromise the OS kernel.
> ... assuming those tabs are cross-origin. Not sure why this has to be a condition. Perhaps tabs loading pages from the same origin will both have read/write access to some shared data in the browser kernel (like the site's cookies), but they still run in separate address spaces regardless. A compromised tab won't be able to directly access another tab's RAM, as is the case with single-process browsers. > Also assum…
Because they can share JavaScript objects.
Earlier quoted context omitted.
> ... assuming those tabs are cross-origin. Not sure why this has to be a condition. Perhaps tabs loading pages from the same origin will both have read/write access to some shared data in the browser kernel (like the site's cookies), but they still run in separate address spaces regardless. A compromised tab won't be able to directly access another tab's RAM, as is the case with single-process browsers. > Also assum…
> Not sure why this has to be a condition. Because they can share JavaScript objects.
Earlier quoted context omitted.
> Not sure why this has to be a condition. Because they can share JavaScript objects.
Sure, tabs can load static assets from a read-only cache instead of re-fetching everything from the origin (be it an in-browser cache run by the browser kernel, or a Web cache somewhere between you and the origin). But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? When would it ever make sense for multiple tabs to directly access each other's runtime sta…
No.
For example, you can get direct access to another tab's "window" object in this way, as long as it's same-origin: https://developer.mozilla.org/en-US/docs/Web/API/window.open...
> When would it ever make sense for multiple tabs to directly access each other's runtime state?
For Web compatibility.