2000708 - Desktop launcher tries to download the stub installer from an incorrect URL

Status: VERIFIED FIXED

(Firefox :: Installer, defect, P1)

Description

[Duncan McIntosh [:dmcintosh]]

It looks like the desktop launcher tries to download using a path of /https://download.mozilla.org/..., instead of that being the full URI. Example HTTP request (when modified to not use HTTPS):

GET /https://download.mozilla.org/?os=win64&lang=en-US&product=firefox-nightly-stub HTTP/1.1
Connection: Keep-Alive
Accept: application/x-msdos-program
User-Agent: FirefoxDesktopLauncher/0.1.0
Host: download.mozilla.org

which the server helpfully redirects to /https:/download..., before 404'ing.

Wireshark says that the full URL is

http://download.mozilla.org/https://download.mozilla.org/?os=win64&lang=en-US&

which has a chunk off of the end (??) but also shows that this isn't correct.

It's possible that this worked until some deployment changes a week or two ago (internal JIRA link), but I'm not sure.

Comment 1

[Duncan McIntosh [:dmcintosh]]

Attachment: Bug 2000708 - Do not include the scheme or hostname in the path used to download the stub installer. r=cdupuis!

Comment 2

[Duncan McIntosh [:dmcintosh]]

I think this is more of an S3—it'll fall back to a secondary codepath, so it'll just open another browser (probably Edge) so the user can download Firefox themselves, which I think is an OK workaround. It's still an easy-to-fix annoyance that should be resolved once we verify that all of the involved code works.

