e10s / Electrolysis

[snertev]

More info about multiprocess implementation in Firefox:

https://mail.mozilla.org/pipermail/fire ... 03722.html

TL;DR: less stability and less responsiveness during their beta test have forced to postpone the "stable" e10s release.

[Moonchild]

forced to postpone the "stable" e10s release.

... again

Good news for ESR users though, so they don't get a new buggy feature shoved into their ESR45 that won't be improved (because ESR only gets critical security updates after release).

[snertev]

forced to postpone the "stable" e10s release.

... again

Good news for ESR users though, so they don't get a new buggy feature shoved into their ESR45 that won't be improved (because ESR only gets critical security updates after release).

As far as I have read on the web, ESR 45 may be the forking point for Seamonkey too. Or, at least, a chance to do so.

[Thrawn]

Signing and sandboxing is pretty much de facto for all web and mobile apps, and now all browser plugins for both Chrome and Mozilla, but the PM author seems confident that PM has achieved security without implementing those.

Not exactly; the point is, signing doesn't actually provide security. As for sandboxing - what kind of sandboxing are you talking about? Security-oriented sandboxing is certainly not what e10s is building.

I think it is safe to assume that their respective engineers wouldn't move forward with those solutions if they were fundamentally broken and didn't offer significant advantages to those browsers.

LOL - I think it is safe to assume that you haven't been paying close attention to Mozilla's technical decisions over the past few years. Some advantages, maybe, but fundamentally broken, definitely. See viewtopic.php?f=26&t=8756 and https://www.palemoon.org/layout-differences.shtml

[Moonchild]

As for sandboxing - what kind of sandboxing are you talking about? Security-oriented sandboxing is certainly not what e10s is building.

e10s is not about sandboxing, at all.

the PM author seems confident that PM has achieved security without implementing those

We do sandbox page content (elaborately so), and all content is separated in containers and we make extensive use of so-called X-Rays to expose functionality to content in one direction -- the containers are all in one application process instead of the (intended) multiple for e10s. That's the difference, nothing more, from a sandboxing point of view.

[Stilez]

In fact, if you are a heavy tab user (the person with 2000+ tabs in a session comes to mind) then it will completely kill your usability of your computer, period.

That's me. 1000 - 2500.

Pale Moon will not implement e10s. I'd rather parallelize system libraries instead (like I already do for some things).

Can you explain a bit more on this? It sounds good but I don't know the technicalities of what's involved or proposed.

[BigTee]

No current browser is designed for thousands of tabs. You need to be unloading tabs well before that point.

