796038 - Default browser prompt shows even after setting defaults for Firefox from control panel

Status: VERIFIED FIXED

(Firefox :: Shell Integration, defect)

Description

[juan becerra [:juanb]]

You get the "would you like to make Firefox your default browser" prompt even after setting defaults from program from the control panel options.


1. Install Firefox
2. When the Default Browser prompt comes up, the one launched by Firefox, select "No."
3. Close the browser
4. Press the Windows key and start typing "default programs" and select it on the left-hand side
5. In the following dialog click on "Set your default programs"
6. Select Firefox from the program list
7. Click on "Set this program as default"

Expected: When I re-launch Firefox I no longer get a prompt to make Firefox my default browser.

Actual: I get prompted to make Firefox my default browser.

The result is similar if you pick the individual http, https, ftp protocols from the list when you select "Choose defaults from this program" (see step5).

Comment 1

[Brian R. Bondy [:bbondy]]

Jim could you take a look at this one? We may want to request it for beta but I think there is not enough time to get it on the train. 

Another way to reproduce this is to use a fresh install, and select the prompt to use Firefox as your default at install time. You'll still get the starutp prompt in that case too.

Comment 2

[Brian R. Bondy [:bbondy]]

Marking for tracking mainly because of the new findings in Comment 1.  I don't think we'll have time to get this in but it's less than desirable for a fresh install of Windows 8 and a fresh install of Firefox, to have selected Firefox as your default browser, and then be prompted at startup if you'd like to set your default browser as well.

The bug is only related to Windows 8.

Comment 3

[Jim Mathies [:jimm]]

Sure I'll take a look.

Comment 4

[bhavana bajaj [:bajaj]]

"wontfix" for FF16 as we are so close to the release.Tracking for FF17,FF18

Comment 5

[Brian R. Bondy [:bbondy]]

I think something is being set in the registry when registering default browser through Firefox that needs to be set during the install.  Probably just defaulting the install to "try" to set default browser always on win8 would fix this.  Note we already have code in the installer to hide the checkbox for default browser.  So I think we just need to default that value.

Comment 6

[Jim Mathies [:jimm]]

Two default values that we check for but Windows does not set for us through control panel:

HKEY_CLASSES_ROOT\http\DefaultIcon
HKEY_CLASSES_ROOT\https\DefaultIcon

Comment 7

[Jim Mathies [:jimm]]

Actually four:

HKEY_CLASSES_ROOT\http\DefaultIcon
HKEY_CLASSES_ROOT\https\DefaultIcon
HKEY_CLASSES_ROOT\http\shell\open\command
HKEY_CLASSES_ROOT\https\shell\open\command

Comment 8

[Jim Mathies [:jimm]]

Hmm, http and https under root are an amalgamation of ie and chrome settings. We're still the default, but Windows doesn't update any of this information.

Comment 9

[Brian R. Bondy [:bbondy]]

So I think we should simplify the IsDefaultBrowser handling when it is checking for protocol only, so that it only checks the http defaults and nothing else. 

To do this we would use the IID_IApplicationAssociationRegistration interface that we already use, but only do that.

hr = pAAR->QueryCurrentDefault(L"http", AT_URLPROTOCOL, AL_EFFECTIVE,
                                     &registeredApp);

Comment 10

[Jim Mathies [:jimm]]

Why not leave it as is so we get the right settings? I seriously doubt a lot of users are going to follow the steps in comment #1. If they do, our added browser check makes sure the browser is set up in a way we expect.

Comment 11

[Brian R. Bondy [:bbondy]]

I think you mean Comment 0 right? Comment 1 I think will be very common.

There's probably a third case as well though where the user sets another browser as default, and then later uses control panel to switch back to Firefox.  On startup all we should be checking for is default HTTP status, so I think that only checking that is most correct on Windows 8.

Comment 12

[Jim Mathies [:jimm]]

Aren't we going to run into display problems with DefaultIcon pointing to the wrong app? Also I seem to remember that some apps launch firefox directly by reading http\shell\open\command data. Aren't we going to be skipping all the registration that normally takes place in helper.exe?

I guess if we know for a fact that the minimal registration Windows does for us is ok, I don't have any issues with shunting the default browser check / helper calls. I'd just like to be sure we aren't leaving important registration steps out.

