If this is true, I would finally be ready to dump Chrome. I had the same issues, and I couldn't figure out what was causing it, but the app regularly ran hot. Will give this round a go.
UPDATE: So far, so good! Multiple account containers open, lots of different websites that usually would cause problems, and so far it's running fine! Also had Ghostery left installed and uninstalled that as well as it also hogged CPU time on Chrome, so that may have had an effect. All in all, think this is g'bye, Chrome.
Sort of tangential, but as an account-containers user, have you found a decent way to achieve making the current container "sticky", so that new tabs opened in a given window go directly to that container?
I currently use Chrome's account profiles for this, so I have a desktop where my work profile lives and a desktop where my personal profile lives, and this makes links followed from other applications Just Work so long as I'm on the right desktop for them. I could probably get used to a slightly more awkward workflow, and the history being annoyingly shared between them, but...
The problem is not having just one instance open all the links. It seems it might be possible to hack around that by writing your own url handler for your os, then dispatching to the correct instance. (https://superuser.com/questions/119014/how-to-remotely-open-...)
I did try that out, when I was seeing if I could stand switching after multiprocess stuff landed. It's closer to the fairly-polished Chrome experience if you use about:profiles, rather than messing around with custom command lines.
But, as you say, the problem with that is that it doesn't handle opening links correctly.
I could see if I could write a URL handler that queries the window manager to find the last Firefox window that had focus on the current desktop (probably possible, but I'm unfamiliar with that domain)... or I could view Firefox not supporting this natively as a sign that it doesn't think my use case is very important, and stick with a browser that works without jumping through hoops.
It's not that I'm averse to putting some work in, per se -- I'm now in the middle of poking at writing a Firefox add-on to see if I can fix my complaints about insufficiently sticky containers -- it's just that writing my own OS url handler is a bit too hacky for my tastes.
I have been using the Conex extension. It opens the new tab in the same container as the currently active tab and you can enable the preference to make it so that it asks you which container you want to use before opening an external link.
I've written my own now, which just approximates the Chrome behavior. (I looked at Conex after you linked it, and it didn't quite do what I felt was right.)
I did the same with Chrome account profiles, and I just searched for this on Firefox. The closest you get to it is ctrl/cmd + "+" (new tab button) which will open a new tab with current container.
Sorry, the main process goes to 140%, and about 5 more other firefox processes start chewing up 80% cpu each. I just added them altogether.
I have seen it spike to 400% a few times in activity monitor.
As to what I'm doing, open up say lobsters, click on all the tabs that look interesting, forget them for a day, repeat. End of the week have a look see at things.
For me the problem was only when firefox was running in retina mode. Going into Applications > Firefox > Right Click Get Info > Check "Open in Low Resolution"
The problem was fixed, but all the text looks bad now.
That's interesting. That fix seems unreasonable for me considering I already have difficulty reading on screens. But that's at least a point to look for later on in the release notes.
UPDATE: So far, so good! Multiple account containers open, lots of different websites that usually would cause problems, and so far it's running fine! Also had Ghostery left installed and uninstalled that as well as it also hogged CPU time on Chrome, so that may have had an effect. All in all, think this is g'bye, Chrome.