(And proper tab unloading without using addons that use hacky solutions would be nice for Pale Moon, especially since it's so low-memory focused.)

[Stilez]

No current browser is designed for thousands of tabs. You need to be unloading tabs well before that point.

Nice if it were possible. There 's always been a "tail" of heavy tab users, and saying that it's "not designed" for it, or this is a tiny minority use-case, isn't saying much in this community. It's a bit like saying 99% of people can't find the "start" button or don't want to tweak their browser or just use <10 tabs, so those abilities should be ditched and dumbed down, or phones shouldn't be rooted/jailbroken because they weren't designed for it.

Almost everyone choosing PM is technically a fringe user already - just being adept to decide between browsers on technical points put you in the last 1% or something, and we have almost all chosen a browser probably because of capabilities 99.99% of users will neither appreciate or value. (My partner's response to my move to PM is a case in point - complete disinterest in browser differences and "why change the browser if that's not what the device manufacturer wants to put on it" )

So for whatever reason, heavy tab use is the workflow that works for some people. I mitigate it using extensions that group tabs and allow hibernation of tabs not in use, or otherwise take avoidable load off the engine (TabGroups Manager being one of them), and by early-adopting x64 builds years ago to get around memory limits. Firefox's original pre-e10s engine seems to handle it gracefully, whether by design, or by happy chance, for which I'm grateful.

(And proper tab unloading without using addons that use hacky solutions would be nice for Pale Moon, especially since it's so low-memory focused.)

I think we reached the exact same conclusion. I posted this in a thread about it on Bugzilla a year ago suggesting more exactly a way to approach this aspect of the engine/API, and was suggested to start a new thread for it, but the writing was on the wall even then; I didn't think it would get anywhere in an era of apparent listening failure and loss of direction at Mozilla. Sounds like the sort of thing you're thinking of.

If there were better resource-recovering APIs and extensions drawing on them, that would really help, and I'd be using them. (If I knew more I might also be able to contribute code.) I do use them where they exist, but the basic APIs to allow tab-specific memory and storage recovery, or limit the firing of events needing CPU time, didn't really exist. If they did, then large numbers of tabs would probably be an exercise in array handling and little more. Will PM get them? I hope so but it's such a monumental task and there's so much else to do just keeping it up to date with external changes, that it almost doesn't seem possible or reasonable to hope.

[Moonchild]

Firefox's original pre-e10s engine seems to handle it gracefully, whether by design, or by happy chance, for which I'm grateful.

Actually by design, but within some limits.

The APIs (although actually more talking to the underlying logic directly than a documented API with extra layers of abstraction) are actually already there and used to good effect by e.g. BarTab for putting tabs in pending states.

The main thing remains though that thousands of tabs is simply not the design scope. That's what bookmarks are for; tabs are designed to be temporary and volatile, also in our non-e10s handling of it. It's perfectly fine if it handles this with some use-case specific extensions (that's what extensions are for) but the common use-case won't necessarily need this unloading behavior (which isn't free either in terms of overhead and web compatibility) and as such it's by definition not a core priority.

[Stilez]

The main thing remains though that thousands of tabs is simply not the design scope. That's what bookmarks are for; tabs are designed to be temporary and volatile, also in our non-e10s handling of it. It's perfectly fine if it handles this with some use-case specific extensions (that's what extensions are for) but the common use-case won't necessarily need this unloading behavior (which isn't free either in terms of overhead and web compatibility) and as such it's by definition not a core priority.

Much like you describe, I see bookmarks as something medium to long term, and not a place I want to park whatever random volatile tabs I happen to have open when working on a task. Not ideal but best I can do given what's available. Hence I'm grateful it handles it.

[freefrog]

In regard to large number of tabs, I would love to see something like this effort implemented in Palemoon:
906076 – Virtual tabs - lazily create linkedBrowser and other dependent elements for tabbrowser tabs to improve startup performance

That would largely alleviate this issue:
1125557 – Very high memory use on startup with many unloaded tabs

[Moonchild]

a place I want to park whatever random volatile tabs I happen to have open when working on a task.

You use thousands of documents when working on a single task? Then you may want to re-think your organization of tasks...

[Stilez]

a place I want to park whatever random volatile tabs I happen to have open when working on a task.

You use thousands of documents when working on a single task? Then you may want to re-think your organization of tasks...

Workflow, workflow..... my workflow involves digging up obscure technical research answers on areas where there aren't standard solutions or pre-packed knowledge. It can take hundreds of iterated search engine hits, pages linked from obscure forums or technical websites, and possible hits on archived and cached versions in case they changed, to gather in-depth information on a whole problem or issue, or many dozens of vendor sites to find technical information on existing solutions enough to feel that there's a clear sense what to bear in mind. At any time those might need referring back and forth between, and there may be many of these ongoing. Its a very unusual work area I agree, but that's how it works. Some areas there just aren't collated sources of material or established solutions, so it's a case of finding leads and tips, or hints, and referring back and forth between them, checking up the points they claim on yet other sources to see if they stand up when examined in depth, instead of one or few pages that say it all or an expert in the back room. It's also fun, but it does mean you need to keep the whole library easily switched between as you work - and not lose the pages dug up, if someone comes back to you with a follow-up query later. Not the usual use-case, eh If it were 3000 xkcd pics or blog threads I'd think differently

[Stilez]

In regard to large number of tabs, I would love to see something like this effort implemented in Palemoon:
906076 – Virtual tabs - lazily create linkedBrowser and other dependent elements for tabbrowser tabs to improve startup performance

Oh I like that one! Even with many tabs, it's often the case than most of them don't need to be kept "live" with an actual browser/DOM instance. But I take the point by the responder that it could break many existing things unless done carefully. What's missing for me is what I suggested in the bugzilla comment (linked previously on this thread) that the browser would benefit if API existed so that extensions can explicitly suspend unnecessary actions or unload unneeded resource usage per-tab within the session.

[BigTee]

The main thing remains though that thousands of tabs is simply not the design scope. That's what bookmarks are for; tabs are designed to be temporary and volatile, also in our non-e10s handling of it. It's perfectly fine if it handles this with some use-case specific extensions (that's what extensions are for) but the common use-case won't necessarily need this unloading behavior (which isn't free either in terms of overhead and web compatibility) and as such it's by definition not a core priority.

I definitely agree that, once you get to that many tabs, you're really talking using tabs as bookmarks. There's just not enough time for you to actively be switching between that many tabs. The issue there is mostly that the user may not know ahead of time that they aren't going to use a tab again for a while, and bookmarking is an explicit activity.

The solution to this, in my opinion, is indeed an extension--one that will convert tabs with no volatile information (like form data) to bookmarks after they've been left unused for a sufficient period of time. Combined with the combined bookmark/tab search built into location bar, the bookmarked tabs are still as easily reachable as they were before.


That said, I think there is still a case to be made for unloading at lower numbers of tabs. While the number people who use thousands of tabs is small, the number of users who use, say, 30 is a lot larger. And, given that they chose a web browser that advertises its lower memory requirements, I would guess that this includes a higher percentage of Pale Moon users.

My argument is that there is a place between actively used tabs and the long term storage of bookmarks. There are times where you neither want quick access to a site you use all the time, nor want to make the page easy to find at some indefinite time in the future. You just have some pages you plan to get to before the day is through. In other words, more of a to-do list.

There are other attempts to handle this short-term situation, but the generally involve explicitly saying you will save the link for later. And they assume that, once you use the item, you are finished with it for good.

But tabs already exist, and work well for this usecase. The only problem is that web pages are large, and this can result in a large memory footprint. Unloading tabs allays this issue.

What about the current solution, using virtual memory and copying to disk? For one thing, there is a redundancy of data. You've likely already cached the page to disk. Furthermore, you're caching rendered data, which is likely much larger than unrendered data. Since disk storage is a huge bottleneck, this often means a larger amount of time reading the data from disk and loading it back into memory. Especially since the memory manager doesn't know what memory is immediately useful and what isn't.

Are there other solutions? Possibly. But I don't think you should give up on unloading tabs just because of the case of people who use tabs as bookmarks.

[Moonchild]

There are already extensions that allow you to unload tabs, and I do recommend them.
The browser also gives you the option to bookmark all tabs if you do want to convert them to bookmarks -- but doing this automatically is not a good idea because you'd end up with a huge unsorted pile of bookmarks.
You'd also need to be able to add exceptions for certain tabs/domains/web apps.
All of that kind of work has already been done in the extensions out there for this purpose.

Tab management though is rather tangential to this topic, with the point that even if unloaded, e10s and processes per tab still wouldn't work for unloaded tabs unless you want to kill processes and respawn them. How are you going to suspend a tab session in that situation? Dump it to disk per tab?... that won't work very well.

[Stilez]

The issue there is mostly that the user may not know ahead of time that they aren't going to use a tab again for a while, and bookmarking is an explicit activity.

The solution to this, in my opinion, is indeed an extension--one that will convert tabs with no volatile information (like form data) to bookmarks after they've been left unused for a sufficient period of time. Combined with the combined bookmark/tab search built into location bar, the bookmarked tabs are still as easily reachable as they were before.

That said, I think there is still a case to be made for unloading at lower numbers of tabs. While the number people who use thousands of tabs is small, the number of users who use, say, 30 is a lot larger. And, given that they chose a web browser that advertises its lower memory requirements, I would guess that this includes a higher percentage of Pale Moon users.

My argument is that there is a place between actively used tabs and the long term storage of bookmarks. There are times where you neither want quick access to a site you use all the time, nor want to make the page easy to find at some indefinite time in the future. You just have some pages you plan to get to before the day is through. In other words, more of a to-do list.

There are other attempts to handle this short-term situation, but the generally involve explicitly saying you will save the link for later. And they assume that, once you use the item, you are finished with it for good.
But tabs already exist, and work well for this usecase. The only problem is that web pages are large, and this can result in a large memory footprint. Unloading tabs allays this issue.

Are there other solutions? Possibly. But I don't think you should give up on unloading tabs just because of the case of people who use tabs as bookmarks.

Well explained. Nicely done, BigTee.

The underlying engine seems to have no issues with large or small numbers of tabs, so the issue isn't "whether the engine is designed for it", it is the means of control over storage, CPU and user management (how the user manages tabs). Of course, tab management is already well catered via extensions (several tab groups/tab tree extensions and ample API).

I agree with BigTee that even for heavy/extreme tab users, many of the tabs opened are probably (as you describe) a volatile "to do list" of tabs to be checked and returned to at some point, and ultimately closed but unsure when. They are not all being used "at this exact moment". Also I suspect that perhaps heavy tab users are more likely to keep open the kinds of pages with lower levels of volatile data (other than perhaps form data). No clear evidence, just a suspicion (if one intends to come back to them, the odds are they are the kinds of tabs where goalposts won't have shifted much?). In my case the kinds of tabs I have open are scientific papers, web forum threads, ebay/amazon items, and google image hits - all of which can be safely unloaded. Others may have video pages to watch which can be static until played.

So in large-tab sessions, a tab that's not been foregrounded for a while can often be safely unloaded, have events ignored, and if needed DOM space/memory/disk cache space recovered for other use - as long as (say) form data isn't lost, it's okay if the tab has to be reloaded when foregrounded. I'd actually prefer it (fewer tabs actively being processed by engine = less likelihood of session issues). Even if Ram isn't an issue, it would be nice to have the ability to freeze events and timers on a tab until foregrounded, essentially rendering it a static chunk of data ignored for most purposes, because CPU pressure and not RAM might be an issue. The debugger has this ability, so how difficult would it be to offer a means to trigger some kind of freezing for this purpose, i.e., maybe repurposing debugger freezing of execution of specified tab(s) to allow resource-saving freezing/unfreezing of events, isn't too hard?

In summary, I'd be very happy if there was some way to trigger/control unloading and event freezing, and I'm sure a basic extension for auto-recovering resources or cutting CPU usage would end up available, if some kind of mechanism were present without "hacks".

[Moonchild]

BarTab Heavy does all of this.

[megaman]

BarTab Heavy does all of this.

I can't recommend BarTab Heavy after the problems I've had with it.
I recommend Unload Tab but it doesn't work nicely with TabMixPlus, plus I wish it could let me customize their menu bar options.
Apparently, Unload Tab doesn't like TabMixPlus's CrashRecovery, which is a helpful feature.

[Moonchild]

BarTab Heavy does all of this.

I can't recommend BarTab Heavy after the problems I've had with it.
I recommend Unload Tab but it doesn't work nicely with TabMixPlus, plus I wish it could let me customize their menu bar options.
Apparently, Unload Tab doesn't like TabMixPlus's CrashRecovery, which is a helpful feature.

YMMV, I guess -- I've actually used BarTab (3.2.1) for months now and it's working just fine...
But, the point is, there are obviously very capable extensions available for tab-heavy users, and several different ones for different workflows (or combinations with other tab extensions).

As said though, it's kind of tangential to the whole e10s question this topic is about, apart from the fact that process-per-tab wouldn't allow this kind of workflow at all, extensions or not.