When I run Nightly for the first time on Windows 10, Nightly asks if I would like to make it the default browser. When I click the "Use Nightly as my default browser" button, Windows opens a "Choose default apps" settings window, but I must manually scroll to the bottom of the window (which has no visible scrollbars!) to see the actual "Web browser" setting. And Spartan is still listed as the default browser. In Windows 8.1, Firefox's "Use Nightly as my default browser" button would open a simple, multiple choice window. This Windows 10 UI seems to be intentionally misleading to make users less successful at switching their default browser from Spartan to Firefox. Is there anything we can do to make this UI easier for Firefox users? Can we watch for the "Choose default apps" window and maximize it so the "Web browser" setting is visible? Please see the attached screenshot. Note that the "Web browser" setting is not visible nor any scrollbars suggesting that you must scroll down.

Maximizing may be possible. Chromium is having the same problem as us right now. Alternatively, we could choose to show a walk-through (bug 1170743) along with that window opening when they click "Use Nightly as my default browser". It doesn't look like there has been any action in bug 1170743 yet. The third option would be to try to use some automation/accessibility APIs to scroll the Web browser item into view, although I'm not sure how we can do that.

This patch uses "openas" verb to show a popup that is much like a popup on Windows 8. ShellExecuteEx requires an actual URL to invoke the verb, so I chose a SUMO article that instructs how to make Firefox the default browser :) I also added a check to the command line handler so that it stops loading the special URI if Firefox is already the default browser. If the user didn't select Firefox on the popup, the selected browser will show the instruction page and the user can learn about how to change the default browser. If the user selected Firefox but forgot to check "Alway use this app to open...", Firefox will show the instruction page. If the user made Firefox the default browser, the instruction page will not be shown.

Here are test binaries: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.jp-1a8ac11b6e78/try-win32/ https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.jp-1a8ac11b6e78/try-win64/

Comment on attachment 8621069 [details] [diff] [review] Proof-of-concept patch This looks and works good to me. I would move the URL to a pref but other than that this is a simpler and more intuitive UI.

Comment on attachment 8621069 [details] [diff] [review] Proof-of-concept patch Jim, what do you think about this?

(In reply to Masatoshi Kimura [:emk] from comment #3) > If the user didn't select Firefox on the popup, the selected browser will > show the instruction page and the user can learn about how to change the > default browser. > If the user selected Firefox but forgot to check "Alway use this app to > open...", Firefox will show the instruction page. > If the user made Firefox the default browser, the instruction page will not > be shown. Clever! :) I tested your Try build and it looks good to me. Having to manually check the "Always use this app to open" checkbox in addition to selecting the Firefox list item increases the possibility of user failure, but this UX is much better than Windows 10's "Choose default apps" UX!

I created a pref for the instruction URL. Try result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d90513d6b6d

Comment on attachment 8622026 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 Review of attachment 8622026 [details] [diff] [review]: ----------------------------------------------------------------- Jared would be a better reviewer. ::: browser/app/profile/firefox.js @@ +270,5 @@ > // At startup, check if we're the default browser and prompt user if not. > pref("browser.shell.checkDefaultBrowser", true); > pref("browser.shell.shortcutFavicons",true); > pref("browser.shell.mostRecentDateSetAsDefault", ""); > +pref("browser.shell.setAsDefaultInstructionURL", "https://support.mozilla.org/kb/make-firefox-your-default-browser?setAsDefault"); No, there doesn't need to be a pref for this. Instead, look at how we construct the DRM url here: http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/in-content/content.js#43 43 let drmInfoURL = 44 Services.urlFormatter.formatURLPref("app.support.baseURL") + "drm-content"; you'll want to do something similar here. This will ensure we pass the right language etc. and avoid extra server-side redirects, making the page load faster. ::: browser/components/shell/nsWindowsShellService.cpp @@ +698,5 @@ > + } > + > + nsString urlStr; > + nsresult rv = formatter->FormatURLPref( > + NS_LITERAL_STRING("browser.shell.setAsDefaultInstructionURL"), urlStr); In fact, it seems you're calling this here already, but you're passing a URL with no formatting codes, which means this is currently a no-op...

Comment on attachment 8622026 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 looks ok to me independent of the url issues raised previously.

Comment on attachment 8622026 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 I'll wait for a new patch that addresses Gijs' comments.

Comment on attachment 8622026 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 * I tried formatURLPref("app.support.baseURL") + "make-firefox-your-default-browser?setAsDefault", but the result was 404 error with [1]. * Looks like [2] redirected to [3] anyway. It is dubious that this avoids extra server-side redirects. * I intentionally avoided the final URL to prevent users from copy&pasting the URL because Firefox cannot open the URL from external apps as long as Firefox is the default browser. Requested review again due to the above reasons. Please provide a workable URL if you ask for a new patch again. [1] https://support.mozilla.org/1/firefox/41.0a1/WINNT/en-US/make-firefox-your-default-browser?setAsDefault [2] https://support.mozilla.org/1/firefox/41.0a1/WINNT/en-US/ [3] https://support.mozilla.org/en-US/products/firefox?as=u&utm_source=inproduct

According to bug 1111146 comment #9 and onwards, 404 is OK at the moment. I used formatURLPref("app.support.baseURL") + "win10-default-browser".

Comment on attachment 8624246 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 Review of attachment 8624246 [details] [diff] [review]: ----------------------------------------------------------------- This looks fine from my end but we should get review from Jim for the C++ changes. We may want to do some A/B testing between this patch and the one that I landed in bug 1167294.

Comment on attachment 8624246 [details] [diff] [review] Use the "openas" verb to select the default HTTP handler on Windows 10 c++ looks ok to me.

Filed bug 1176112 for A/B testing.

(In reply to Masatoshi Kimura [:emk] from comment #3) > Created attachment 8621069 [details] [diff] [review] > Proof-of-concept patch > > This patch uses "openas" verb to show a popup that is much like a popup on > Windows 8. > ShellExecuteEx requires an actual URL to invoke the verb, so I chose a SUMO > article that instructs how to make Firefox the default browser :) I also > added a check to the command line handler so that it stops loading the > special URI if Firefox is already the default browser. > > If the user didn't select Firefox on the popup, the selected browser will > show the instruction page and the user can learn about how to change the > default browser. > If the user selected Firefox but forgot to check "Alway use this app to > open...", Firefox will show the instruction page. > If the user made Firefox the default browser, the instruction page will not > be shown. Haven't tried the patch, but that sounds like a great idea! Is there a bug on file about creating/updating the support page that would be involved here?

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #18) > Haven't tried the patch, but that sounds like a great idea! > Is there a bug on file about creating/updating the support page that would > be involved here? Filed bug 1176116 for that.

Verified fixed on Nightly 41.0a1 (2015-06-23), using Windows 10 Pro Insider Preview (Build 10130, 64-bit architecture). All the specifications from Comment 3 are now successfully met.

This never got uplifted, resulting in bug 1193196 being discovered after Firefox 40 was released today. As a result we're uplifting it to mozilla-release and spinning a 40.0.1 with it and a couple other fixes. https://hg.mozilla.org/releases/mozilla-release/rev/dad22a127344 (already discussed and approved with lmandel)