1190586 - UITour should expose if default browser can be set w/o UI on Win8+

Status: RESOLVED FIXED

(Firefox :: Tours, defect, P3)

Description

[Justin Dolske [:Dolske]]

Bug 1184508 added the ability on Windows 8+ to restore Firefox as the default browser, if it had previously been set as such, without triggering Window's own complex UI for setting a default app.

We should probably expose this through the tour API, so that support pages know what's actually going to happen when the user triggers the default browser change. Otherwise they'll appear to tell the user to brace themselves for Windows' UI, and they may be confused when it happens without seeing that.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

Comment 2

[Justin Dolske [:Dolske]]

Comment on attachment 8645728 [details] [diff] [review]
Patch

Review of attachment 8645728 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/uitour/UITour.jsm
@@ +1820,5 @@
> +
> +        let canSetDefaultBrowserInBackground =
> +          AppConstants.platform != "win" ||
> +          !AppConstants.isPlatformAndVersionAtLeast("win", "6.2");
> +        if (AppConstants.isPlatformAndVersionAtLeast("win", "6.2")) {

This can be simplified to just:

let canSet... = true;
if (AppConstants.isPlatformAndVersionAtLeast("win", "6.2")) {
   ...
   canSet = prefChildren.length > 0;
}


That said...

OS X does have a system prompt (http://imgur.com/qoj7SWc). I think this is fairly new, 10.9 or 10.10? Should reflect that here.

Also, Linux is actually a little tricky because we may not have a suitable shell service that even allows setting it. Should probably just go ahead and return |false| here in such cases.

::: browser/components/uitour/test/browser_UITour_defaultBrowser.js
@@ +80,5 @@
> +  taskify(function* test_setInBackgroundWhenPrefExists(done) {
> +    gContentAPI.getConfiguration("appinfo", (data) => {
> +      let canSetInBackground = false;
> +      is(canSetInBackground, data.canSetDefaultBrowserInBackground,
> +        "canSetDefaultBrowserInBackground should be false when no hashes are present");

Err, won't this end up failing on not-Windows?

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.1

I looked online and found that OSX introduced that prompt in 10.10, https://www.aeyoun.com/posts/osx-protect-default-browser.html

I changed the code so that canSetDefaultBrowserInBackground is null on Linux when the shell service is unavailable. 

Try push, https://treeherder.mozilla.org/#/jobs?repo=try&revision=fbb251a421bd

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.2

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.3

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b2b988e646ea

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/db8c8c03c7bf

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 8

[Masatoshi Kimura [:emk]]

>          canSetDefaultBrowserInBackground = prefChildren.length > 0;

It should be |prefChildren.length >= 4|. setDefaultBrowser(true, false) will trigger the Windows UI if it can't set any one of http, https, .html, and .htm.

Comment 9

[Bogdan Maris, Desktop Test Engineering]

I see that the same UITour (the one with 3 easy steps) prompted on both Firefox 42.0 RC and 43 beta 2 when none of them are set as default, and they have been earlier but switched with chrome. If both 42 and 43 are set as default browsers I will get another UITour (the one with Privacy, Speed and Choice). So judging by the tracking flags, 42 should be bad and 43 should be good but I can't spot any difference between the behaviour from both versions. 

Is there something I'm missing? Or am I checking the wrong thing here? requesting needinfo from Masatosi Kimura since he verified bug 1184508 as well.

Comment 10

[Alex Gibson [:agibson]]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #9)
> I see that the same UITour (the one with 3 easy steps) prompted on both
> Firefox 42.0 RC and 43 beta 2 when none of them are set as default, and they
> have been earlier but switched with chrome. If both 42 and 43 are set as
> default browsers I will get another UITour (the one with Privacy, Speed and
> Choice). So judging by the tracking flags, 42 should be bad and 43 should be
> good but I can't spot any difference between the behaviour from both
> versions. 
> 
> Is there something I'm missing? Or am I checking the wrong thing here?
> requesting needinfo from Masatosi Kimura since he verified bug 1184508 as
> well.

This bug has yet to be implemented on those pages in production.

Comment 11

[Masatoshi Kimura [:emk]]

Comment 10 seems to answer the question.