Set the browser.ml.chat.enabled and browser.ml.enabled to false as they intensively use the processor and drain the battery. All that to just find the best name for your tab groups. I prefer to have my laptop last one more hour instead.
I took a brief gander at its code [0] and saw it mainly focusses on k-means clustering algorithms (in JS, no less). To my ken this is likely for suggesting new tabs, something a user is even less likely to use than renaming them.
Its constant drain even when not 'in use' seems to imply it's classifying tabs as they change page (though it might be telemetry or uncommented testing). If so, it's an example of premature optimisation gone very wrong.
It's a shame, because it overshadows the fact that naming tab groups is a perfect use case for an LLM, alongside keyboard suggestions and reverse dictionaries [1]. I'm ardently distrustful of LLMs for many, many purposes, but for the tiny parameter and token usage needed it's hard to not like. Which is a shame it's (somehow) such a drain.
Does anyone here struggle so much with naming a group of tabs that you'd reach for an LLM? I mean... really? How often does a group of tabs need a more complex name than "Work", "Gaming", etc? Maybe a suffix for the work project?
i think the implementation is more that when you connect two or more tabs, it automatically names it for you, meaning you don't have to rename it (at least, that's my experience with the feature in Edge)
I recall an extension (I think by a Mozilla dev) which could do automatic grouping of tabs (back before tab groups was removed). I'm surprised this hasn't come back.
Wasn't that a bug that was fixed weeks ago? Like early August? If you are not averse to this feature then it is better to simply make sure you are running the latest version.
I litterally gained one hour off my charged battery when I switched these two settings off, just a week ago, and I keep my browser up to date. So not for me.
You sound like 1.125 watts is insignificant to a laptop, but my laptop idles around 6 watts and it is currently using 8 watts since I've got some stuff running. Shaving off 1.125 watts is a 14-19% improvement.
Exactly. And honestly- the screen is way way more than 1watt. According to RAPL power, a USB-PD power analyzer- changing the brightness on my 15" 4k OLED laptop screen can reduce power usage by 15-20W. The nature of OLED makes it hard to get a clear picture.
I didn't know about this 2 settings but they were already disabled in my about:config. I wonder if Debian distributes a non-default about:config with Firefox.
They do, see /etc/firefox-esr/firefox-esr.js -- but the aforementioned settings are not in that file by default, and [0] seems to suggest Debian does not alter the compiled-in defaults either.
Some quick digging in the source suggests that it's simply not enabled by default in ESR 128. I don't know if that's because it's only enabled by default in a later release, or because it's disabled in all ESR releases; I suspect the former. Compare [1] and [2]:
-pref("browser.ml.enable", false); # in upstream/128.14.0esr
+pref("browser.ml.enable", true); # in upstream/142.0.1
The other pref, browser.ml.chat.enable[d] is not mentioned in that file at all.
(edit: according to [3a] and [3b], it's browser.ml.enable and browser.ml.chat.enabled... yay for consistency, I guess)
You can preload them now in your profile `user.js` - FF will ignore any settings it does not know about, it's "safe" to leave old things that got deleted and add new things coming in the next ESR without harm (that I'm aware, been doing it for years). A user.js is portable, not relying on any given vendor configurations.
