Jump to content

Force "multiprocess mode" in FF 52


Recommended Posts

"I was under the impression this pref would only work with FF53 (or Basilisk 55)
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add manually"

Probably so. I am just testing, and have not yet tried loading file://s. I will soon test with tiddywiki and see.

True, I have two nvidia quadro in this setup, so juice there is -but I tried in a lesser VM setup, and it ain't bad at all, compared to the status quo before learning about browser.tabs.remote.force-enable (thanks @Mathwiz).

But I also have plenty confidence on the skills and foresight of @roytam1.

PS: since my 15s I have cut my hair (myself, with sizers) cherokee (or something like that) style, so I have practice with using black stuff to cover the hairless-spots I've been leaving in my skull. Now I have to find some greyish stuff to do the trick    :P

Edited by dmiranda
Link to comment
Share on other sites


Just for the fun of it :P, and intrigued by this latest "revival' of the e10s/Serpent topic, I went ahead and enabled e10s in my latest St52 [v52.9.0 (2021-07-16) (32-bit)] working profile, having it properly backed-up beforehand... ;)

This is an old, 2008 era, Vista SP2 32-bit laptop, with a Core2Duo CPU, an integrated GPU (with no h264 H/W decoding support) and a blacklisted, vendor customised, gfx driver, that can't be updated any further; in essence, an under-resourced PC by today's standards... :(

I witnessed no crashes at all, but the expected increase in RAM consumption:

aqrZsqj.jpg

I don't frequent facebook, instagram, twitter, tiktok, discord, etc. (the main villains :realmad: ) and I only occasionally visit "GoogleTube" (because it's Google's, not yours... :angry: ), so the browser remained responsive on most sites I use :) ...

HOWEVER, as part of my daily workflow, I must have several GitHub tabs open in Serpent 52; GitHub (and recently GitLab) is unusable in UXP browsers, unless JustOff's GitHub-WebComponents-Polyfill legacy extension is installed: 

https://github.com/JustOff/github-wc-polyfill/releases

But said extension IS NOT electrolysis (e10s) compatible, so, sadly :(, I'll have to return to my single-process profile to continue using it on GitHub...
Happy experimenting to the rest of you ;), I'll be still keeping an eye on this thread (though in a silent manner, I'm afraid) ... :rolleyes:

Best wishes :)

Edited by VistaLover
Link to comment
Share on other sites

On 7/19/2021 at 1:01 PM, XPerceniol said:

Am I right in saying Basilisk 55 *was* actually based on FF53, and not really/truly FF55?

As @VistaLover noted, Basilisk 55 (aka Moebius) was forked from an alpha version of FF 53. My understanding is that the "55" came from the fact that some changes were back-ported from FF 54 and FF 55 before MCP gave up on Moebius and re-forked Basilisk from FF 52.6. (Sort of like what ArcticFox and @roytam1 have been doing with NM 27 lately ;))

Anyway, as an (albeit early) FF 53 fork, Serpent 55 is probably the best XP platform for e10s multi-process mode, although memory usage does get pretty large pretty quickly! (The second-best XP platform for e10s would likely be "stock" FF 52.9.) I've been using e10s with St55 for a couple of years now, without noticeable ill effects (other than memory usage), although I keep a "single-process mode" profile available, in case I need to use those incompatible browser extensions (notably Classic Add-Ons Archive).

On 7/19/2021 at 6:37 PM, ArcticFoxie said:

