Hacker News Reader

Comment by mintplant | Hacker News Reader

I had to disable e10s because whenever I switched tabs the page would sometimes be replaced indefinitely by a white screen with a big loading indicator. Tried it again recently and the problem was still there, but less so.

I get that multi-process is important, but I really hope Mozilla holds off on a wider release until performance and stability are fully ironed out.

View on HN

Part of the problem is that e10s Firefox by default still uses just one UI process and one "content" process, shared by all tabs. So a web page can't cause the UI to hang, but it can cause all other web pages to hang.

Curious testers can go to about:config and set "dom.ipc.processCount" higher than 1 to increase the number of content processes. I suggest trying this only in Firefox Developer Edition or Nightly, and not in your main browsing profile, since there are still some serious bugs and active development related to this configuration (so consider it a chance to test future improvements, rather than something that’s ready for regular use):

http://bugzil.la/e10s-multi

Wow, thanks! I use Firefox Developer Edition, and haven't seen any discernible improvement in performance with e10s, but setting "dom.ipc.processCount" higher than 1 already seems to be making my browser run faster.

When e10 becomes the default, will the number of content processes still default to 1?

It'll be 1 at first. It's likely to then gradually be increased over time, probably to 2, then 4, maybe 8. Not sure about beyond that.

I'm currently working on reducing memory usage to help with this, because that's the main downside of increasing the content process count. There are all sorts of trade-offs here: performance, memory usage, address space usage, security, crash-resilience, and they all tug in different directions.

There's a bug open for basing it on the amount of cores and memory.

https://bugzilla.mozilla.org/show_bug.cgi?id=1066789

Yes, the conclusion of the link says so.

Where? I don't see any such conclusion. Mind quoting the relevant bit?

> Overall we see a 10-20% increase in memory usage for the 1 content process case (which is what we plan on shipping initially).

> I had to disable e10s because whenever I switched tabs the page would sometimes be replaced indefinitely by a white screen with a big loading indicator.

I'm pretty sure I know what loading indicator you're talking about, though I don't have a screenshot handy.

Basically, this is because one of the other tabs is hogging the rendering process. Since the Firefox UI[0] is controlled by a separate process under e10s, it's still responsive while the other process is rendering webpages. So, you're able to switch tabs before there's something there to switch to.

Without e10s, under this situation, the Firefox UI will be unresponsive while the tab is rendering web content (the browser will appear to lock up). That doesn't necessarily mean the tab will always be fully rendered by the time you're able to switch, but the loading indicator was added to e10s specifically because multiprocess mode makes this situation more likely to occur than under single-process mode.

If you want to see what I'm talking about, try visiting an Amazon product page both in an e10s window and in a non-e10s window[1].

[0] Confusingly referred to as the chrome, a name that predates the browser with the same name

[1] Unless they've fixed it recently, there's a longstanding, known "bug" that's caused by Amazon "prefetching" the content of all links on an Amazon product page. This Javascript is included only when the page is loaded in Firefox, and it's rather redundant, because the content is still re-fetched when the link is clicked. Unfortunately, Amazon hasn't fixed this, and I don't think there's much Mozilla can do about it.

Thanks for the explanation.

I could be wrong, but I feel like I experience the white-page-and-loading-icon with e10s enabled much more often than I do UI hangs with it disabled.

If that's really what's happening, though, then the UI could be improved -- otherwise people like me will end up blaming the issue on the e10s update.

For the time being I have also disabled e10s because it does not yet, and I suspect never will, support userContent.css and userChrome.css.

https://bugzilla.mozilla.org/show_bug.cgi?id=1046166

Eventually, I will need to migrate my user styles to a plugin such as Stylish, but I have preferred the minimalism of userContent.css.

However, seeing the mention of a multi-process user interface elsewhere in this thread is tempting me to ditch userContent so I can re-enable e10s with the multi-process UI, at least once the kinks are worked out.

Can you file a bug report? It can't be fixed if Mozilla doesn't know about it.

I've noticed something like this in Chrome on my Mac anytime I switch tabs... If I come back to a tab, it is just a blank white page and I need to refresh to bring the page back up.

I recently did a clean install of El Capitan and the problem persisted.

Is what's happening to me kind of the same thing?

Reply on news.ycombinator.com