1626887 - Firefox .msi installer does not create the Default Browser Agent task in Task Scheduler

Status: REOPENED

(Toolkit :: General, defect, P3)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Affected versions

• Firefox 75.0
• Firefox 76.0a1

Affected platforms

• Windows 7, 8.1, 10 (X64)

Steps to reproduce

1. Download a .msi installer from the archive
2. Proceed and install it
3. After the installation process is done, access Task Scheduler
4. Expand Task Scheduler Library

Expected result

• Mozilla folder is created and the Default Browser Agent's task is active

Actual result

• Mozilla folder is created but it's empty

Regression range

• No regression, as it was just implemented

Additional notes

• It seems that only x64 versions of Windows are affected, as on Windows 7 (x86) the task was successfully installed by a .msi installer.

Comment 1

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

Catalin and I discussed this on Slack and agreed it's not a blocker since only the MSI is affected. I have an idea for a fix that I'll attempt, but I don't think it would merit uplift at this stage.

Comment 2

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

Attachment: Bug 1626887 - Fallback for when registering the default browser agent task fails in the MSI. r=agashlin

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b6fd7b67139a
Fallback for when registering the default browser agent task fails in the MSI. r=agashlin

Comment 4

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/b6fd7b67139a

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mhowell, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 6

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

This fix only affects the MSI, so it doesn't really seem important enough to me.

Comment 7

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

I have tried verifying this 77.0(ID:20200525134724) , 78.0a1(ID:20200525134724) on multiple Windows 10x64 and the issue still reproduces with the same repro steps as in the Description.

I have tried verifying with a build from treeherder from comment 3 and comment 4 but there is no target.msi build to check this.

Comment 8

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

Thanks for verifying this. I can reproduce the bug as well, so maybe this fix just never actually worked. I'll look into it.

Comment 9

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

I think what's happening is this:
After this bug's patch, in the MSI install scenario we're attempting to register the task twice. The first time (the attempt that was there before) fails to create the task because it can't get the right user, but before that fails it did successfully create our task folder, and it's done that as SYSTEM. The second attempt (the one that the patch here added) then comes along running as the unelevated interactive user and it can't create the task because that user doesn't have write permissions in the already existing folder, because the task scheduler service wouldn't have seen the need to create it that way.
So it seems like what we need to do is, if creating the task fails during an attempt where we have also created the task folder, we should be deleting the folder. Really we should have been doing that anyway just so we clean up after ourselves properly, but nobody thought about it before.

Comment 10

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

Attachment: Bug 1626887 Followup - Don't leave a task folder around when we fail to create a scheduled task. r=bytesized

This is needed to prevent a failed attempt to create the task from blocking
out the ability to try again later if the two attempts are run under different
user contexts, where the second is more limited than the first, because the
less privileged attempt is unlikely to have permission to write to the folder
created by the more privileged one. In particular the MSI installer runs into
this scenario, because it makes one attempt to register the task as SYSTEM,
followed by a second attempt as the unelevated interactive user.

This is also nice because it keeps us from leaving an empty folder behind
under any circumstances, not just this specific situation.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f158534871a
Followup - Don't leave a task folder around when we fail to create a scheduled task. r=bytesized

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/6f158534871a

Comment 13

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

I have tried this on 79.0a1 (ID:20200603214922), 77.0.1(ID:20200602222727) and 78.0b2(ID:20200602134412) with Windows 10x64 and I still manage to reproduce the issue with the same steps as in Description.

Comment 14

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

I've finally gotten around to trying to reproduce this again with release 78.0.2, and I am not able to do so on my own systems; I always see the task being created from the MSI. I'm not sure what to do here next.

Comment 15

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: Task Sched 80.0a1.png

Tried with .msi installers for both 79.0b7 and 80.0a1 (2020-07-13) and still had no success in finding the task, only the mozilla folder will be created in Task Scheduler.

If installing with an .exe build, the task is present. This was done on a relatively clean Windows 10. I'll attach a screenshot with the latest Nightly here.

Comment 16

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

Hmm. That's the behavior I was getting before these patches, but after I do see the task get created.

Can you check in the Windows Event Viewer under the Application log for a message from the Default Browser Agent, and post the contents of that event's Details tab here? Thanks.

Comment 17

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: Task error.png

Yes, here's what Event Viewer is looking like in this case. The full message in the description is as follows:

"The description for Event ID 1332 from source Firefox Default Browser Agent cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

0x80070534 in RegisterTask:192"

Comment 18

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: image.png

Hello!
It seems that we are still able to reproduce the issue with Firefox 83.0b5 MSI installer and Firefox 84.0a1 MSI installer on Windows 10x64 and 10x86. Only an empty Mozilla folder is created in Task Scheduler and this error is displayed in Windows Event Viewer: No mapping between account names and security IDs was done. (see attached screenshot).
Should we file a new bug or reopen this one? Thank you!

Comment 19

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

That's definitely the same bug, so I'll reopen this. Although I admit I'm not immediately sure what to do with it if the earlier patch was incomplete or couldn't support some scenarios that I didn't think of, and I don't know when I'm going to have a chance to look into it. Thanks for retesting this.