951627 - Implementation: Use something other than a modal dialog to ask for setting the default browser

Status: VERIFIED FIXED

(Firefox :: Shell Integration, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

One of the first things Firefox does to people after a fresh install is to interrupt their flow with a modal dialog. We need a concept for something equally persuasive but less intrusive.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Philipp is this a bug for a design team or for people on the Toolkit team? For now I'll put this in Toolkit::Startup and Profile. Thanks!

Comment 2

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

Default browser is handled by Firefox -> Shell Integration so fixing component

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

At it's current stage, the ball is at the UX team. We need to decide on a good way to ask people to set FF as their default browser that is persuasive, yet not annoying.

Comment 4

[Manish Goregaokar [:manishearth]]

This could possibly be done via doorhangers; once on every browser start. Not idea, though.

Comment 5

[Manish Goregaokar [:manishearth]]

I meant "ideal" up there.

The doorhanger UI is designed to be for per-page dialogs. Not sure if it would be the best way to do this, but it's an option, one that can be done without additional UI work.

Comment 6

[Marco Mucci [:MarcoM]]

Carry over to Iteration it-30c-29a-28b.3

Comment 7

[Michael Maslaney [:mmaslaney] ([e-mail])]

Spec and assets Posted in bug 977045

Comment 8

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

There was some confusion about how to handle this bug in our process. It started as an implementation bug, then bug 977045 got spun off to do the UX work and now this is closed but no implementation has happened yet.

Marco, should we reopen this bug to use it for the implementation or open a new one for this?

Comment 9

[Marco Mucci [:MarcoM]]

Hi Philipp.  Yes, you are correct. My mistake for having forgotten. I'll make the necessary changes to reflect that.

Comment 11

[Manish Goregaokar [:manishearth]]

So I guess this should be done in a <notificationbox>?

Comment 12

[:Gijs (he/him)]

The icon in the mock is 34x34px. AFAICT there is no such icon in the tree. There's a 32x32px version at http://mxr.mozilla.org/mozilla-central/source/browser/branding/official/content/VisualElements_smalllogo.png but no hidpi version there either, AFAICT.

Philipp, can you clarify and provide the necessary assets?

Comment 13

[:Gijs (he/him)]

Note also that this would need to happen for all the different branding we have (ie nightly/unofficial, aurora, official).

Comment 14

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: firefox-34-temp.zip

I created a 34px version for now, but it would be better if we could reuse the existing 32px icon. I tried to apply that in the mockup, but it looked a little out of place.
Michael, can you think of a way of making this work with the icon that Gijs linked in comment #12?

Gijs, if you'd like you could start implementing this with the icons I just uploaded. If we decide to change it to the smaller version, there shouldn't be that much to change.

Comment 15

[Michael Maslaney [:mmaslaney] ([e-mail])]

Let's move forward with the 32x32 icon, as it's only 2 pixels off from the original. Gijs do you need the Aurora and Nightly assets, as well?

Comment 16

[:Gijs (he/him)]

(In reply to mmaslaney from comment #15)
> Let's move forward with the 32x32 icon, as it's only 2 pixels off from the
> original. Gijs do you need the Aurora and Nightly assets, as well?

Hm, well, interestingly it seems the icons that I noticed earlier aren't even shipped in-product, but in use in the installer. We have larger icons (for the about Firefox window) and smaller icons (e.g. the modified icon for the "Firefox" type URLs like customize mode) but I've not found something inbetween. In any case, I would assume that I should be able to extract 32x32 and 64x64 (ie hidpi) versions from the app icons that we have in-tree elsewhere...

Comment 17

[:Gijs (he/him)]

Marco, can you assign this to me for the new iteration?

Comment 18

[Marco Mucci [:MarcoM]]

Added to Iteration 33.1

Comment 19

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #16)
> (In reply to mmaslaney from comment #15)
> > Let's move forward with the 32x32 icon, as it's only 2 pixels off from the
> > original. Gijs do you need the Aurora and Nightly assets, as well?
> 
> Hm, well, interestingly it seems the icons that I noticed earlier aren't
> even shipped in-product, but in use in the installer. We have larger icons
> (for the about Firefox window) and smaller icons (e.g. the modified icon for
> the "Firefox" type URLs like customize mode) but I've not found something
> inbetween. In any case, I would assume that I should be able to extract
> 32x32 and 64x64 (ie hidpi) versions from the app icons that we have in-tree
> elsewhere...

Ah, but there is chrome://branding/content/icon(32|48|64).png, so that should be fine.

Comment 20

[:Gijs (he/him)]

So I'm looking at the mock/specs... the prompt has "Not Now" with a dropdown. What's in the dropdown? How is that styled? There doesn't seem to be any info about this in the mock/spec.

And just so we're 100% clear:

"Use Firefox as my default browser" -> toggles the default, leaves the 'should I ask' pref as-is
"Not now" -> doesn't toggle the default, leaves the 'should I ask' pref as-is
... ?

I'm guessing there's a "Never ask me this" (or something along those lines) which doesn't toggle the default and turns off the pref that controls whether we ask... but please be explicit about how it should behave.

Comment 21

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #20)
> So I'm looking at the mock/specs... the prompt has "Not Now" with a
> dropdown. What's in the dropdown? How is that styled? There doesn't seem to
> be any info about this in the mock/spec.

The dropdown has only one entry which is »No and don't ask again«
Michael should know more about the styling.

> And just so we're 100% clear:
> 
> "Use Firefox as my default browser" -> toggles the default, leaves the
> 'should I ask' pref as-is
> "Not now" -> doesn't toggle the default, leaves the 'should I ask' pref as-is
> ... ?

»Not now« should dismiss the bar and make it pop up again the next time the browser starts (you probably meant that, but just to be clear :)

> I'm guessing there's a "Never ask me this" (or something along those lines)
> which doesn't toggle the default and turns off the pref that controls
> whether we ask... but please be explicit about how it should behave.

»No and don't ask again« (in the dropdown) doesn't set the default browser and prevents the bar from appearing again. After using that item, going to prefs manually is the only way to set Fx as the default browser.

Comment 22

[Dão Gottwald [:dao]]

Looking at the mockup, I'm curious why we are not using the standard notification bar style here. (This includes the possibility to update that style if wanted.) Alternatively, as an interim solution, I would at least have expected this to reuse the recent custom style added for the translation info bar. Can we please not create maintenance hell by inventing different styles for each new notification bar? This is starting to get out of hand.

On a separate note, the top of the content area is usually reserved for site-specific notification bars, much like popup notifications. There's a container at the bottom of the content area for global notifications.

Comment 23

[Michael Maslaney [:mmaslaney] ([e-mail])]

To clarify, this SHOULD be using the custom style added for translation. Both were designed to look and feel the same.

Comment 24

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #22)
> Looking at the mockup, I'm curious why we are not using the standard
> notification bar style here. (This includes the possibility to update that
> style if wanted.) Alternatively, as an interim solution, I would at least
> have expected this to reuse the recent custom style added for the
> translation info bar. Can we please not create maintenance hell by inventing
> different styles for each new notification bar? This is starting to get out
> of hand.

Can you clarify where you see this diverging from the translation style? I haven't, but perhaps I've not looked in enough detail. Sadly I can't reuse any of the translation work directly. I'll have to see how much is sharable by moving it elsewhere.

Comment 25

[:Gijs (he/him)]

(In reply to mmaslaney from comment #23)
> To clarify, this SHOULD be using the custom style added for translation.
> Both were designed to look and feel the same.

Can you still clarify how the dropdown is meant to be styled?

Comment 26

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #24)
> Can you clarify where you see this diverging from the translation style? I
> haven't, but perhaps I've not looked in enough detail.

Compared to attachment 8420452 [details], the most obvious divergences are:

- the icon is separated in a box with a lighter background
- the button with the default action is green instead of blue
- there's a "not now" button with a dropdown instead of a "not now" button and an "options" menu button
- there's no close button

Comment 27

[Michael Maslaney [:mmaslaney] ([e-mail])]

• We can use a blue action button in this case.

• There should be a close button

Comment 28

[Michael Maslaney [:mmaslaney] ([e-mail])]

(In reply to :Gijs Kruitbosch from comment #25)
> (In reply to mmaslaney from comment #23)
> > To clarify, this SHOULD be using the custom style added for translation.
> > Both were designed to look and feel the same.
> 
> Can you still clarify how the dropdown is meant to be styled?

Let's use native until we officially nail down a look and feel for the style guide.

Comment 29

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #26)
> (In reply to :Gijs Kruitbosch from comment #24)
> > Can you clarify where you see this diverging from the translation style? I
> > haven't, but perhaps I've not looked in enough detail.
> 
> Compared to attachment 8420452 [details], the most obvious divergences are:
> 
> - there's a "not now" button with a dropdown instead of a "not now" button
> and an "options" menu button

This is making my life difficult when implementing this because of the restrictions in notifications.xml's builtin notifications (it can't do button-that-also-has-a-dropdown, and while I could build that, this is the only notification bar interested, AFAICT). Seeing as we have a close button already, and for consistency with the translations, maybe we can just do [options] (or maybe even [No...]) which drops down to "Not now" and "Never" ?

Comment 30

[:Gijs (he/him)]

(that would also solve the IMO awkward UI of having a dropdown menu with only 1 item in it...)

Comment 31

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #29)
> (In reply to Dão Gottwald [:dao] from comment #26)
> > (In reply to :Gijs Kruitbosch from comment #24)
> > > Can you clarify where you see this diverging from the translation style? I
> > > haven't, but perhaps I've not looked in enough detail.
> > 
> > Compared to attachment 8420452 [details], the most obvious divergences are:
> > 
> > - there's a "not now" button with a dropdown instead of a "not now" button
> > and an "options" menu button
> 
> This is making my life difficult when implementing this because of the
> restrictions in notifications.xml's builtin notifications (it can't do
> button-that-also-has-a-dropdown, and while I could build that, this is the
> only notification bar interested, AFAICT). Seeing as we have a close button
> already, and for consistency with the translations, maybe we can just do
> [options] (or maybe even [No...]) which drops down to "Not now" and "Never" ?

If that makes things easier, I'm fine with hiding all »no«-actions behind an options button since those are both discouraged actions.

Comment 32

[:Gijs (he/him)]

The translation infobar is also a lot slimmer - 31 pixels on my OS X build - than this one. I'm going to assume it also needs to be 40px.

Comment 33

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #32)
> The translation infobar is also a lot slimmer - 31 pixels on my OS X build -
> than this one. I'm going to assume it also needs to be 40px.

bug 1022405.

Comment 34

[:Gijs (he/him)]

Attachment: use notification for default browser prompt,

This has updated styles for OS X. I still need to update Linux and Windows. Jared, can you look over the code and my approach here? My basic idea has been that I want the styles in shared/infobar and osx/infobar to be directly portable to toolkit as much as possible, hence redoing a bunch of things based on the pre-existing classes in <notification>s and updating the translation binding to use them as much as possible. Michael, can you check that this matches the combination of the spec and the discussions we've had in the bug? I ended up simplifying a bunch of the translation styling to be in line with the spec you gave for this one. Try push that should have builds in a hopefully short while: https://tbpl.mozilla.org/?tree=Try&rev=4041193f9768

Comment 35

[Dão Gottwald [:dao]]

Comment on attachment 8440010 [details] [diff] [review]
use notification for default browser prompt,

>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js

>+  prompt: function() {
>+    let brandBundle = document.getElementById("bundle_brand");
>+    let shellBundle = document.getElementById("bundle_shell");
>+
>+    let brandShortName = brandBundle.getString("brandShortName");
>+    let promptMessage = shellBundle.getFormattedString("setDefaultBrowserMessage2",
>+                                                       [brandShortName]);
>+
>+    let confirmMessage = shellBundle.getFormattedString("setDefaultBrowserConfirm.label",
>+                                                        [brandShortName]);
>+    let confirmKey = shellBundle.getString("setDefaultBrowserConfirm.accesskey");
>+
>+    let optionsMessage = shellBundle.getString("setDefaultBrowserOptions.label");
>+    let optionsKey = shellBundle.getString("setDefaultBrowserOptions.accesskey");
>+
>+    let selectedBrowser = gBrowser.selectedBrowser;
>+    let notificationBox = gBrowser.getNotificationBox(selectedBrowser);

Like I said earlier, this notification isn't browser-specific. You should use global-notificationbox.

Also, any reason why this code shouldn't continue to live in nsBrowserGlue? It only needs to run once, after startup, not at arbitrary times in various browser windows.

Comment 36

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #35)
> Like I said earlier, this notification isn't browser-specific. You should
> use global-notificationbox.

I understood from UX that they cared more about this being at the top of the window than about it being displayed across all tabs. It's possible I misunderstood, let's check with Philipp.

> Also, any reason why this code shouldn't continue to live in nsBrowserGlue?
> It only needs to run once, after startup, not at arbitrary times in various
> browser windows.

Yes. Notification.xml makes you reference an existing popup for the dropdown. The alternative to this method would be making nsBrowserGlue available in the browser window, exposing methods for the "never" ans "not now" actions in the idl (or using wrappedJSObject), and calling those. That seemed worse to me, especially because the code already depends on browser-window-internal things. Made more sense to move it to the browser window.

Comment 37

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #36)
> (In reply to Dão Gottwald [:dao] from comment #35)
> > Like I said earlier, this notification isn't browser-specific. You should
> > use global-notificationbox.
> 
> I understood from UX that they cared more about this being at the top of the
> window than about it being displayed across all tabs. It's possible I
> misunderstood, let's check with Philipp.

We should have a separate discussion about the right place for global-notificationbox then rather than creating another half-broken isolated solution here.

> > Also, any reason why this code shouldn't continue to live in nsBrowserGlue?
> > It only needs to run once, after startup, not at arbitrary times in various
> > browser windows.
> 
> Yes. Notification.xml makes you reference an existing popup for the
> dropdown. The alternative to this method would be making nsBrowserGlue
> available in the browser window, exposing methods for the "never" ans "not
> now" actions in the idl (or using wrappedJSObject), and calling those. That
> seemed worse to me, especially because the code already depends on
> browser-window-internal things.

I don't see why that would be necessary. defaultBrowserNotificationPopup can exist in browser.xul and nsBrowserGlue can call notificationBox.appendNotification with that id. What matters is that notificationBox and the popup are in the same document.

Comment 38

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #37)
> (In reply to :Gijs Kruitbosch from comment #36)
> > (In reply to Dão Gottwald [:dao] from comment #35)
> > > Also, any reason why this code shouldn't continue to live in nsBrowserGlue?
> > > It only needs to run once, after startup, not at arbitrary times in various
> > > browser windows.
> > 
> > Yes. Notification.xml makes you reference an existing popup for the
> > dropdown. The alternative to this method would be making nsBrowserGlue
> > available in the browser window, exposing methods for the "never" ans "not
> > now" actions in the idl (or using wrappedJSObject), and calling those. That
> > seemed worse to me, especially because the code already depends on
> > browser-window-internal things.
> 
> I don't see why that would be necessary. defaultBrowserNotificationPopup can
> exist in browser.xul and nsBrowserGlue can call
> notificationBox.appendNotification with that id. What matters is that
> notificationBox and the popup are in the same document.

I must have been unclear - it's not the appending of the notification that I'm worried about. It's the actions resulting from the popup (hide the notification, and/or tell the shell service not to ever ask again). We could do the implementation of only those actions in browser.js / browser.xul, and keep the 'make Firefox the default' action of the notification in nsBrowserGlue, but that didn't make sense to me as it splits the location of the handling of the user interacting with the infobar, some of it being in browser.js and some of it in nsBrowserGlue.

Moving everything to nsBrowserGlue means having the IDL expose that, or using wrappedJSObject, as I noted. I thought putting everything in browser.js was cleaner.

I guess we could also put all the actions in browser.js, but keep the appendNotification call in nsBrowserGlue - but it seemed to make more sense to keep all of it together.

Comment 39

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #38)
> I must have been unclear - it's not the appending of the notification that
> I'm worried about. It's the actions resulting from the popup (hide the
> notification, and/or tell the shell service not to ever ask again). We could
> do the implementation of only those actions in browser.js / browser.xul, and
> keep the 'make Firefox the default' action of the notification in
> nsBrowserGlue, but that didn't make sense to me as it splits the location of
> the handling of the user interacting with the infobar, some of it being in
> browser.js and some of it in nsBrowserGlue.
> 
> Moving everything to nsBrowserGlue means having the IDL expose that, or
> using wrappedJSObject, as I noted. I thought putting everything in
> browser.js was cleaner.
> 
> I guess we could also put all the actions in browser.js, but keep the
> appendNotification call in nsBrowserGlue - but it seemed to make more sense
> to keep all of it together.

nsBrowserGlue could just add a command event listener to the popup (or one to each menuitem) instead of oncommand being hardcoded in XUL. Speaking of which, nsBrowserGlue could also create the popup on demand...

Comment 40

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #37)
> (In reply to :Gijs Kruitbosch from comment #36)
> > (In reply to Dão Gottwald [:dao] from comment #35)
> > > Like I said earlier, this notification isn't browser-specific. You should
> > > use global-notificationbox.
> > 
> > I understood from UX that they cared more about this being at the top of the
> > window than about it being displayed across all tabs. It's possible I
> > misunderstood, let's check with Philipp.
> 
> We should have a separate discussion about the right place for
> global-notificationbox then rather than creating another half-broken
> isolated solution here.

I don't really see why the current state is "half-broken" or an "isolated" solution. If we need to change the location of the global notificationbox and then use that, we can do a followup for that - this bug/patch is already big enough as it is.

Comment 41

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #40)
> (In reply to Dão Gottwald [:dao] from comment #37)
> > (In reply to :Gijs Kruitbosch from comment #36)
> > > (In reply to Dão Gottwald [:dao] from comment #35)
> > > > Like I said earlier, this notification isn't browser-specific. You should
> > > > use global-notificationbox.
> > > 
> > > I understood from UX that they cared more about this being at the top of the
> > > window than about it being displayed across all tabs. It's possible I
> > > misunderstood, let's check with Philipp.
> > 
> > We should have a separate discussion about the right place for
> > global-notificationbox then rather than creating another half-broken
> > isolated solution here.
> 
> I don't really see why the current state is "half-broken" or an "isolated"
> solution.

It's isolated and inconsistent because we don't handle other non-browser-specific notifications this way. It's half-broken because it ties the notification to a specific browser, which doesn't make sense code-wise nor from the user's perspective. If some code switches tabs after you added the notification (like, in the context of your patch, the code opening about:newaddon, which seems to race with your code), the user may not even see it. Even if that doesn't happen, chances are the user will do something that would unexpectedly make the notification go away, so you're sacrificing the notification's persistence for an only initially higher visibility.

Comment 42

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yes, this bar only makes sense if it is at the top of the window, because users likely won't notice it at the bottom.

If the trade-off is that we can only display it in one tab for now, then that's still worth it (given that it is displayed in the tab the user actually sees). We should still follow up swiftly on making the bar global though.

Comment 43

[:Gijs (he/him)]

Attachment: use notification for default browser prompt,

Now with Windows styles.

Comment 44

[Dão Gottwald [:dao]]

Comment on attachment 8440760 [details] [diff] [review]
use notification for default browser prompt,

(In reply to Philipp Sackl [:phlsa] from comment #42)
> Yes, this bar only makes sense if it is at the top of the window, because
> users likely won't notice it at the bottom.

Other global notification bars are already at the bottom. They may not be super important, but surely we don't expect the to likely go unnoticed. So either what you say isn't true or it's something we need to fix asap regardless of this bug, and in the meantime this patch can already use the global notification box assuming it will be fixed.

> If the trade-off is that we can only display it in one tab for now, then
> that's still worth it (given that it is displayed in the tab the user
> actually sees). We should still follow up swiftly on making the bar global
> though.

See my previous comment. There are various places in our code base alone (let alone add-ons) that add & select tabs around the time the initial window is opened. The tab that's selected when the notification bar is be added isn't necessarily the tab the user will actually see. This seems exceedingly fragile. I'll stick my formal r- in here for that.

Comment 45

[:Gijs (he/him)]

Attachment: use notification for default browser prompt,

With Linux styling.

Comment 46

[:Gijs (he/him)]

I'm abandoning this bug. Here's why:

1. Being told by different stakeholders to do both X and !X is both draining as well as meaning that there's no clear path forward. I'll let Philipp and Dão argue that out, but I'm not up for continuously writing patches to suit then the one, then the other idea.

2. The design work here was adjusted per earlier comments, but no new specs/mockups have appeared, which means I'm implementing something unspecced (see also bug 1025182). I'm not sure, for instance, about the spacing of the dropdown icon on the options button, and the spacing in general (which is very different on the translation info bar). There needs to be consensus about whether the styling achieved by these patches is OK or whether there need to be more adjustments. (needinfo: mmaslaney; try push: https://tbpl.mozilla.org/?tree=Try&rev=3c8e17ce16a0)

3. Having to deal with issues in the translation styling per se and then making those generic is probably a bug in and of itself (bug 1025182), and this bug will be a lot easier to implement once styling doesn't take up 80% of the time. Perhaps some of the work in this patch can be reused there.

4. Someone recently raised the question to me of how this impacts ADUs and whether getting rid of the modal dialog is actually right from a user retention perspective. That is, most people will want to have the browser be the default, and making the prompt less conspicuous will most likely be bad for those people. I'm not aware of this having been discussed or thought through, nor of there being any telemetry/metrics that we can use to measure the effect of this change and to ensure we deal with this appropriately (needinfo: mconnor). We should answer some of those questions and/or have the discussions (not in the bug, probably) before moving forward here.

Comment 47

[:Gijs (he/him)]

Attachment: use notification for default browser prompt,

Unbitrotted for the try push.

Comment 48

[Marco Mucci [:MarcoM]]

Removed from Iteration 33.1

Comment 49

[Justin Dolske [:Dolske]]

(In reply to Dão Gottwald [:dao] from comment #37)
[...]
> We should have a separate discussion about the right place for
> global-notificationbox then rather than creating another half-broken
> isolated solution here.

Concur. I chatted with Philipp about this briefly on IRC a while ago... It's been a long standing problem that we don't have a very good solution for global notifications from the browser. The global notification box is what we have, but it's also just what Sync originally hacked together as good-enough.

That said, a good solution may not exist or have a good cost/benefit for implementing. An isolated solution may be fine, if we've duly considered the options and their cost. [i.e., using a global notification as-is is cheap but not ideal, solving global notifications generally is ideal but expensive, and there's a spectrum in between.]

Three other thoughts while I'm here:

1) I think we should be careful thinking about the impact this has on user conversion. The dialog-on-first-run can suck, but I'd be really wary of ending up with something so non-intrusive that we end up losing a significant fraction of new installs. At the very least we'll need to watch metrics for new-user ADI rates for dips, and it's plausible this could snowball into needing full-fledged UR and additional FHR/Telemetry to understand impact.

2) There are actually two problems to solve here -- first-run experience, and "something changed my default browser" experience. I think we all want to improve the first-run case, but arguably the second case should remain very in-your-face. There's significant user benefit (users tend to hate sneaky default-browser changes), and since this should rarely happen it's OK to have intrusive UI for an exceptional condition.

3) I noticed last week that Chrome has an rather elegant solution to the first-run experience. They put the "make Chrome my default" checkbox on the _download page_ -- enabled by default, of course -- and then (presumably) give you a different installer that automatically does that or not. That's a clever way to retain user choice, but completely eliminate the first-run prompt.

Comment 50

[Dão Gottwald [:dao]]

(In reply to Justin Dolske [:Dolske] from comment #49)
> 2) There are actually two problems to solve here -- first-run experience,
> and "something changed my default browser" experience. I think we all want
> to improve the first-run case, but arguably the second case should remain
> very in-your-face.

I would expect the second case to be the dominant one on Windows where our installer's default behavior is to make Firefox the default browser.

Comment 51

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Justin Dolske [:Dolske] from comment #49)
> Three other thoughts while I'm here:
> 
> 1) I think we should be careful thinking about the impact this has on user
> conversion. The dialog-on-first-run can suck, but I'd be really wary of
> ending up with something so non-intrusive that we end up losing a
> significant fraction of new installs. At the very least we'll need to watch
> metrics for new-user ADI rates for dips, and it's plausible this could
> snowball into needing full-fledged UR and additional FHR/Telemetry to
> understand impact.
> 
> 2) There are actually two problems to solve here -- first-run experience,
> and "something changed my default browser" experience. I think we all want
> to improve the first-run case, but arguably the second case should remain
> very in-your-face. There's significant user benefit (users tend to hate
> sneaky default-browser changes), and since this should rarely happen it's OK
> to have intrusive UI for an exceptional condition.

Good thoughts! Yes, this is a sensitive place and we should watch the numbers closely (regardless of what solution we're going with). Since this but is on hold now anyway, I'll iterate on the design some more considering the points you've raised.

> 3) I noticed last week that Chrome has an rather elegant solution to the
> first-run experience. They put the "make Chrome my default" checkbox on the
> _download page_ -- enabled by default, of course -- and then (presumably)
> give you a different installer that automatically does that or not. That's a
> clever way to retain user choice, but completely eliminate the first-run
> prompt.

That does look like a good way to do things and could (probably should) be done independently of the mechanism we use in the browser.


(In reply to Dão Gottwald [:dao] from comment #44)
> (In reply to Philipp Sackl [:phlsa] from comment #42)
> > Yes, this bar only makes sense if it is at the top of the window, because
> > users likely won't notice it at the bottom.
> 
> Other global notification bars are already at the bottom. They may not be
> super important, but surely we don't expect the to likely go unnoticed. So
> either what you say isn't true or it's something we need to fix asap
> regardless of this bug, and in the meantime this patch can already use the
> global notification box assuming it will be fixed.

Almost every eye tracking heatmap I've seen clusters heavily around the top and usually has less than 10% of people notice things going on at the bottom. Not sure if we ever did something like that for Firefox.
AFAICT, none of the global bars we had so far has as much user impact as this one, which could be why that wasn't a huge problem up until now.
Is there a list of what global notification bars we have right now?

Comment 52

[u428464]

I know it's the purpose of this bug to go away from modal dialog. But wouldn't something like this mockup work : https://bug1020871.bugzilla.mozilla.org/attachment.cgi?id=8439891 It's more intrusive than a notification bar but it's a lot more noticeable.

Comment 53

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Guillaume C. [:ge3k0s] from comment #52)
> I know it's the purpose of this bug to go away from modal dialog. But
> wouldn't something like this mockup work :
> https://bug1020871.bugzilla.mozilla.org/attachment.cgi?id=8439891 It's more
> intrusive than a notification bar but it's a lot more noticeable.

That is the design for tab-modal dialogs. Maybe we can take some cues from it, but the current design wouldn't help a lot in the case of setting the default browser because it is tab specific (so it can get lost when a second tab is opened).

Comment 54

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

(In reply to Philipp Sackl [:phlsa] from comment #51)
> Almost every eye tracking heatmap I've seen clusters heavily around the top
> and usually has less than 10% of people notice things going on at the
> bottom. Not sure if we ever did something like that for Firefox.
> AFAICT, none of the global bars we had so far has as much user impact as
> this one, which could be why that wasn't a huge problem up until now.
> Is there a list of what global notification bars we have right now?

Note that Internet Explorer uses bottom notification bars and their implementation is more noticeable (uses color, overlays content, is taller) than the Firefox implementation.

Comment 55

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

As a follow-up to comment #54, Internet Explorer opens a tab to an about: page when it finds that it is no longer the default browser. This would be a very simple solution to this bug and even if it becomes unselected by an add-on it would still be around to be seen later.

Comment 56

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

Attachment: Tab-prompts spec

I'll work on implementing the design specs that were linked to in bug 1024741 comment 8, which is a tab-based approach instead of trying to move the global notification bar.

Comment 57

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

Attachment: Patch

This patch is almost complete. There are three things left to do:
1) The label and access key aren't showing up on the id="options" button. I can't figure out why, but the generated markup is looking like:
  <xul:button type="menu-button">
    <xul:menupopup>
      <xul:menuitem label="Not now" accesskey="N"/>
    </xul:menupopup>
    <button class="button-menubutton-button>#text #text</button>
    <button class="button-menubutton-dropmarker"/>
  </xul:button>
Setting a label and accesskey attribute on the <xul:button type="menu-button"> doesn't fix it. For some reason, the nested button's <xul:label> and <xul:image> aren't being generated from the binding.

2) The vertical positioning of the options button doesn't match the setAsDefault button.

3) It is not clear what we should do after a choice has been made. My thought is that we can redirect to about:home (using switchToTabHavingURI so that we don't have duplicate about:home tabs if it's already open). Maybe show a "Thanks! Redirecting you to &brandShortName; in 5 seconds", where 5 changes from 5..4..3..2..1 until the redirect happens.

Flagging needinfo from phlsa on issue #3, flagging feedback from unfocused on #1.

Comment 58

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo? me) from comment #57)
> 3) It is not clear what we should do after a choice has been made. My
> thought is that we can redirect to about:home (using switchToTabHavingURI so
> that we don't have duplicate about:home tabs if it's already open). Maybe
> show a "Thanks! Redirecting you to &brandShortName; in 5 seconds", where 5
> changes from 5..4..3..2..1 until the redirect happens.

If you close the tab, the user should be taken to the tab that would otherwise have been selected on startup, but only if you opened your tab the right way (which you currently don't; you need to use openUILinkIn). I don't see why we should load about:home here if the user set a different home page.

By the way, bug 1024741 mocked up two different notifications, both of which seem to use "set as default browser" as dummy content. I'm not sure why you jumped the gun on this bug, as there's no word in bug 1024741 on which design the default browser notification should use. Apparently bug 1028966 was filed to flesh that out.

Comment 59

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

(In reply to Dão Gottwald [:dao] from comment #58)
> (In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo?
> me) from comment #57)
> > 3) It is not clear what we should do after a choice has been made. My
> > thought is that we can redirect to about:home (using switchToTabHavingURI so
> > that we don't have duplicate about:home tabs if it's already open). Maybe
> > show a "Thanks! Redirecting you to &brandShortName; in 5 seconds", where 5
> > changes from 5..4..3..2..1 until the redirect happens.
> 
> If you close the tab, the user should be taken to the tab that would
> otherwise have been selected on startup, but only if you opened your tab the
> right way (which you currently don't; you need to use openUILinkIn).

Yeah, I can make the switch to openUILinkIn

> I don't
> see why we should load about:home here if the user set a different home page.

That's a good point.
 
> By the way, bug 1024741 mocked up two different notifications, both of which
> seem to use "set as default browser" as dummy content. I'm not sure why you
> jumped the gun on this bug, as there's no word in bug 1024741 on which
> design the default browser notification should use.

"jumping the gun" is not what I did here. I see that it wasn't communicated in the bugs, which was an oversight and should have been done. After talking with mmaslaney over IRC after the notification-bar design was uploaded, we decided to go with the tab-based prompt since it will be more noticeable than the current global-notificationbar.

> Apparently bug 1028966
> was filed to flesh that out.

Bug 1028966 is looking for other ways to prompt people to make Firefox their default browser, such as snippets, reminders after N days, etc.

Comment 60

[:Gijs (he/him)]

Is there a plan yet on how to measure impact on ADUs/install success and so on? I'm not sure we should proceed without having a solid idea about how we're measuring success/failure here.

Comment 61

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

The plan is to monitor ADUs/install success that we currently track with Telemetry and blocklist pings. We need to be aggressive with backing out this change if we notice that it is having a negative effect.

Comment 62

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

Attachment: Patch v1

Addressed issues #1 and #2 as well as comment #58.

Comment 63

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo? me) from comment #57)
> 3) It is not clear what we should do after a choice has been made. My
> thought is that we can redirect to about:home (using switchToTabHavingURI so
> that we don't have duplicate about:home tabs if it's already open). Maybe
> show a "Thanks! Redirecting you to &brandShortName; in 5 seconds", where 5
> changes from 5..4..3..2..1 until the redirect happens.

Ideally, we'd have some feedback right after the click (»Great, Firefox is now your default browser!«) and then, after a few seconds, close the tab so the user ends up on the page he usually would have ended up. I don't think we need a counter to indicate that automatism though.

Comment 64

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

(In reply to Philipp Sackl [:phlsa] from comment #63)
> (In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo?
> me) from comment #57)
> > 3) It is not clear what we should do after a choice has been made. My
> > thought is that we can redirect to about:home (using switchToTabHavingURI so
> > that we don't have duplicate about:home tabs if it's already open). Maybe
> > show a "Thanks! Redirecting you to &brandShortName; in 5 seconds", where 5
> > changes from 5..4..3..2..1 until the redirect happens.
> 
> Ideally, we'd have some feedback right after the click (»Great, Firefox is
> now your default browser!«) and then, after a few seconds, close the tab so
> the user ends up on the page he usually would have ended up. I don't think
> we need a counter to indicate that automatism though.

Ok, the current patch changes the button from "Use &brandShortName; as my default browser" to "&brandShortName; is your default browser". I can tweak the wording to your suggestion after Dao reviews the rest of the patch.

Comment 65

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

OK, I didn't follow the thread closely enough and my last comment was made under the assumption that we are still using a notification bar.

When we are using the full page dialog, we should differentiate between two cases:

1) First run: Show the confirmation and then redirect to about:home (because that's where people would have ended up anyway).

2) If a session is restored: The tab should simply be closed so that the user gets to the page he would have ended up at. If the dialog tab is the only tab, go to about:home (in that same tab)

It would also make sense to use a visual (say, a checkmark) and some animation to make it clear that setting the default browser has worked.
Michael, does the design still stand or did you change anything based on the concerns around this looking very similar to about:home?

Comment 66

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

(In reply to Philipp Sackl [:phlsa] from comment #65)
> OK, I didn't follow the thread closely enough and my last comment was made
> under the assumption that we are still using a notification bar.
> 
> When we are using the full page dialog, we should differentiate between two
> cases:
> 
> 1) First run: Show the confirmation and then redirect to about:home (because
> that's where people would have ended up anyway).
> 
> 2) If a session is restored: The tab should simply be closed so that the
> user gets to the page he would have ended up at. If the dialog tab is the
> only tab, go to about:home (in that same tab)

I think the only time we should do a redirect of some sort is if the about:defaultbrowser page is the only tab open. All other times it can be closed and their other tabs (such as their home page(s) or the restored session tabs) will be selected.

[Flagging needinfo for mmaslaney from comment #65]

Comment 67

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo? me) from comment #66)
> I think the only time we should do a redirect of some sort is if the
> about:defaultbrowser page is the only tab open. All other times it can be
> closed and their other tabs (such as their home page(s) or the restored
> session tabs) will be selected.

I generally agree, but first run is a different case for a few reasons:
- There is no session to restore and no custom home page.
- We already show two tabs on startup, so that would be the third one (which feels like a lot to me).
- Navigating feels like a less jarring transition as opposed to tab switching (though none of theme is _extremely_ jarring).


That being said, all of this might be questionable because of a good point that Michael Verdi just raised:
How does this interact with the UI tour that users see on first run?

I don't have an answer for that from the top of my head. Perhaps Michael (Maslaney) knows more.

Comment 68

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

We will still be running the UI tour in Firefox 33?

Comment 69

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo? me) from comment #68)
> We will still be running the UI tour in Firefox 33?

I'm not sure, but even if we don't, it is a mechanism to talk to users that we'll likely use in the future as well. So we should have a solution for that.

Comment 70

[:Gijs (he/him)]

We could integrate this as some kind of default UI tour...

Comment 71

[Verdi [:verdi] Best to slack me]

(In reply to Jared Wein [:jaws] [Away for most of July] (please needinfo? me) from comment #68)
> We will still be running the UI tour in Firefox 33?

We have two tours. One is a "firstrun" or new user tour so I think we should assume that we'll be showing it (or some future version of it) for now. The other tour is a "what's new" tour. That is something we will only show when we have something big (like australis) to talk to users about. I don't know about Fx 33 though we might be showing it to users who are updating to 33 from 28 or lower.

Comment 72

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #70)
> We could integrate this as some kind of default UI tour...

That's an interesting idea… we'd have to make sure that it stands out enough though. And we'd probably need a different mechanism for non-first-run cases.

In general, let's hold off from implementing this further until we have a good solution for all these issues.

Comment 73

[Michael Maslaney [:mmaslaney] ([e-mail])]

(In reply to Philipp Sackl [:phlsa] from comment #65)
> OK, I didn't follow the thread closely enough and my last comment was made
> under the assumption that we are still using a notification bar.
> 
> When we are using the full page dialog, we should differentiate between two
> cases:
> 
> 1) First run: Show the confirmation and then redirect to about:home (because
> that's where people would have ended up anyway).
> 
> 2) If a session is restored: The tab should simply be closed so that the
> user gets to the page he would have ended up at. If the dialog tab is the
> only tab, go to about:home (in that same tab)
> 
> It would also make sense to use a visual (say, a checkmark) and some
> animation to make it clear that setting the default browser has worked.
> Michael, does the design still stand or did you change anything based on the
> concerns around this looking very similar to about:home?

Philipp, I believe so. Designing the default browser page to resemble about:home was intentional, as it creates a foundation, unifying our browser's dialog on a tab level. That being said, we'll need to design the confirmation screen.

Comment 74

[Marco Mucci [:MarcoM]]

Removed from Iteration 33.2

Comment 76

[Madhava Enros [:madhava]]

Just duped a newer bug to this one (to keep all this context), but the design direction in the newer one was the new direction to pursue. Copied from the newer one:

(From Sevaan Franks)
The modal pop-up window is too disruptive and has a high annoyance factor for our users. Instead, we would like to replace it with a notification bar.

Mockup and specs here: https://bugzilla.mozilla.org/attachment.cgi?id=8387819

Comment 77

[Sevaan Franks [:sevaan]]

Attachment: Mockup/Specs for Default Browser Prompt Notification Bar

Comment 78

[Asaf Romano (gone)]

Attachment: Gijs's patch, without the styling bits, using the new notification box

The new, and unified, styling for the all notifications is going to happen in bug 1025182. I therefore removed all the sytling bits from Gijs's patch. I could (or should, or shouldn't) take care of showing some sort of dropmarker on OS X. Assuming the new styling lands for the same release, that would be a waste of time, but it might be risky to live it unfixed.

The only other change is the adoption of the new, top global notification box.

Comment 79

[Dão Gottwald [:dao]]

Comment on attachment 8466954 [details] [diff] [review]
Gijs's patch, without the styling bits, using the new notification box

>+if CONFIG['MOZ_WIDGET_TOOLKIT'] in ('windows', 'gtk2', 'gtk3', 'cocoa'):
>+  DEFINES['HAVE_SHELL_SERVICE'] = 1
>+

>+#ifdef HAVE_SHELL_SERVICE
>+XPCOMUtils.defineLazyServiceGetter(this, "ShellService",
>+                                   "@mozilla.org/browser/shell-service;1",
>+                                   "nsIShellService");
>+#else
>+this.ShellService = null;
>+#endif

>     // Perform default browser checking.
>-    var shell;
>-    try {
>-      shell = Components.classes["@mozilh la.org/browser/shell-service;1"]
>-        .getService(Components.interfaces.nsIShellService);
>-    } catch (e) { }
>-    if (shell) {

Setting ShellService in try/catch like before seems preferable over the hardcoded ifdef condition to me.

>--- a/toolkit/content/widgets/notification.xml
>+++ b/toolkit/content/widgets/notification.xml
>@@ -115,16 +115,19 @@
>               var defaultElem;
> 
>               for (var b = 0; b < aButtons.length; b++) {
>                 var button = aButtons[b];
>                 var buttonElem = document.createElementNS(XULNS, "button");
>                 buttonElem.setAttribute("label", button.label);
>                 buttonElem.setAttribute("accesskey", button.accessKey);
>                 buttonElem.classList.add("notification-button");
>+                if (button.popup) {
>+                  buttonElem.classList.add("notification-button-dropdown");
>+                }

This isn't used anymore in this patch.

Comment 80

[Asaf Romano (gone)]

Attachment: checked in

I took the liberty of removing all the introduced HAVE_SHELL_SERVICE usage in nsBrowserGlue, that is the only other remaining bit: the #ifdef around the DefaultBrowserCheck object. Since DefaultBrowserCheck isn't used if SheelService is null, the only effect this has on shell-service-less builds is may be half a byte or so in the Amiga build size.

So no moz.build changes either.

Comment 81

[Asaf Romano (gone)]

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

Comment 82

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/72de0ffdfbd6

Comment 83

[Camelia Badau [:cbadau], Desktop QA]

Verified on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OSX 10.8.5 using latest Nightly 34.0a1 (buildID: 20140818030205) and the notification bar for setting the default browser correctly appears, but the following mentions should be done: 
- the height of notification bar is 28px on Windows and Ubuntu and 24px on Mac - is this ok? 
- the Nightly icon (from the left corner) is not vertically centered 
- after I select "Use Nightly as my default browser", the notification bar is closed , but I'm not announced that Nightly was set as my default browser - is this intended behaviour? 
- on Ubuntu : after I select "Use Nightly as my default browser" , Nightly became my default browser - this is correct; but after I restarted the browser, the notification bar for setting the default browser appears again, even if Nightly is my default browser - should I file a bug for this?

Comment 84

[Asaf Romano (gone)]

(In reply to Camelia Badau, QA [:cbadau] from comment #83)
> Verified on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OSX 10.8.5 using
> latest Nightly 34.0a1 (buildID: 20140818030205) and the notification bar for
> setting the default browser correctly appears, but the following mentions
> should be done: 
> - the height of notification bar is 28px on Windows and Ubuntu and 24px on
> Mac - is this ok? 

I think that's the case for all "old-style" notifications bars. So yes, that's expected. This styling is expected to change though.

> - the Nightly icon (from the left corner) is not vertically centered 

File a bug please.

> - after I select "Use Nightly as my default browser", the notification bar
> is closed , but I'm not announced that Nightly was set as my default browser
> - is this intended behaviour? 

The spec didn't require that as far as I can tell. Only UX can answer that.

> - on Ubuntu : after I select "Use Nightly as my default browser" , Nightly
> became my default browser - this is correct; but after I restarted the
> browser, the notification bar for setting the default browser appears again,
> even if Nightly is my default browser - should I file a bug for this?

File a bug, please. This sound pretty bad. Is the preferences window broken too (i.e. do you see the "Make Nightly My Default Browser" button)?

Comment 85

[Camelia Badau [:cbadau], Desktop QA]

> > - the Nightly icon (from the left corner) is not vertically centered 
> 
> File a bug please.
 
I filled bug 1058431. 

> 
> > - on Ubuntu : after I select "Use Nightly as my default browser" , Nightly
> > became my default browser - this is correct; but after I restarted the
> > browser, the notification bar for setting the default browser appears again,
> > even if Nightly is my default browser - should I file a bug for this?
> 
> File a bug, please. This sound pretty bad. Is the preferences window broken
> too (i.e. do you see the "Make Nightly My Default Browser" button)?

I already filled bug 1056056 . 
The "Make Nightly My Default Browser" button correctly appears in the preferences window.

Comment 86

[Camelia Badau [:cbadau], Desktop QA]

> 
> > - after I select "Use Nightly as my default browser", the notification bar
> > is closed , but I'm not announced that Nightly was set as my default browser
>

Can you provide any info regarding this matter? Is this intended behaviour?

Comment 87

[Sevaan Franks [:sevaan]]

Yes, that is the intended behaviour. Once you select it as your default browser, that's it. We don't need a confirmation screen after to let the user know they have made a choice.

Comment 88

[jaramat]

(In reply to Sevaan Franks [:sevaan] from comment #87)

That is correct, though now that I think about it, it would be pretty nice if the button "Use Firefox as my default browser" got replaced by some kind of confirmation text once user clicks on it, and then after some delay (like 2 seconds) the notification panel closes. This would be helpful especially if the user account isn't an admin, and Firefox has to ask for elevated privileges to perform the action.

Comment 89

[Camelia Badau [:cbadau], Desktop QA]

(In reply to jaramat from comment #88)
> (In reply to Sevaan Franks [:sevaan] from comment #87)
> 
> That is correct, though now that I think about it, it would be pretty nice
> if the button "Use Firefox as my default browser" got replaced by some kind
> of confirmation text once user clicks on it, and then after some delay (like
> 2 seconds) the notification panel closes. This would be helpful especially
> if the user account isn't an admin, and Firefox has to ask for elevated
> privileges to perform the action.

Do you want me to track this in another bug and to close this one?

Comment 90

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

(In reply to Camelia Badau, QA [:cbadau] from comment #89) 
> Do you want me to track this in another bug and to close this one?

New bug is preferred when the current bug is already closed and the fix is not extremely trivial (typo, etc).

Comment 91

[Camelia Badau [:cbadau], Desktop QA]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #90)
> (In reply to Camelia Badau, QA [:cbadau] from comment #89) 
> > Do you want me to track this in another bug and to close this one?
> 
> New bug is preferred when the current bug is already closed and the fix is
> not extremely trivial (typo, etc).

I filled bug 1061479 (enhancement).

Comment 92

[Liz Henry (:lizzard) (relman/hg->git project)]

Release Note Request (optional, but appreciated)
[Why is this notable]: This is the best thing ever if you install lots of versions of Firefox every day on new profiles. Best.  Best!! I'm sure it's also great for first-time users not to have pop-ups to click through. 
[Suggested wording]: Non-intrusive way to set Firefox as default browser. 
[Links (documentation, blog post, etc)]: 

I'm sure there is a nicer way to word this, but anyhow, it seems worth a note.

Comment 93

[Sylvestre Ledru [:Sylvestre]]

Added in the release notes with "Non-intrusive way to set Firefox as default browser" as wording.

Comment 94

[:Gavin Sharp [email: [e-mail]]]

We should un-relnote this given bug 1086958.

Comment 95

[Sylvestre Ledru [:Sylvestre]]

un-relnoted!