(In fact, it's actually a bit lucky that it's broken—most of the new code in bug 2000411 can't run right now, minimizing risk in the uplift.)

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b18c9e27e744
https://hg.mozilla.org/integration/autoland/rev/e6226a2d1903
Do not include the scheme or hostname in the path used to download the stub installer. r=cdupuis

Comment 4

[Cristian Tuns]

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

Comment 5

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Desktop launcher will fail to download the installer, and will open a download page in another browser instead of prompting the user to install directly.

[Re automated testing: the string itself is covered by tests, most other things that use the string aren't.]

• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On relevant versions of Windows:

1. Install Firefox.
2. Copy 'C:\Program Files\Mozilla Firefox\desktop-launcher\desktop-launcher.exe' to the desktop. Call it 'Anything.exe' (or whatever name you want).
3. Uninstall Firefox.
4. Run 'Anything.exe' without internet access. It should open the default browser (probably Edge) to "https://www.mozilla.org/firefox/new/", and that browser will probably complain that it's offline. Close the other browser.
5. Run 'Anything.exe' with internet access. Critically, you should see a prompt asking you whether you'd like to install Firefox. (Testing whether said installation works is optional, the prompt working should be sufficient.)

• Risk associated with taking this patch: medium
• Explanation of risk level: Risks: The code modified in bug 2000411 is now actually accessible. Bug 2000411 also shows that small issues in the desktop launcher can be very severe.
  Anti-risks: This will only affect users that do not have Firefox installed (e.g. moving between computers). This is a straightforward fix that hasn't earned any bugs in Nightly. This path structure is also used in one of the pre-existing tests.
• String changes made/needed: no
• Is Android affected?: no

Comment 6

[Duncan McIntosh [:dmcintosh]]

Attachment: Bug 2000708 - Do not include the scheme or hostname in the path used to download the stub installer.

Original Revision: https://phabricator.services.mozilla.com/D272948

Comment 7

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Desktop launcher will fail to download the installer, and will open a download page in another browser instead of prompting the user to install directly.

[Re automated testing: the string itself is covered by tests, most other things that use the string aren't.]

• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On relevant versions of Windows:

1. Install Firefox.
2. Copy 'C:\Program Files\Mozilla Firefox\desktop-launcher\desktop-launcher.exe' to the desktop. Call it 'Anything.exe' (or whatever name you want).
3. Uninstall Firefox.
4. Run 'Anything.exe' without internet access. It should open the default browser (probably Edge) to "https://www.mozilla.org/firefox/new/", and that browser will probably complain that it's offline. Close the other browser.
5. Run 'Anything.exe' with internet access. Critically, you should see a prompt asking you whether you'd like to install Firefox. (Testing whether said installation works is optional, the prompt working should be sufficient.)

• Risk associated with taking this patch: medium
• Explanation of risk level: Risks: The code modified in bug 2000411 is now actually accessible. Bug 2000411 also shows that small issues in the desktop launcher can be very severe.
  Anti-risks: This will only affect users that do not have Firefox installed (e.g. moving between computers). This is a straightforward fix that hasn't earned any bugs in Nightly. This path structure is also used in one of the pre-existing tests.
• String changes made/needed: no
• Is Android affected?: no

Comment 8

[Duncan McIntosh [:dmcintosh]]

Attachment: Bug 2000708 - Do not include the scheme or hostname in the path used to download the stub installer.

Original Revision: https://phabricator.services.mozilla.com/D272948

Comment 9

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/aed76704931b
https://hg.mozilla.org/releases/mozilla-beta/rev/d9243b0a56d6

Comment 10

[Ciprian Georgiu, Desktop QA]

Hi, dmcintosh! We’ve managed to reproduce the issue using the STR from comment 5 on Firefox Beta 5 with Windows 11. However, we want to double-check if our verification is sufficient, since we did not use Wireshark to inspect the actual URLs.

We reproduced that on an affected build, the “Anything.exe” file is detected as HTML, which triggers the OS prompt when clicking the file (step 5 from comment 7), and it opens the https://www.firefox.com/en-US/?redirect_source=mozilla-org&utm_campaign=SET_DEFAULT_BROWSER page.

On a fixed build (Beta 146.0b6), the prompt is correctly displayed, asking the user if they would like to install Firefox - see image. Confirming as well that the installation works correctly.

On the latest Nightly 147.0a1, I’m getting an error message when double-clicking “Anything.exe” - see image. After the error appears, the prompt is displayed correctly, and the installation works as expected.

Can you let us know if this verification is enough and share your thoughts regarding the error message on the latest Nightly 147.0a1? We can file a separate bug if this turns out to be a valid issue.

Comment 11

[Duncan McIntosh [:dmcintosh]]

(In reply to Ciprian Georgiu, Desktop QA from comment #10)

Hi, dmcintosh! We’ve managed to reproduce the issue using the STR from comment 5 on Firefox Beta 5 with Windows 11. However, we want to double-check if our verification is sufficient, since we did not use Wireshark to inspect the actual URLs.

Makes sense, you wouldn't be able to use Wireshark on a real build anyways since it uses HTTPS.

We reproduced that on an affected build, the “Anything.exe” file is detected as HTML,
which triggers the OS prompt when clicking the file (step 5 from comment 7), and it opens the https://www.firefox.com/en-US/?redirect_source=mozilla-org&utm_campaign=SET_DEFAULT_BROWSER page.

Opening that page is what I'd expect for an affected build, but I don't understand the part about it detecting as HTML. It should be an EXE that opens a webpage (and I guess the prompt is asking what browser to open it in)—does that match what you saw, or is something else going on?

On a fixed build (Beta 146.0b6), the prompt is correctly displayed, asking the user if they would like to install Firefox - see image. Confirming as well that the installation works correctly.

That's what I'd expect! :D (The prompt comes from the stub installer, so if we got here the URL has to be correct.)

On the latest Nightly 147.0a1, I’m getting an error message when double-clicking “Anything.exe” - see image. After the error appears, the prompt is displayed correctly, and the installation works as expected.

That's not what I'd expect! I also can't reproduce it on my end, and it's not clear why it's looking there. Did any 'Desktop\nigh*' exist before (different install, used that instead of 'Anything.exe', ...?) Does it reproduce in a fresh VM (as in, install Firefox, copy the launcher, uninstall Firefox, run)?

I'm also thinking that could happen if you deleted the Firefox installation instead of uninstalling it properly, but I don't know how you usually test these things. If that's what happened, it might still be worth a bug so we can avoid that error message.

Can you let us know if this verification is enough and share your thoughts regarding the error message on the latest Nightly 147.0a1? We can file a separate bug if this turns out to be a valid issue.

For beta this verification should be enough. If you can still reproduce the Nightly issue, can you report that as another bug?

Thanks for testing this!

Comment 12

[Ciprian Georgiu, Desktop QA]

(In reply to Duncan McIntosh [:dmcintosh] from comment #11)

Opening that page is what I'd expect for an affected build, but I don't understand the part about it detecting as HTML. It should be an EXE that opens a webpage (and I guess the prompt is asking what browser to open it in)—does that match what you saw, or is something else going on?

Yes, it does. Thanks!

That's not what I'd expect! I also can't reproduce it on my end, and it's not clear why it's looking there. Did any 'Desktop\nigh*' exist before (different install, used that instead of 'Anything.exe', ...?) Does it reproduce in a fresh VM (as in, install Firefox, copy the launcher, uninstall Firefox, run)?

I tried with a different laptop and I cannot reproduce it there. It might have something to do with a previously desktop laucher that had the same name and was later deleted, or possibly with the fact that I have two OS user profiles on that laptop. I’ll investigate this after I return from PTO and will file a bug if I find a reliable way to reproduce it.

I'll close this bug verified as fixed per my previous verification.