User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

helper.exe /SetAsDefaultAppUser

Actual results:

this command set firefox as default browser and pdf viewer

Expected results:

stop firefox taking over as default pdf viewer

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

every day in the my domain I run a script that restores the default browser settings.
to do this, I launch a command helper.exe /SetAsDefaultAppUser
but now this command also changes the default pdf viewer
can you somehow change the program settings to remove this behavior so that only the default browser changes

every day in the my domain I run a script that restores the default browser settings.
to do this, I launch a command helper.exe /SetAsDefaultAppUser
but now this command also changes the default pdf viewer
can you somehow change the program settings to remove this behavior
so that only the default browser changes
but HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts.pdf\UserChoice
Progid="AcroExch.Document.DC" remains the same

This sounds like a result of Bug 1506416, which allowed Firefox to be set as the default PDF viewer. That is, it registered Firefox as a file handler for PDFs.

Alex AC: Firefox is also registered as a file handler for, say, .html files. And also .svg, .webp, and others. I'm pretty sure /SetAsDefaultAppUser is going to set Firefox as the default app for everything that it is registered to handle. Can you confirm this?

jaws: Firefox uses this internally to set itself as the default browser upon user request. It might be that setting Firefox as the default browser shouldn't also set Firefox as the default handler for PDFs. Is this jumping the gun given the ongoing work to improve PDF handling in Firefox?

NI to me to check the behaviour, and NI to bwinton to redirect responding to #c4.

Yes, I confirm that. launching helper is the easiest way to set the default browser, but it changes the settings for viewing pdf files. maybe you can make additional keys for helper? it is also strange to install Firefox as the default pdf viewer without asking the user if he already has another pdf viewer installed

(In reply to Alex AC from comment #6)

Yes, I confirm that.

Thanks!

launching helper is the easiest way to set the default browser, but it changes the settings for viewing pdf files. maybe you can make additional keys for helper? it is also strange to install Firefox as the default pdf viewer without asking the user if he already has another pdf viewer installed

I do think this is strange behaviour, and probably not desirable, so I'm going to run this around and see what is really intended here. Then we'll think about what the right way to address this is.

Bugbug thinks this bug is a defect, but please change it back in case of error.

Set release status flags based on info from the regressing bug 1506416

Is it stranger than setting us as the default handler for SVG files, when the user may have an SVG Editor previously set?

As part of the PDF project, we took a larger look at what we think we should do, and according to Romain's document at https://docs.google.com/document/d/1BFpd1mNdok0ZbhlKEgExEZKPEmlmQRath_s1AmPtVug/edit (apologies if it's not viewable), we should be the Default for: htm, html, shtml, webp, svg, xml; and Optional for: pdf, xht, xhtml; so it sounds like this is a bug…

:mhowell: do you expect this helper.exe functionality to make a distinction between file extensions, i.e., to make Firefox the default handler for some (.html, etc) and not for others (.xhtml, .pdf, etc)? I'm trying to understand if this is fixing an existing bug in /SetAsDefaultAppUser or adding a nuance, which might require a different flag. Looks like this may have always been wrong (per the desired behaviour in #c10)?

Personally from my own perspective I would not expect any distinction; I would expect the command to make us the default for everything that we register as a potential default for. Also, these helper.exe flags aren't really intended as a public user interface, so a change to their behavior when invoked directly is tough for me to think of as a defect. That fact also makes we worry about adding a more limited second version of the command, because then that version wouldn't have any internal users and wouldn't really get tested.

All that said though, I don't actually have strong feelings about whether .pdf is included in this particular list or not, and it sounds like there's basically consensus that this is a problem, so let's change it.

We started distributing the MSI of Firefox 78 ESR. Fortunately, for now to only a few Windows 10 PCs, because we discovered that the PDF association, after the MSI installation, is reset and not associated to Adobe Reader DC anymore.
This is a stopper for us because we have about 1200 PCs with many "newbie" users and we cannot tell to all to choose Adobe Reader DC.

I noticed that the severity of this bug is set to "S3".
From your documentation https://wiki.mozilla.org/BMO/UserGuide/BugFields
it means:

"S3 (Normal) Blocks non-critical functionality and a work around exists "

If there is an work around, what is it?

