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...

EDIT: ah, well, I found the relevant github issue. Looks like there's years of arguing yet to go! https://github.com/mozilla/multi-account-containers/issues/3...

Firefox can already run multiple profiles simultaneously (like you do with chrome) http://kb.mozillazine.org/Command_line_arguments .

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.

https://addons.mozilla.org/en-US/firefox/addon/conex/

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.)

https://github.com/kemayo/firefox-sticky-containers

I'm currently seeing whether #webextensions on irc.mozilla.org feels like ripping it to shreds, but I'll put it up on AMO after that's done.

Okay! Here it is: https://addons.mozilla.org/en-US/firefox/addon/sticky-contai...

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.

No keyboard shortcuts to speak of.

uMatrix is a good replacement for Ghostery.

https://addons.mozilla.org/en-US/firefox/addon/umatrix/

Firefox has built-in tracking protection that can be enabled in non-private windows too.

Nice! This was my number one issue with Firefox as well. 400% cpu usage with about 40 tabs compared to safari was getting to be too much.

Yes I'm one of "those" people. I hoard tabs like they're going out of style.

What incantation do you do to make your cpu go to 400%?

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.

Mac shows CPU usage as 100% per core. Means he has a quad-core or dual-core w/ hyperthreading.

Linux does the same thing too. I wonder whether this is a POSIX thing, or if it's just a rather common UNIX thing.

Could you please report back with your findings? I'm also terribly interested in this as well.

Just updated!

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.

Most likely related: https://bugzilla.mozilla.org/show_bug.cgi?id=1404042

My personal test case will be with the UniFi 5.7/5.8 Controller web interface page. I've found consistently under the last few versions of Firefox that, while it's fine for at least an hour, if I leave it up constantly for ease of monitoring then after a day or two the Firefox process inevitably ends up pegging an entire core. There is no video whatsoever or any particularly fancy graphical usage, and while they may be doing something odd internally (I haven't had time to really dig into it) I'm not sure Firefox should end up in that state there over time. It's relatively easily repeatable though (will take a day but requires no interaction on my part) so I look forward to testing it. Although if it does resolve the problem I'll be mildly bummed whatever fix it was didn't make it into ESR, but so it goes.

Would it be possible to get access to the page in question to try to diagnose this problem?

If it would, please let me know at bzbarsky at mit dot edu.

If not, would you be willing to use a Firefox nightly and follow the steps at https://developer.mozilla.org/en-US/docs/Mozilla/Performance... then send me a link to the profile that gets generated?

Ubiquiti runs a demo of it here: https://demo.ubnt.com/manage/site/default/dashboard

Thank you! I'll give that a shot.

I’ll try to repro myself first, already started up a test both on metal and a VM on a few systems. If it’s dealt with probably not much point investigating further. Should know within a day or two (or sooner, maybe it’s even regressed a bit). I’ll try to do a proper performance profile a report after that as well as ping a contact at Ubiquiti. They’d be the best placed to really dig into it.

Thank you! Please let me know how things look.

I agree that if it's a leak on the Ubiquiti side they would be best placed to deal with that aspect, but there might be things we can do better on the Firefox side to handle pages leaking too...

That sounds like the developers messed up some Javascript references that are unable to be cleaned up to me. But interesting nonetheless.

Memory leaks can be hard to track down.

After weeks of effort, a team mate finally figured out that a default noop function param, eg function blah( param = () => {} ), was never being gc’d. Wut?!

Was it getting captured by a closure being returned from the function, with that closure never getting gced?

But yes, in general tracking down leaks in JS is a huge pain...

I recently wrote an automatic memory leak detector and debugger, which makes this a lot easier (imo) [0]. You write a short input script that drives the UI in some loop, it looks for growing things (objects, arrays, event listener lists, DOM node lists...), and then collects stack traces to find the code that grew them. While it won't find all of the leaks, I was able to eliminate an average of 94% of the live heap growth I observed in 5 web applications (which found new memory leaks in Google Analytics, AngularJS, Google Maps, etc).

More information about the technique can be found in a PLDI paper (which I presented last week :D ), which I tried to write clearly so that it is accessible to a technical audience (i.e., non-academics) [1].

[0] http://bleak-detector.org/

[1] https://dl.acm.org/citation.cfm?doid=3192366.3192376 (shouldn't be paywalled, but if it is, it's also available at [0])

I once used the Python function "gc.get_objects()", which returns a list of all objects in memory, to diagnose a memory leak. I don't suppose anything like it exists in JS tooling?

You can capture a heap snapshot in most browsers now using development tools. However, even a blank webpage (about:blank) has tens of thousands of objects allocated for the default JavaScript/DOM APIs. It's challenging to manually grok a JavaScript heap.

The approach I used was to take a snapshot, count up all the different object types (making a hash table mapping "name of type of object" => "count of objects whose type has that name", then discarding the snapshot), then take another snapshot a few minutes later, and see what the difference was, and which type of object there was suddenly a lot more of. Then I looked at various instances of that object. It turned out to be some async queue-related object that was only used in a couple of places, so that narrowed it down a lot. Even if it were something generic like a hash table or list, I suspect looking at instances of the object and breaking them down by some observable quality (e.g. number of elements, the set of keys in a table, the types of objects in a list), plus the differential approach, will take you fairly far.

Not that I've seen.

There are some browser-specific tools that will do something like that out-of-band (e.g. in Firefox about:memory has a "Save GC & CC logs" option that outputs data about what the GC and cycle collector heap graphs look like). But interpreting those graphs is not easy, sadly.

For me it's the Microsoft Azure Portal that would cause Firefox to idle around 50% CPU utilization. For the moment it seems to be behaving. I opened up the UniFi Controller interface too just to test and it caused it to spike briefly but it settled back down to under 6% across 6 cores. So it's improved IMO.

I also had that, and it finally appears to be gone!

On the other hand, everything is blurry. I've searched to no end, and haven't found a solution. It looks like third-party apps used to when the rMBP was first released and apps that performed their own text rendering hadn't yet been updated to support it.

Any ideas?

Edit: I have no idea how this was even ever set in the first place, but a sibling comment mentioned the "Open in Low Resolution" flag that can be set on a binary, and it was enabled for Firefox on my machine. Either I set this manually trying to solve the performance issues (and somehow this setting persisted across uninstalls), or Firefox ships with this flag set. Unchecking it fixed the blurriness, and hopefully didn't bring back the performance problems.

It might have persisted across uninstalls (browser profiles often do), because people were suggesting the "open in low resolution" flag as a temporary fix for Firefox performance issues on Macs prior to v61 being released.

Out of curiosity, were these high CPU usages on pages with any sort of video playing (culprits for me were Twitch or any live stream)? I was also having these issues, and I want to use Firefox, but the performance in the past was just too difficult.

I had the same issues and avoided FF 57+ because of it. I just tried FF 61 and my results were mixed. Twitch and Youtube still made my CPU temps spike a little bit. It seems worse than Chrome but better than FF 57.

Google Maps, unfortunately, still made my CPU temp spike 30C+ as soon as I opened it. I use Maps a lot, so this is still a deal breaker for me.

Glad it's not just me. All of those really seem to stress Firefox out on my iMac. Chrome is far more efficient with something like Twitch.

Interesting thing I've noticed: If you don't use chat much and just want the video, try using Twitch's "pop-out" player that opens in its own window- for me this uses far less CPU (even in Chrome)

Chrome's "switch to fullscreen" transition on twitch for me is super laggy though, and I haven't been able to solve that one (Firefox switches to fullscreen smoothly).

Yea, most of my browser time spent during free time is strictly on Twitch/Youtube/Netflix. Until these see improvements, then I won't make the switch.

I only use firefox (for privacy reasons). But the macbook-burning-a-hole-in-my-pants behaviour that firefox creates on these sites has led me to using mpv with youtube-dl to watch most of youtube and all of twitch. If you have both installed you can just do a 'mpv https://www.twitch.tv/username' and it will work quite nicely. You might need to set up mpv to get the best quality, I think putting 'ytdl-format=bestvideo+bestaudio/best' in ~/.config/mpv/mpv.conf is sufficient. HTH.

I am also in this camp and want to say that twitch especially is just horrible for performance

Which is so surprising to me because it's using the HTML5 video player and toggling around with hardware acceleration does nothing to fix the issue. Perhaps it's the integrated chat + any of the add ones that Twitch has written for the videos?

I have noticed the pop-out player seems far more efficient, which leads me to think the chat and other things going on around the video might be the culprit

Unrelated, but what do people do on twitch? I worry about getting out of touch with my children.

In addition to FreeFulls comment, there are also talkshows/(video)podcasts. It's basically the main broadcasting platform for gamers and tech people.

Twitch is mostly people streaming video of themselves playing games, but there are also some programmers that stream as they write software.

Video has been a big culprit for me - in both FireFox and Chrome. I've actually taken to using Microsoft Edge when I plan to play video.

I use Opera as my personal browser and it handles video pretty well. It's running Chromium under the hood, and I don't think any major improvements have been made for video in Chromium or in any of the standards like HTML5 or flash. I see on par performance to stock Chrome.

I would lean towards "yes". Mostly problematic pages: YouTube and Twilio dashboard.

Unfortunately, this doesn't appear to be the case for me. I've been wanting to switch back to FF for some time but just opening a website causes my MBP CPU to go nuts, seems 61 is no different for me.

You wouldn't happen to be running Tab Session Manager, would you? That was causing me all sorts of performance problems on both PCs and Macs, and I only tracked it down by disabling all extensions and themes and then incrementally re-enabling them.

I am not, although you did remind me to try without any extensions enabled again. I can't do a straight comparison as I'm at work now, but my work laptop (2017 vs 2016) is showing improvements. For reference, my work laptop also had high CPU usage on previous releases (even with no extensions), so there's hope yet. Although not being able to use the extensions I normally use would be a deal breaker (blockers and such)

For me it just consistently hovers around 18% cpu. Chrome on the same site sites around 1%... could it be optimized for memory usage isn’t always better if it means more cpu usage?

I'm at 2% right now typing this comment. Might be worth checking your add-ons.

I always run stock browsers. Usually in FF on OS X any kind of css animation is very cpu intensive.

Sounds like your computer. :)