@XPerceniol - you cited in one of the 360Chrome threads that multi-process (several .exe's in the Windows Task Manager) is one of the things that you do not like about Chrome-based browsers.

So I must admit, I'm a bit confused that you are attempting to bring multi-process to FF-based browsers when that support by its developers never matured anywhere near the level of Chrome development (from my understanding).

I can't speak for @XPerceniol, but speaking for myself, one advantage of multi-process mode in the FF platform is the ability to limit the number of processes to something reasonable. In "straight" FF, you get one process, period. That obviously isn't enough for many modern sites. But in Chrome, AIUI, you get a separate process for each tab of each window - overkill IMO. E10s lets you choose a reasonable "middle ground" based on how you use your browser and how much RAM your system has.

Link to comment
Share on other sites

On 7/25/2021 at 6:51 PM, Mathwiz said:

But in Chrome, AIUI, you get a separate process for each tab of each window - overkill IMO. E10s lets you choose a reasonable "middle ground" based on how you use your browser and how much RAM your system has.

It's not that simple in Chrome.

I don't know the "algorithm" and can't really say as it concernms me too much, but it really cannot be "watered down" to "a separate process for each tab of each window".

Maybe I'll research it one of these days, but other priorities kinda take precedence at the moment.

I'm showing 12 processes for four windows with two tabs each.

Drop down to two windows with two tabs each and I'm at 8 processes.

Move the second window's two tabs into the first window and close that second window still has me at 8 processes.

Drop down to only one tab in that one window and I'm at 5 processes.

Open a second window and open 15 tabs so now I have one window with one tab and a second window with 15 tabs and I'm at 23 processes.

Open a third window and open 25 tabs and I'm at 52 processes.

Open a fourth window and open 49 tabs and I'm at 86 processes.

Return to the third window and open 24 more tabs and I'm still at 86 processes.

Return to the second window and open 24 more tabs and I'm still at 86 processes.

 

So that kinda tells me that Chrome chooses its own "middle ground" and that Firefox just isn't "smart enough" to choose its own "middle ground" so the developers opted to create a scheme where the "user" sets that "middle ground".

That probably works for most MSFN FF users, but I'm betting that the "average" FF user probably only "cripples" their FF by trying to set that "middle ground".

But anywhoo...

 

Link to comment
Share on other sites

On 7/21/2021 at 3:15 PM, XPerceniol said:

I was under the impression this pref would only work with FF53 (or Basilisk 55)
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add manually

Be it that it treats a file as a normal tab, be it that the option is "hidden" (you gotta create it the pref in about:config) basilisk52 treats a file as a different process.

As of now, my user.js prefs are (auto means that user.js establish the pref without user action, set means that user has to set it manually in about:config, add means that user has to create it in about:config, review means that I'm not sure about it yet):

// MULTIPROCESS
user_pref("browser.tabs.remote.force-enable", true); // set
user_pref("browser.tabs.remote.autostart", true); // auto
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add
user_pref("dom.ipc.processCount", 4); // set
user_pref("dom.ipc.process.webLargeAllocation", 4); // set
user_pref("extensions.e10sBlocksEnabling", false); // set
user_pref("extensions.e10sMultiBlockedByAddons", false); // add
//user_pref("browser.tabs.remote.autostart.2",); // reset if created

If your setup has the juice for it:

// ACCELERATION AND GRAPHICS
user_pref("layers.acceleration.force-enabled", true); // add
user_pref("layers.force-active", true); // set
user_pref("layers.acceleration.enabled", true); // default
user_pref("layers.async-pan-zoom.enabled", true); // default
user_pref("layers.offmainthreadcomposition.async-animations", true); // default
user_pref("layers.offmainthreadcomposition.enabled", true); // add
user_pref("layers.async-video.enabled", true); // add
user_pref("html5.offmainthread", true); // default
user_pref("layout.frame_rate.precise", true); // set review
user_pref("gfx.direct2d.disabled", false); // default
user_pref("gfx.font_rendering.directwrite.force-enabled", true); // set
 

Edited by dmiranda
Link to comment
Share on other sites

On 7/28/2021 at 8:15 AM, ArcticFoxie said:

It's not that simple in Chrome.

I don't know the "algorithm" and can't really say as it concernms me too much, but it really cannot be "watered down" to "a separate process for each tab of each window".

Maybe I'll research it one of these days, but other priorities kinda take precedence at the moment.

I'm showing 12 processes for four windows with two tabs each.

Drop down to two windows with two tabs each and I'm at 8 processes.

Move the second window's two tabs into the first window and close that second window still has me at 8 processes.

Drop down to only one tab in that one window and I'm at 5 processes.

Open a second window and open 15 tabs so now I have one window with one tab and a second window with 15 tabs and I'm at 23 processes.

Open a third window and open 25 tabs and I'm at 52 processes.

Open a fourth window and open 49 tabs and I'm at 86 processes.

Return to the third window and open 24 more tabs and I'm still at 86 processes.

Return to the second window and open 24 more tabs and I'm still at 86 processes.

 

So that kinda tells me that Chrome chooses its own "middle ground" and that Firefox just isn't "smart enough" to choose its own "middle ground" so the developers opted to create a scheme where the "user" sets that "middle ground".

That probably works for most MSFN FF users, but I'm betting that the "average" FF user probably only "cripples" their FF by trying to set that "middle ground".

But anywhoo...

In every example you cited except the last two, there were more than "one process for each tab of each window," by a minimum of four processes! That is not a "middle ground" between one process, total (FF w/o e10s); and one process for each tab of each window - it actually means Chrome is more of a process hog than I thought (at least until you hit the apparent cap of 86(!) processes).

If Chrome were "intelligently" sharing processes as the total number of tabs increased, we would expect to have fewer processes than tabs, not more processes than tabs. But you didn't see that until you got up to 90+ tabs!

Link to comment
Share on other sites

  • 1 month later...
On 7/20/2021 at 12:14 PM, XPerceniol said:

..user_pref("dom.ipc.processHangMonitor", true);

 

 

 

See https://www.reddit.com/r/firefox/comments/ct0suf/any_way_to_disable_the_browser_pausing_with_a_web/app.support.e10sAccessibilityUrl

Also, now testing (after seeing your edit)

user_pref("app.support.e10sAccessibilityUrl","127.0.0.1"); // set

user_pref("app.support.baseURL","127.0.0.1"); // set

I may do the same for most mozilla.org references

Edited by dmiranda
Link to comment
Share on other sites

  • 2 weeks later...
On 9/12/2021 at 12:17 AM, dmiranda said:

Thanks for that! That annoying warning banner comes up almost every time I visit my bank's (Chase) web site, and I've long wanted to get rid of it! Clicking "wait" makes it go away for a few seconds, but it usually comes back before the script is finished.

You don't actually have to click on "wait;" once their Javascript finishes downloading whatever info I asked for (e.g., checking account transactions), the banner goes away on its own. It's just annoying to have it pop up every time!

Edit: Unfortunately, it didn't work! After a restart, the banner no longer comes up; but a dialog box pops up with the same options. There's a "don't show this again" checkbox, but it doesn't work either. :( However, I believe I discovered the correct pref to get rid of it for good: set dom.max_script_run_time to 0. That seems to have banished the dialog box for good.

Edited by Mathwiz
Link to comment
Share on other sites

  • 2 weeks later...
On 7/22/2021 at 9:14 AM, VistaLover said:

HOWEVER, as part of my daily workflow, I must have several GitHub tabs open in Serpent 52; GitHub (and recently GitLab) is unusable in UXP browsers, unless JustOff's GitHub-WebComponents-Polyfill legacy extension is installed: 

https://github.com/JustOff/github-wc-polyfill/releases

But said extension IS NOT electrolysis (e10s) compatible, so, sadly :(, I'll have to return to my single-process profile to continue using it on GitHub...

I tested 4 Github tabs in 4 process separately without problem. My relevant setting:
 

browser.tabs.remote.force-enable;true

dom.ipc.processCount;8

layers.acceleration.enabled;false

Correction:

I concluded too quickly; Github actually crippled in various ways with e10s and latest github-wc-polyfill, though downloading works.

Edited by luweitest
correction
Link to comment
Share on other sites

When number of tabs exceed dom.ipc.processCount, it's possible to experience inability to switch to another tab if one of the tabs get super-busy, as in single-process mode.

Some extensions don't work in multi-process mode. Anyone found the documentation on how to make them compatible? Test your add-ons for Multi-process Firefox compatibility page leads to a dead page: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Working_with_multiprocess_Firefox

Also can't have Actual Window Manager enabled for the browser as long as it's in multi-process mode because the browser soon becomes unresponsive as the secondary process gets in some kind of infinite loop, using 100% of CPU core.

BTW:

On 5/11/2019 at 1:25 AM, Mathwiz said:
#if defined(XP_WIN)
  if (Preferences::GetDefaultCString("app.update.channel").EqualsLiteral("release") &&
      !IsVistaOrLater()) {
    gMultiprocessBlockPolicy = kE10sDisabledForOperatingSystem;
    return gMultiprocessBlockPolicy;
  }
#endif

(This was back around FF 48.) As you can see, it uses an #if defined(...) block to check whether the build targets Win XP

XP_WIN just means Windows. Another macro may be defined in its place when compiling code for another platform, eg. XP_MACOSX or XP_UNIX.

Edited by UCyborg
Link to comment
Share on other sites

On 10/16/2021 at 1:13 PM, UCyborg said:

When number of tabs exceed dom.ipc.processCount, it's possible to experience inability to switch to another tab if one of the tabs get super-busy, as in single-process mode.

Yes, I've experienced that myself. I have one tab open that has JavaScript to auto-refresh every 5 minutes; when the auto-refresh happens, certain other tabs will freeze until the refresh completes (on both XP and Win 7!) I guess I just need to stuff in more RAM and bump the process count.

BTW (and slightly OT), I found unrelated preferences whose setting can be changed for improved performance: layout.frame_rate and layers.offmainthreadcomposition.frame-rate. The defaults are -1, which AIUI means refresh the screen as fast and often as possible; clearly a waste of CPU if yours can refresh the screen faster than your monitor refreshes! I had mine set to 240; probably a holdover from the "UOC Patch," which wasn't much better for performance than -1! I changed them to my monitor's refresh rate, 60, and got noticeably improved performance on a website that's particularly heavy on "cute" animations (like fading windows in/out, rotating "Please wait" wheels, and the like).

On 10/16/2021 at 1:13 PM, UCyborg said:

XP_WIN just means Windows. Another macro may be defined in its place when compiling code for another platform, eg. XP_MACOSX or XP_UNIX.

I see; the "XP" in the macro is merely a coincidence. I'm sure there's no Mac OS XP or LinuXP! (Probably stands for eXecution Platform or some such nonsense.) It would have made sense to condition the code not just to Windows but to the specific version, since there's no need for the test at all, if the code can only run on Vista+ anyway (think FF 53+); so naturally I thought XP_WIN meant Windows XP; oh, well, you can't win them all....

Luckily, it's irrelevant to the point I was making two years ago, which is that there was code (at least in FF 49) that checked the app.update.channel pref at run time, and disabled e10s if it was set to "release."

We were searching for alternative ways to enable e10s, and if for some reason you happen to be running FF 49, changing the update channel pref may work. (I never tried.) But by the time of FF 52 (the basis for all UXP browsers, including St 52, and of course the basis for FF 53, which in turn was the basis for St 55), the app.update.channel pref had no effects other than those which @VistaLover noted in the post I replied to.

Edited by Mathwiz
Link to comment
Share on other sites

11 hours ago, Mathwiz said:

layout.frame_rate and layers.offmainthreadcomposition.frame-rate. The defaults are -1, which AIUI means refresh the screen as fast and often as possible; clearly a waste of CPU if yours can refresh the screen faster than your monitor refreshes!

Nah, the code says -1 for layout.frame_rate means 60 FPS and layers.offmainthreadcomposition.frame-rate = -1 means use the value of layout.frame_rate. Value of 0 has special meaning for both settings. Both control FPS of different parts.

Maybe it figures out monitor refresh rate on certain systems and use that if -1 is set for the first setting, would have to check more thoroughly.

Edited by UCyborg
Link to comment
Share on other sites

On 10/10/2021 at 5:31 AM, luweitest said:
  On 7/22/2021 at 4:14 AM, VistaLover said:

HOWEVER, as part of my daily workflow, I must have several GitHub tabs open in Serpent 52; GitHub (and recently GitLab) is unusable in UXP browsers, unless JustOff's GitHub-WebComponents-Polyfill legacy extension is installed: 

https://github.com/JustOff/github-wc-polyfill/releases

But said extension IS NOT electrolysis (e10s) compatible, so, sadly :(, I'll have to return to my single-process profile to continue using it on GitHub...

On 10/10/2021 at 5:31 AM, luweitest said:

Correction:

I concluded too quickly; Github actually crippled in various ways with e10s and latest github-wc-polyfill, though downloading works.

As I stressed already, GitHub pages do load when e10s is force-enabled in St52, but the gh-wc-p extension isn't e10s-compatible; this means that the majority of useful functions (especially for a logged-in user) in the GitHub web front-end simply fail to work... :(
Read the relevant discussion over at
https://github.com/JustOff/github-wc-polyfill/issues/33

:whistle:

Link to comment
Share on other sites

On 10/16/2021 at 9:13 PM, UCyborg said:

Some extensions don't work in multi-process mode. Anyone found the documentation on how to make them compatible? Test your add-ons for Multi-process Firefox compatibility page leads to a dead page: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Working_with_multiprocess_Firefox

The documentation was removed last December:

http://web.archive.org/web/20200801000000*/https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Working_with_multiprocess_Firefox

Relevant articles:

https://blog.mozilla.org/addons/2016/08/02/multi-process-firefox-and-add-ons-a-call-to-action/

https://wiki.mozilla.org/Add-ons/developer/communication#Migration_paths_for_developers_of_legacy_add-ons

https://extensionworkshop.com/documentation/develop/comparison-with-the-add-on-sdk/

I'm quite sure additional documentation has been spared from Mozilla's axe, it's just that one needs to hunt it down with determination... ;)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...