1763824 - [Windows 10] The Firefox browser is not set as default when clicking the “Make Firefox my default” button from “Thank you” spotlight modal /“about:welcome” screen after browser update

Status: VERIFIED FIXED

(Firefox :: Installer, defect, P1)

Description

[Simona Rosu [:srosu], Ecosystem QA]

Attachment: upgradingUsers_SetAsDefault.gif

[Notes]:

• This issue is only reproducible only after a browser update.
• This issue is also reproducible if the browser is set as default from the "about:preferences" page or from the "Make default browser" prompt.

[Affected versions]:

• Firefox Beta 100.0b4 (Build ID: 20220410195727)
• Firefox Nightly 101.0a1 (Build ID: 20220410213958)

[Affected Platforms]:

• Windows 10 x64

[Prerequisites]:

• Have a Firefox Nightly/Beta 99 browser installed.
• Have a new Firefox profile.
• Don’t have the Firefox browser set as default.

[Steps to reproduce]:

1. Open the Firefox browser with the profile from prerequisites.
2. Update the browser to the latest version.
3. Click the “Make Firefox my default” button from the “Thank you” spotlight.
4. Observe what happens.

[Expected result]:

• The Firefox browser is set as default.

[Actual result]:

• The OS settings window is opened and the Firefox browser is not set as default.

[Additional Notes]:

• This issue is not reproducible for new users.
• I didn't manage to investigate this issue on Nightly, but I'll come back with additional details on Monday.
• Attached is a screen recording of the issue.

Comment 1

[Simona Rosu [:srosu], Ecosystem QA]

After further investigations, I've found out the following:

• This issue is also reproducible on Windows 10, versions >1803.
• This issue is also reproducible if the browser is set as default from the "about:preferences" page or from the "Make default browser" prompt.
• This issue is also reproducible on the latest Firefox Nightly 101.
• This issue is not reproducible on Firefox Release 99.0.

I've updated the title, description, and severity of this issue accordingly.

Comment 2

[Ed Lee :Mardak]

Attachment: checkAllProgIDsExist failed

Could 1-click set default have regressed with bug 1762100?

Comment 3

[Ed Lee :Mardak]

[Tracking Requested - why for this release]: Potentially regressed by bug 1762100. Telemetry shows significant spike in progID exceptions on 100 beta. Upgrade spotlight shown to users upgrading to Fx100 can have a primary button of setting default currently falling back to users manually changing the default browser instead of 1-click from Firefox.

Comment 4

[Nick Alexander :nalexander [he/him]]

Clearly something is going wrong with the new FirefoxPDF ProgID, but I'm not sure what it is. The initial report is consistent with the ProgIDs not being added after update in PostUpdate, so I'll start digging there. But it's also consistent with having both FirefoxHTML and FirefoxPDF somehow impacting the default browser choice, in somewhat the same manner as Bug 1764277. I'll try to get to the bottom of it now.

:srosu: was the Firefox installation in question installed by the installer? Or was it unpackaged from a ZIP package?
:mardak: same Q.

I couldn't find a reasonable way to test this manually on the tight timeline I was working with, so I appreciate QA "testing it live", as it were.

Comment 5

[Nick Alexander :nalexander [he/him]]

I can verify that this isn't working; clearly something with PostUpdate is incorrect, so the FirefoxPDF prog ID doesn't exist.

Comment 6

[Ed Lee :Mardak]

I just tested installing 99.0b1 from https://ftp.mozilla.org/pub/firefox/releases/99.0b1/win64/en-US/Firefox%20Setup%2099.0b1.exe on top of a 100 beta standard installation on windows 1809 then upgraded it back to 100 from within Firefox, but I wasn't able to reproduce the setting default not-1-click behavior. I did run into the issue when making the screenshot attachment 9271793 [details], and that was also with installing, but I don't remember exactly from/to. Maybe it was a paveover install when it failed? I'll keep trying to get it to fail more consistently.

Comment 7

[Simona Rosu [:srosu], Ecosystem QA]

This issue is reproducible in both cases: using an installed or extracted build.
I just rechecked the issue and I managed to reproduce it again in both cases (updating the Firefox Beta 98.0b9 installed and extracted build). Tested on Windows Sandbox ( Windows 10 Enterprise, OS build 19041.1586).
I’ve also attached here a screen recording with the entire flow.

Comment 8

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1763824 - Always add/update `FirefoxPDF-*` ProgID in Windows PostUpdate. r?mhowell

This was simply an oversight on my part: I didn't appreciate that
freshly introduced ProgIDs need to be added or updated unconditionally
in PostUpdate.