(In reply to Luca M. from comment #14)

I noticed that the severity of this bug is set to "S3".
From your documentation https://wiki.mozilla.org/BMO/UserGuide/BugFields
it means:

"S3 (Normal) Blocks non-critical functionality and a work around exists "

If there is an work around, what is it?

Hi Luca! For any individual user, the work-around is clear: change the association manually. For an administrator such as yourself, the work-around is the same -- figure out how to change the association manually for the administered devices -- although I understand that it's not easy to arrange that.

mkaply: it sounds like this might impact enterprise users, and it's in ESR 78. Do you have signal suggesting that this is an issue?

Do you agree with bwinton's suggestion in #c10, namely to make the PDF (and a few other) registrations optional? I will investigate in the interim.

Yes, I specifically pointed Luca here from the enterprise list.

I'm not sure whether the right fix is to allow additional parameters to the MSI install to not take some handlers?

Or maybe the silent installs shouldn't take certain handlers?

Or maybe we should see if PDF is already taken by Acrobat and not take it?

I don't know if there are good answers.

How can installer take over default apps on Windows 10? I thought this bug is only relevant to Windows 7. The reporter (comment #0) uses Windows 7.

(In reply to Luca M. from comment #13)

We started distributing the MSI of Firefox 78 ESR. Fortunately, for now to only a few Windows 10 PCs, because we discovered that the PDF association, after the MSI installation, is reset and not associated to Adobe Reader DC anymore.
This is a stopper for us because we have about 1200 PCs with many "newbie" users and we cannot tell to all to choose Adobe Reader DC.

Hi Luca, can you confirm that this is happening (only) on Windows 7 ? Thank you!

Luca said "for now to only a few Windows 10 PCs". Moreover, the PDF association is reset. I guess the operating system detected that we tried to take over the association and reset the association. We should not try to take over associations on Windows 10.

Hi Rachel - do you want to resolve this wontfix, or do you intend make changes here?

(In reply to Jens Stutte [:jstutte] from comment #18)

Hi Luca, can you confirm that this is happening (only) on Windows 7 ? Thank you!

I'm not Luca but... i confirm this annoying bug on Windows 7; i doubt it apply on Win10, because in Win10 there's a different approach on setting default application, and so probably /SetAsDefaultAppUser does not work at all.

Anyway, for me apply for Win7.

(In reply to Jens Stutte [:jstutte] from comment #18)

(In reply to Luca M. from comment #13)

We started distributing the MSI of Firefox 78 ESR. Fortunately, for now to only a few Windows 10 PCs, because we discovered that the PDF association, after the MSI installation, is reset and not associated to Adobe Reader DC anymore.
This is a stopper for us because we have about 1200 PCs with many "newbie" users and we cannot tell to all to choose Adobe Reader DC.

Hi Luca, can you confirm that this is happening (only) on Windows 7 ? Thank you!

Sorry for the late of my response. I do not know, this "feature" is tested on Windows 10 PCs.

We set all protocols as default here. We should call SetAppAsDefault for each extensions and protocols that we want to set as default by default (that is, .htm, .html, .shtml, .webp, .xht, .xhtml, http, and https), instead of calling SetAppAsDefaultAll.

I would like to take this unless you are already working on it.

(In reply to Masatoshi Kimura [:emk] from comment #24)

I would like to take this unless you are already working on it.

Please do. Thanks!

(NI just so that you see this response; it's easy to miss responses in the stream of bugmail without NI.)

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

Comment on attachment 9191000 [details]
Bug 1652412 - Do not set as deault .pdf, .svg, ftp:, and mailto: handlers on Windows 7. r?mhowell

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This issue impacts Windows 7 users only.

This is a quality of life issue: Firefox can "steal" the user's default association when setting itself as default. This mostly impacts users who set their default PDF viewer.

• User impact if declined: Poor experience setting Firefox as the default browser on Windows 7 for users who have configured a default PDF viewer.
• Fix Landed on Version: 85
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a small change to the installer. I am not aware of alternatives to this approach that will last, say, a Firefox update cycle.
• String or UUID changes made by this patch: none

Comment on attachment 9191000 [details]
Bug 1652412 - Do not set as deault .pdf, .svg, ftp:, and mailto: handlers on Windows 7. r?mhowell

Approved for 78.7esr.

https://hg.mozilla.org/releases/mozilla-esr78/rev/290bfbbaa1ad