1876714 - installing lower Firefox versions shows error popup but installs successfully: "This profile was last used with a newer version of this application. Please create a new profile."

Status: NEW

(Toolkit :: Background Tasks, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

One of my test environments with Firefox 121.0.1 x64 on Windows 10 got unintentionally updated to Firefox 122.0.

With Firefox closed, an install of 121.0.1 into the same folder showed the error message: "This profile was last used with a newer version of this application. Please create a new profile." during install.

Acknowledging the message lets the installer complete, 121.0.1 has been installed and launches without issues.

Even uninstalling Firefox from the install directory (which also shows the error message) and installing 121.0.1 again shows the error message again.

Have there been any changes in the last 3 months or so regarding this? Installing downgrades had been no issues in the past.

Comment 1

[Dave Townsend [:mossop]]

This sounds like the installer and uninstaller are executing Firefox. I vaguely recall that we do this to make sure nimbus is set up right or something. But because the default profile has been used by a more recent version it shows the downgrade error. Presumably the installer is already passing some kind of argument to make Firefox quit without fully opening, we should also make that cause us to just fail silently in the case of downgrade.

Comment 2

[Dave Townsend [:mossop]]

Molly, do you still own the installer? Do you know why and how it is launching Firefox?

Comment 3

[Molly Howell (she/her) (mostly inactive)]

(I'm the module owner yes, but really only because nobody else wants it; the desktop integration team do all the actual work in there these days)

I actually don't think this is the Nimbus thing; that happens during the normal post-install startup (that is, after the end of the install), and not at all during uninstall.

I think this sounds more like the background task registration step. It does run during uninstall as well, and it would be using its own profile. It's not meant to be re-using a profile such that it could generate this error though. @nalexander, thoughts?

Comment 4

[Dave Townsend [:mossop]]

(In reply to Molly Howell (she/her) [:mhowell] from comment #3)

(I'm the module owner yes, but really only because nobody else wants it; the desktop integration team do all the actual work in there these days)

I actually don't think this is the Nimbus thing; that happens during the normal post-install startup (that is, after the end of the install), and not at all during uninstall.

I think this sounds more like the background task registration step. It does run during uninstall as well, and it would be using its own profile. It's not meant to be re-using a profile such that it could generate this error though. @nalexander, thoughts?

Ah but it appears to use a persistent profile (as it isn't listed here). Nick, does it make sense to somehow create a new profile in this case?

Comment 5

[Robin Steuber (she/her) [:bytesized]]

(In reply to Dave Townsend [:mossop] from comment #4)

Ah but it appears to use a persistent profile (as it isn't listed here). Nick, does it make sense to somehow create a new profile in this case?

The logic there is inverted. It doesn't use a persistent profile because it isn't listed there. Or, at least, it isn't supposed to.

Comment 6

[Dave Townsend [:mossop]]

(In reply to Robin Steuber (they/them) [:bytesized] from comment #5)

(In reply to Dave Townsend [:mossop] from comment #4)

Ah but it appears to use a persistent profile (as it isn't listed here). Nick, does it make sense to somehow create a new profile in this case?

The logic there is inverted. It doesn't use a persistent profile because it isn't listed there.

Oh yes, missed that. Ok then it's not clear why this would be happening.

Comment 7

[Nick Alexander :nalexander [he/him]]

What a fascinating interaction. The logic above seems correct to me: we invoke tasks named for install and uninstall, but they all should have ephemeral profiles (partly to avoid these upgrade/downgrade concerns).

But https://searchfox.org/mozilla-central/rev/cee2c396081d950f9e3401113fb179999e404ab8/browser/installer/windows/nsis/shared.nsh#170-184 shows that we also invoke the defaultagent task, which does have a persistent profile to register-task and unregister-task. And that could show exactly this issue. This would have changed with Bug 1838755 in Firefox 120, I think. It should also be consistent: I'll try to repro locally.

Task definitions are cheap: the simplest thing is to spin out a schedule_defaultagent task that does the existing work but uses an ephemeral profile. The only other solution I can think of is to ignore downgrade errors in background tasks since they're so unlikely to cause issues.

nrishel: thoughts?

Comment 8

[Robin Steuber (she/her) [:bytesized]]

(In reply to Nick Alexander :nalexander [he/him] from comment #7)

Task definitions are cheap: the simplest thing is to spin out a schedule_defaultagent task that does the existing work but uses an ephemeral profile. The only other solution I can think of is to ignore downgrade errors in background tasks since they're so unlikely to cause issues.

It sounds like the entire purpose of this task would be to run at install time. Could this functionality be folded into the existing install task?

Comment 9

[Dave Townsend [:mossop]]

(In reply to Nick Alexander :nalexander [he/him] from comment #7)

Task definitions are cheap: the simplest thing is to spin out a schedule_defaultagent task that does the existing work but uses an ephemeral profile. The only other solution I can think of is to ignore downgrade errors in background tasks since they're so unlikely to cause issues.

I'd rather not ignore downgrade errors, if by ignore you mean bypass. While downgrades are generally "ok", they're completely untested and we do occasionally hit startup crashes in unexpected places. Either creating a new profile or clobbering the existing profile would be fine.

Comment 10

[Nick Rishel [:nrishel]]

(In reply to Nick Alexander :nalexander [he/him] from comment #7)

Task definitions are cheap: the simplest thing is to spin out a schedule_defaultagent task that does the existing work but uses an ephemeral profile. The only other solution I can think of is to ignore downgrade errors in background tasks since they're so unlikely to cause issues.

nrishel: thoughts?

I'd prefer to use this as impetus to get D184143 over the line. I'd need to double check, but I think we'd also need to extend the patch to handle scheduling too?