I've tested this by copying the fresh helper.exe into an existing
installation directory, running uninstall\helper.exe /PostUpdate
manually, verifying the expected ProgIDs exist in HKCR, and then
verifying that "Make default" within Firefox succeeds.

At some point we should do the same for FirefoxHTML-* and
FirefoxURL-*, but this patch should be uplifted to Beta 100 and I
don't want to introduce additional risk.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1c5b7b058b6f
Always add/update `FirefoxPDF-*` ProgID in Windows PostUpdate. r=mhowell,bhearsum

Comment 10

[Nick Alexander :nalexander [he/him]]

Comment on attachment 9272207 [details]
Bug 1763824 - Always add/update FirefoxPDF-* ProgID in Windows PostUpdate. r?mhowell

Beta/Release Uplift Approval Request

• User impact if declined: "Make default" will always pop the Windows App Default UI rather than work silently. (At least the first time: the second time should succeed automatically, since the fallback to the Windows App Default UI writes the registry values needed for the silent method to succeed.)
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: QA is aware of the steps and in fact found the issue. (Twice: two separate QA teams!)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is tiny, has been reviewed by two reviewers, and has been manually tested and reviewed by the developer. We could wait for Nightly testing but that will entail missing the last early beta (I think). The likelihood of fallout is very low, where-as the issue itself is significant.
• String changes made/needed:

Comment 11

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/1c5b7b058b6f

Comment 12

[Simona Rosu [:srosu], Ecosystem QA]

I‘ve verified this issue using the latest Firefox Nightly101.0a1 (Build ID: 20220415092909) on Windows 10 x64, macOS 11.6, and Ubuntu 20.04.

• The Firefox browser is set as default when clicking the “Make Firefox my default” button from the “Thank you” spotlight modal /“about:welcome” screen after the browser update.

Comment 13

[Dianna Smith [:diannaS]]

Comment on attachment 9272207 [details]
Bug 1763824 - Always add/update FirefoxPDF-* ProgID in Windows PostUpdate. r?mhowell

Approved for 100.0b7

Comment 14

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2ba7da937283

Comment 15

[Simona Rosu [:srosu], Ecosystem QA]

I‘ve verified this issue using Firefox Beta 100.0b7 (Build ID: 20220417185951) on Windows 10 x64.

• The Firefox browser is set as default when clicking the “Make Firefox my default” button from the “Thank you” spotlight modal /“about:welcome” screen after the browser update.

Comment 16

[Nick Alexander :nalexander [he/him]]

(In reply to Simona Rosu [:srosu], Ecosystem QA from comment #15)

I‘ve verified this issue using Firefox Beta 100.0b7 (Build ID: 20220417185951) on Windows 10 x64.

• The Firefox browser is set as default when clicking the “Make Firefox my default” button from the “Thank you” spotlight modal /“about:welcome” screen after the browser update.

:srosu: you verified by upgrading an older Beta to 100.0b7, correct? The fix only impacts the update flow.

Comment 17

[Ed Lee :Mardak]

nalexander, does there need to be some special "cleaning up" of registry keys or something to get to a pre-100 state to QA correctly? Comment 10 seems to suggest a "second time" will happen to work already

Comment 18

[Nick Alexander :nalexander [he/him]]

(In reply to Ed Lee :Mardak from comment #17)

nalexander, does there need to be some special "cleaning up" of registry keys or something to get to a pre-100 state to QA correctly? Comment 10 seems to suggest a "second time" will happen to work already

Yes. You'd either need to uninstall with the uninstaller, or you'd need to install to a different location (so that the registry keys have a different installation directory hash). It's easy enough for me to test this, so I'll try now-ish.

Comment 19

[Nick Alexander :nalexander [he/him]]

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

(In reply to Ed Lee :Mardak from comment #17)

nalexander, does there need to be some special "cleaning up" of registry keys or something to get to a pre-100 state to QA correctly? Comment 10 seems to suggest a "second time" will happen to work already

Yes. You'd either need to uninstall with the uninstaller, or you'd need to install to a different location (so that the registry keys have a different installation directory hash). It's easy enough for me to test this, so I'll try now-ish.

I've verified that updating from 99.0b8 to 100.0b7 allows "Make Firefox default" to continue work, with or without the browser.shell.setDefaultPDFHandler Gecko preference enabled.

Comment 20

[Simona Rosu [:srosu], Ecosystem QA]

@Nick, for verifying this issue, I've used Firefox Beta 99.0b8 and 98.0b9 builds installed on Windows 10 v21H1 x64 and Windows 10 v1803 x64, which I’ve updated to the latest version of Beta (100.0b7). After the browser's update, I can confirm that the Firefox browser is 1-click set as default without opening the OS window.