Comment 13

[Brian R. Bondy [:bbondy]]

> Aren't we going to run into display problems with DefaultIcon pointing to 
> the wrong app? 

Yes but most people will just be using one browser. And it's a really bad user experience for the user to get a prompt after installing asking them to select their default browser, they select firefox, then when they open firefox for us to ask them again.  We give them a second opportunity to change what their default browser is.

> Also I seem to remember that some apps launch firefox directly by reading 
> http\shell\open\command data.

If they do they can be getting wrong info as of Windows 8, so we shouldn't optimize for that.

> Aren't we going to be skipping all the registration that normally takes place 
> in helper.exe?

Yes, if the user selects the default after installing from the Windows 8 popup.
yes, if the user selects the default directly from control panel.
But we can't control those cases.

> I'd just like to be sure we aren't leaving important registration steps out.

We can check with Rob, but given the above I think the best user experience is the one that could give the user the wrong icon.  Alternately, we could have different keys for each browser brand. I think that would solve all problems.

Comment 14

[Brian R. Bondy [:bbondy]]

I meant to say: We <strike>can</strike> should check with Rob...

Comment 15

[Jim Mathies [:jimm]]

For example I was looking at bug 796044. We have a routine 'MigrateTaskBarShortcut' which pins shortcuts. It calls a routine IsHandlerForInstallDir, which checks the path under http to see if we are the default browser.

Comment 16

[Brian R. Bondy [:bbondy]]

Ya that's crappy but I think the valid values are stored on the hash protected subkey now and not the main key.

Comment 17

[Robert Strong (they/them - no direct email)]

(In reply to Brian R. Bondy [:bbondy] from comment #13)
> > Aren't we going to run into display problems with DefaultIcon pointing to 
> > the wrong app? 
> 
> Yes but most people will just be using one browser. And it's a really bad
> user experience for the user to get a prompt after installing asking them to
> select their default browser, they select firefox, then when they open
> firefox for us to ask them again.  We give them a second opportunity to
> change what their default browser is.
> 
> > Also I seem to remember that some apps launch firefox directly by reading 
> > http\shell\open\command data.
> 
> If they do they can be getting wrong info as of Windows 8, so we shouldn't
> optimize for that.
Actually as of Window Vista and this was added as a workaround to improve the user experience when they had apps that weren't updated yet (there were quite a few applications with large install bases). I haven't had a chance to check if there are new methods in Win8 for getting handlers beyond application association registration which was implemented in Win Vista and if there are new methods I would prefer to at the very least maintain compatibility with Win Vista / Win 7 so users using apps that haven't been updated don't have a degraded experience.

> 
> > Aren't we going to be skipping all the registration that normally takes place 
> > in helper.exe?
> 
> Yes, if the user selects the default after installing from the Windows 8
> popup.
> yes, if the user selects the default directly from control panel.
> But we can't control those cases.
Agreed and this is the case under Win Vista as well.

> > I'd just like to be sure we aren't leaving important registration steps out.
> 
> We can check with Rob, but given the above I think the best user experience
> is the one that could give the user the wrong icon.  Alternately, we could
> have different keys for each browser brand. I think that would solve all
> problems.
I'm ok with the wrong icon but it would be a good thing to provide the ability to fix that. For example, if the user can perform a manual check to see if Firefox is default in Options which would say we are not when the default icon and other registry settings are not 100% correct and then provide the ability to fix them.

I think there were issues with using multiple Capabilities registry keys but I don't remember what they were atm. If we can do this we should at some point though I don't think it is all that important to do so at this time.

Comment 18

[Jim Mathies [:jimm]]

(In reply to Robert Strong [:rstrong] (do not email) from comment #17)
> I'm ok with the wrong icon but it would be a good thing to provide the
> ability to fix that. For example, if the user can perform a manual check to
> see if Firefox is default in Options which would say we are not when the
> default icon and other registry settings are not 100% correct and then
> provide the ability to fix them.

That might be a possible way to handle this. 

1) On the "lite weight" browser check we let Windows do whatever it wants to.
2) From the options we do a real check, and set all of our setting properly.

Hard to say what the side effects would be from this. We'll be the default but in the registry our normal set up won't be set up.

Comment 19

