Review Mozilla 1738983: Enable Background Update by default on Release starting in FX96

changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration

added Next Sponsor 131 Q3 labels

assigned to @pierov

mentioned in issue tor-browser-spec#40030 (closed)

marked this issue as related to tor-browser-spec#40030 (closed)

Commit is 21fe3d1d.

So, Tor Browser 102 has background updates automatically enabled:

We should add --disable-update-agent to our mozconfigs (macOS, too, as per Bug 1687783/commit b1187e89).

So, we won't have more problems with this functionality.

Should we disable background tasks, too?

They are for privileged code, and searching for EXTRA_JS_MODULES.backgroundtasks finds the updater, which we disable with that flag, and telemetry... So things we don't exactly want, but that we disable also in other ways .

My main concern here is that background tasks could prevent firefox.exe from being deleted ASAP because it's running background tasks... But I am not sure this is really a possibility.

One of the main reasons we don't want the update service is that it's privileged code.

However, background tasks should be run as a user. Apart from this:

My main concern here is that background tasks could prevent firefox.exe from being deleted ASAP because it's running background tasks... But I am not sure this is really a possibility.

do they have other disadvantages? Possibly disk leaks?

But from what I understand, the user won't have a Firefox process that keeps running forever. Rather, from time to time it does some maintenance, then stop.

Sounds like we should do an audit of the existing background tasks and verify we don't need them for anything. Hopefully we don't need them (though I suspect this will be a losing battle long term if Mozilla decides they are a super neat place to put functionality).

If we don't need them, I'd like the system's backend ifdef'd out if possible. Ideally we would trigger a build-time error if it gets used in the future but we'll see.

verify we don't need them for anything

What about the updates after closing Tor Browser?

removed Next label

added Doing label

removed Doing label

added Next label

added Disk Leak Security labels

removed Q3 label

added Q4 label

added Backlog label and removed Next label

@richard I think we could disable the telemetry background task, and keep the updater.

In case, we should remove

EXTRA_JS_MODULES.backgroundtasks += [
    "pings/BackgroundTask_pingsender.jsm",
]

from toolkit/components/telemetry/moz.build.

Otherwise, if you want to remove the updater, too, we could entirely disable the feature (--disable-backgroundtasks).

Please notice that we currently disable the updater's background task on Windows because of a Rust/mingw bug, that we could even solve, since we rebuild the compiler, for our builds.

So, the updater as background task would work only on macOS.

I think it is okay to have it, since it doesn't run anything with privileges?

added Needs Revision label

I'm inclined to say just disable it everywhere rather than having it only enabled on one of our platforms.

Okay. Should we leave this issue open for future follow-ups?

I double checked because I wanted to copy the same flag we use for Windows... and discovered that we don't use it for.

Moz's mingw mozconfigs use that option, but we don't .

So, @richard are you confirming that you want that disabled?

I think it's disabled by defualt when mingw windows builds are detected (though I may be mis-remembering). Assuming this doesn't interfere with the updater let's go ahead and explicitly disable it and then revisit this for esr115 next year.

Okay, will do. At that point I will disable background tasks, too.

and then revisit this for esr115 next year.

New issue, or this one?

Should we create the label already?

We already have it :3

Done in !387 (merged).

Unassigning myself for now, in case someone else wants to take it when it is the moment for 115.

removed Needs Revision label

added FF115-esr label

mentioned in merge request !387 (merged)

unassigned @pierov

I was able to reproduce this issue on the latest Tor Browser alpha build (12.0a3). my test environment was a HP Laptop 15 – bs0xx running Windows 10 Home, Version 21H2 19044 x 64.

Steps To Reproduce

Start tor browser.
Go to "open application menu" at the upper right of the browser.
Click on settings and scroll down to Tor Browser Update.

Hi @Temi, we're shipping the patch in 12.0a4, that's why you can reproduce in 12.0a3 .

Oh Okay. When will 12.0a4 be out ?

We still have to build it.

We've pushed the rebased branch yesterday. Normally, we'd start preparing the release just after that, but we still have some blockers.

The current ETA is about end of the month.

Okay Great. Will the issue be closed after shipping the patch in 12.0a4 and what are the blockers been experienced ?

Will the issue be closed after shipping the patch in 12.0a4

Usually they are, this won't be, because we want to follow up on it next year when switching to 13.0 based on 115.

We know that this feature is there, and if it's a feature or an antifeature for us.

So, we'd like you to go deeper with it, not just to say "it's there", but if it's really a disk leak, and what are the negative effects of it in general (if any), or if disabling it was overcautious.