I saw the same issues and I'm using a 2017 MBP 15" with the middle of the road CPU and 16GB RAM (dedicated GPU as well).

> And now the dark theme also applies to address bar and hamburger menu which is nice bonus.

I have both normal FF and nightly FF. Before nightly getting the dark hamburger menu I'd never thought much of it. After nightly got the dark menu, now on normal FF I can't help but notice it every time I open the menu, and it annoys me to no end. Funny how these things work.

I wouldn't call it a great release. For me Firefox is unresponsive sometimes for literally minutes. I click on another tab and it takes minutes to switch to it. I just had it happen before posting this comment. I also took a perf profile and asked the people in #perf to look at it but nobody did.

So no, I wouldn't call this a great release.

Firefox has tools to figure out which tabs are causing problems, try about:performance. Any freeze of minutes is generally caused by a memory leak in the javascript of a particular page.

I thought the recent work on multi-process stuff would have gotten rid of that? The browser chrome not being affected by in-page issues seems like a fairly important goal there...

I did look in about:performance, nothing obvious was there. I think it's rather because I have many tabs, not because of a specific tab.

I have about 200 tabs on my work machine and something even worse on my personal one and have never seen this, so unless you're a serious tab hoarder I doubt it's that.

>about:performance //

Where's that in the menus?

It's a URL

I'd be very interested to look into that, haven't seen it being stuck for minutes anywhere. Do you still have this profile around? or maybe just the URL?

Yes, I still have the profile. If you send me an email to the address in my profile, I'll send it to you.

Yes, so far so good.

This is the page I always test for Firefox CPU usage: https://flypaper.soundfly.com/

I don't visit this site, but on a past Google hit, I discovered that it would make Firefox go crazy. No idea why.

Yes, 60 was giving me some performance troubles on iMac. Excited to see if 61 resolves them.

They need to better staging these releases so that the lap warmer releases occur in fall and winter and these cooler releases start in early spring.

I'll bite - not everyone lives in Northern hemispere so for me (winter just started) it's perfect <s/>