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

VERIFIED FIXED in Firefox 17

Status

()

Firefox
Shell Integration
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: juanb, Assigned: bbondy)

Tracking

({verifyme})

Trunk
Firefox 19
x86
Windows 8
verifyme
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16- wontfix, firefox17+ verified, firefox18+ verified, firefox19 verified)

Details

(Whiteboard: [win8])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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).
(Reporter)

Updated

6 years ago
Whiteboard: [win8]
(Assignee)

Comment 1

6 years ago
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.
(Assignee)

Comment 2

6 years ago
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.
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?

Comment 3

6 years ago
Sure I'll take a look.
Assignee: nobody → jmathies
"wontfix" for FF16 as we are so close to the release.Tracking for FF17,FF18
status-firefox16: --- → wontfix
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: ? → -
tracking-firefox17: ? → +
tracking-firefox18: ? → +
(Assignee)

Comment 5

6 years ago
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

6 years ago
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

6 years ago
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

6 years ago
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.
(Assignee)

Comment 9

6 years ago
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

6 years ago
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.
(Assignee)

Comment 11

6 years ago
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

6 years ago
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.
(Assignee)

Comment 13

6 years ago
> 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.
(Assignee)

Comment 14

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

Comment 15

6 years ago
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.
(Assignee)

Comment 16

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

Updated

6 years ago
Blocks: 796044
(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

6 years ago
(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.
(Assignee)

Comment 19

6 years ago
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.
(Assignee)

Comment 20

6 years ago
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)
(Assignee)

Comment 21

6 years ago
control panel sets it to true on windows 8, every other OS sets it to true always.
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.
Summary: default browser prompt shows even after setting defaults for Firefox from control panel → [Win8] default browser prompt shows even after setting defaults for Firefox from control panel
(Assignee)

Comment 23

6 years ago
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.
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.
(Assignee)

Comment 25

6 years ago
I just fixed a different issue around the same code tonight, so I'll pick this up tonight.
Assignee: jmathies → netzen
(Assignee)

Comment 26

6 years ago
Created attachment 668299 [details] [diff] [review]
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.
Attachment #668299 - Flags: review?(jmathies)

Comment 27

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

Comment 28

6 years ago
Comment on attachment 668299 [details] [diff] [review]
Patch v1

Thanks for picking this up!
Attachment #668299 - Flags: review?(jmathies) → review+
(Assignee)

Comment 29

6 years ago
(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.
(Assignee)

Updated

6 years ago
Summary: [Win8] default browser prompt shows even after setting defaults for Firefox from control panel → Default browser prompt shows even after setting defaults for Firefox from control panel
https://hg.mozilla.org/mozilla-central/rev/de6c6589ebe4
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 32

6 years ago
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
Attachment #668299 - Flags: approval-mozilla-beta?
Attachment #668299 - Flags: approval-mozilla-aurora?
Attachment #668299 - Flags: approval-mozilla-beta?
Attachment #668299 - Flags: approval-mozilla-beta+
Attachment #668299 - Flags: approval-mozilla-aurora?
Attachment #668299 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 33

6 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/aae4dd033b64
https://hg.mozilla.org/releases/mozilla-aurora/rev/b7cc170fe11e
status-firefox17: affected → fixed
status-firefox18: affected → fixed
status-firefox19: --- → fixed
Keywords: verifyme
Verified on FF17b3, Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/17.0 Firefox/17.0, Build ID: 20121023124120
status-firefox17: fixed → verified

Updated

6 years ago
QA Contact: manuela.muntean
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
status-firefox18: fixed → verified
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
Status: RESOLVED → VERIFIED
status-firefox19: fixed → verified
(Assignee)

Updated

5 years ago
Blocks: 831612
You need to log in before you can comment on or make changes to this bug.