top | item 45076771

(no title)

olivergregory | 6 months ago

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.

discuss

order

yunruse|6 months ago

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.

[0] https://github.com/mozilla-firefox/firefox/blob/7b42e629fdef... exports a SmartTabGroupingManager, though how or why that is used without being asked eludes me

[1] https://www.onelook.com/thesaurus/ Can be helpful in a pinch when a word's on the tip of your tongue, though its synonyms aren't always perfect.

squigz|6 months ago

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?

aragilar|6 months ago

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.

st3fan|6 months ago

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.

neobrain|6 months ago

It was also caught during progressive rollout, i.e. it never affected anyone who had disabled "studies" in their preferences.

olivergregory|6 months ago

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.

marc_abonce|6 months ago

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.

tremon|6 months ago

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)

[0] https://sources.debian.org/src/firefox-esr/128.14.0esr-1~deb...

[1] https://salsa.debian.org/mozilla-team/firefox/-/blame/upstre...

[2] https://salsa.debian.org/mozilla-team/firefox/-/blame/upstre...

[3a] https://salsa.debian.org/mozilla-team/firefox/-/blame/esr128...

[3b] https://salsa.debian.org/mozilla-team/firefox/-/blame/esr128...