[Brian R. Bondy [:bbondy]]

Yes I was only suggesting doing the lightweight check on startup and using options to do everything as we already do.

(In reply to Brian R. Bondy [:bbondy] from comment #11)
> I think you mean Comment 0 right? Comment 1 I think will be very common.
> 
> On startup all we should be checking for is default HTTP status,
> so I think that only checking that is most correct on Windows 8.

Comment 20

[Brian R. Bondy [:bbondy]]

In particular when aForAllTypes == false. 
This second parameter was added recently and is only set to false on Windows 8.
isDefaultBrowser(bool aStartupCheck,$ bool aForAllTypes)

Comment 21

[Brian R. Bondy [:bbondy]]

control panel sets it to true on windows 8, every other OS sets it to true always.

Comment 22

[Robert Strong (they/them - no direct email)]

I don't think this should block or for that matter be tracked for Firefox 17 since it is a Win8 bug and we have bigger fish to fry.

Comment 23

[Brian R. Bondy [:bbondy]]

The main reason I thought it should be fixed in Firefox 17 is because the OS asks you for your default browser, you select Firefox, then we ask again at startup.  It gives the user an opportunity to change the browser after they already selected Firefox as their default.

Comment 24

[Robert Strong (they/them - no direct email)]

If we have the resources to get it fixed for Firefox 17 it would be great just as it would be great to fix a bunch of other bugs. So, I'm not against it getting fixed though I still don't think it should track 17.

Comment 25

[Brian R. Bondy [:bbondy]]

I just fixed a different issue around the same code tonight, so I'll pick this up tonight.

Comment 26

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1

Note: The check all defaults flag is effectively ignored on <win8. Which is fine and documented that the flag will be ignored on some OS.

The explicit HTTP/HTML checks w/ ProgID checks is needed on Win8 because the checkAllDefaults AAR check returns true when the default is set but the protected hash ProgID is different.

The check all defaults flag is set to false only on startup and only on windows 8 in the browser glue js code.

Comment 27

[Jim Mathies [:jimm]]

Tested on win8, this addresses the original problem in comment 1.

Comment 28

[Jim Mathies [:jimm]]

Comment on attachment 668299 [details] [diff] [review]
Patch v1

Thanks for picking this up!

Comment 29

[Brian R. Bondy [:bbondy]]

(In reply to Jim Mathies [:jimm] from comment #27)
> Tested on win8, this addresses the original problem in comment 1.

Excellent I had only tested on win7 so far and I was going to test on win8 today :) I'll test anyway though using my same test cases before landing it on m-c.  I'll just let elm pull it in naturally to elm to avoid any merge problems.

Comment 30

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/de6c6589ebe4

Comment 31

[Ed Morley [:emorley]]

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

Comment 32

[Brian R. Bondy [:bbondy]]

Comment on attachment 668299 [details] [diff] [review]
Patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): win8 handing its own defaults

User impact if declined: 
When the user first installs they are prompted with an OS initiated dialog for setting the default (only in Win8). If they select Firefox, and then they open the program, they will be prompted again for what default they want. This is bad for 2 reasons: 1) It looks bad that we didn't do what the user said in the first place. 2) We give them a second chance to change their browser away from us after they already selected us.  Comment 0 gives another way to reproduce this, but the one I described here is more important and the reason for the uplift request.

Testing completed (on m-c, etc.): 
I tried on Win8 with a Nightly build to make sure the problem no longer appears. I also tried setting defaults on Win7 to ensure that code path had no problems.

Risk to taking this patch (and alternatives if risky): Low

String or UUID changes made by this patch: None

Comment 33

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/releases/mozilla-beta/rev/aae4dd033b64
https://hg.mozilla.org/releases/mozilla-aurora/rev/b7cc170fe11e

Comment 34

[Manuela Muntean [Away]]

Verified on FF17b3, Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/17.0 Firefox/17.0, Build ID: 20121023124120

Comment 35

[Manuela Muntean [Away]]

Also fixed on Firefox 18 beta 1.

User Agent: Mozilla/5.0 (Windows NT 6.2; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20121121075611

Comment 36

[Manuela Muntean [Away]]

Verified on Firefox 19 beta 2.

User Agent: Mozilla/5.0 (Windows NT 6.2; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130116072953