Closed Bug 1191250 Opened 9 years ago Closed 9 years ago

Defer showing the default browser prompt to 2nd run (and only show it a maximum of three times)

Categories

(Firefox :: Shell Integration, defect, P2)

42 Branch
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
Firefox 43
Tracking Status
firefox42 --- affected
firefox43 --- verified

People

(Reporter: phlsa, Assigned: jaws)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

The default browser dialog currently clashes with a lot of other messaging we're doing on first run. It is the equivalent of "rate this app" modals that show up on first run on some mobile apps. We should do two things in order to make it more bearable: 1) Show it on second run, not first run. It is highly unlikely that a user who would want Firefox as their default doesn't at least launch it two times, so we will still hit virtually every relevant user. 2) Only show it a maximum of three times. If a user clicks "no" three times, we shouldn't ask again. This counter should be reset when Firefox becomes the default browser (so that it shows up again when another app takes over the default). I'd argue that we can do this even without the A/B test on the relevancy of the default setting, since we will still hit almost all relevant users as explained above.
Blocks: windows-10
Blocks: 1191384
Attached patch Patch (obsolete) (deleted) — Splinter Review
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8645921 - Flags: review?(jmathies)
Since this has come up in a couple of side discussions... This seems like a good improvement to investigate, but we need to have a plan for understanding its impact to new-user retention before actually shipping it to Release. The assumptions in comment 0 are reasonable, but we should be able to back that up with actual data. (Possibly including results of bug 1191060, if that shows that importance of the prompt is low.) Notably I'd like to avoid a repeat of bug 951627 -- where this wasn't done -- and then we had to jump through hoops to deal with an unexpected backout in beta when data showed there was a negative impact.
Why don't we move the prompt to in-tab ui? Then it's not that annoying. I've been hoping we would do this for years, maybe now is the time to actually do it?
Comment on attachment 8645921 [details] [diff] [review] Patch Review of attachment 8645921 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/components/shell/nsGNOMEShellService.cpp @@ +336,5 @@ > + return rv; > + } > + > + rv = prefs->GetBoolPref(PREF_SKIPDEFAULTBROWSERCHECK, > + aResult); nit - did this really need to wrap? ::: browser/components/shell/nsIShellService.idl @@ +50,5 @@ > + * Used to determine whether or not the "Set Default Browser" check > + * should be skipped during first-run or after the browser has been > + * run a few times. > + */ > + readonly attribute boolean shouldSkipCheckDefaultBrowser; you need to rev the interface uuid. ::: browser/components/shell/nsMacShellService.cpp @@ +103,5 @@ > return NS_OK; > } > > NS_IMETHODIMP > +nsMacShellService::GetShouldSkipCheckDefaultBrowser(bool* aResult) nit - not going to block on this but a cross platform util lib for these shell files might be handy, you could share a lot of this.
Attachment #8645921 - Flags: review?(jmathies) → review+
(In reply to Jim Mathies [:jimm] from comment #3) > Why don't we move the prompt to in-tab ui? Then it's not that annoying. I've > been hoping we would do this for years, maybe now is the time to actually do > it? Tab-modal isn't really right -- it's not specific to the web-page, and gets lost if you switch tabs. Bug 951627 made it a notification bar. But we're treading a fine line here between making it less bad, and making it sufficiently frictionless that people don't see/use it, and thus don't set Firefox as their default browser (which in turn may impact longer term adoption/usage). Hence my caution in what we do here.
(In reply to Justin Dolske [:Dolske] from comment #5) > (In reply to Jim Mathies [:jimm] from comment #3) > > Why don't we move the prompt to in-tab ui? Then it's not that annoying. I've > > been hoping we would do this for years, maybe now is the time to actually do > > it? > > Tab-modal isn't really right -- it's not specific to the web-page, and gets > lost if you switch tabs. I wasn't suggesting tab-modal prompt, I was suggest an about page. It's a really great way to passively annoy the user until they do something about it. I think both Chrome and IE do this. > Bug 951627 made it a notification bar. But we're treading a fine line here > between making it less bad, and making it sufficiently frictionless that > people don't see/use it, and thus don't set Firefox as their default browser > (which in turn may impact longer term adoption/usage). Hence my caution in > what we do here. Yeah I can see this, I tend to ignore notification bars and just close them or wait for them to go away once I navigate. :)
(In reply to Jim Mathies [:jimm] from comment #6) > I wasn't suggesting tab-modal prompt, I was suggest an about page. Ah, that's something we should look at (in a different bug ;). Especially given that on Win8+ a simple prompt+buttons is no longer sufficient to actually complete the action.
What is the next step for this bug? Comment #2 implies it may be RESO-WONTFIX, or at least abandoned until we have some more data.
Flags: needinfo?(philipp)
Flags: needinfo?(dolske)
Discussed this out-of-band with Dolske and Philipp, we're gonna land this but only for Nightly and Aurora builds until we're more confident about the change.
Flags: needinfo?(philipp)
Flags: needinfo?(dolske)
Depends on: 1199845
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
I seem to remember that we DO NOT want to request uplift for 41 on this one. Jaws can you confirm?
That is correct, see comment #9. We *could* uplift this to Aurora, but it will not ride past Aurora so the benefits of getting it to the Aurora population a couple weeks early are disputable.
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #0) > 2) Only show it a maximum of three times. If a user clicks "no" three times, > we shouldn't ask again. This counter should be reset when Firefox becomes > the default browser (so that it shows up again when another app takes over > the default). Performed a quick testing around this bug on Firefox 44.0a1 (2015-09-23) and I’ve noticed that the default browser dialog appears only 2 times. It is not displayed when the browser is opened a fourth time. How we should proceed in this situation? Should I reopen this bug or file a new one?
Flags: needinfo?(philipp)
QA Contact: vasilica.mihasca
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #16) > (In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from > comment #0) > > > 2) Only show it a maximum of three times. If a user clicks "no" three times, > > we shouldn't ask again. This counter should be reset when Firefox becomes > > the default browser (so that it shows up again when another app takes over > > the default). > > Performed a quick testing around this bug on Firefox 44.0a1 (2015-09-23) and > I’ve noticed that the default browser dialog appears only 2 times. It is not > displayed when the browser is opened a fourth time. > > How we should proceed in this situation? Should I reopen this bug or file a > new one? I'd suggest opening a new one with a dependency to this one. From what you describe, the behavior is right in spirit, but not in magnitude.
Flags: needinfo?(philipp)
Depends on: 1208000
Flags: qe-verify+
Depends on: 1223833
Tested this bug on Firefox 45.0a1 (2015-11-17), Firefox 44.0a2 (2015-11-17) and Firefox 43 beta 4 (20151116155110) under Windows 10 64-bit, Mac OS X 10.11.1 and noticed the following: - In Nightly and Aurora the default browser dialog it is shown starting with a second run, but it is displayed only 2 times - Bug 1225648 - this fix is not available in Firefox 43 Beta 4 because of Bug 1223833 Based on the above mentions, I am marking this bug as Verified since the other issues are tracked separately.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: