@nalexander does something like this seem feasible?

I'd like to explore experimenting with different variants of the stub installer than include known growth levers like set to default and pin to taskbar. I know we've done at least one traffic cop experiment sending folks to different download pages in the past. Have we experimented with moving set to default into the installer flow before? @pdahiya mentioned pin to taskbar was included in the past, and I'm curious why it was removed.

In D223066#7669961, @mviar wrote:

@nalexander does something like this seem feasible?

I'd like to explore experimenting with different variants of the stub installer than include known growth levers like set to default and pin to taskbar. I know we've done at least one traffic cop experiment sending folks to different download pages in the past. Have we experimented with moving set to default into the installer flow before? @pdahiya mentioned pin to taskbar was included in the past, and I'm curious why it was removed.

Sure, stuff like this is definitely possible. However, the stub installer is 0-click by design: you launch it and you get Firefox, with no blocking user input. We'd definitely want product input on changing that.

In terms of what component actually applies the default -- the more that stays with Firefox, the better things are. Set-as-default is quite complicated and running the code in the installer is not attractive; we want all of Gecko available to us. And, in some cases, the APIs in question need the running process to _be_ Firefox, the process we want to act on. This is mostly why we removed pin to taskbar from the installer: we got a really awkward screen talking about setup.exe and not Firefox; and the resulting pin sometimes wouldn't work for firefox.exe anyway.

@nrishel, I'd like to get this onto your radar so that DI team is aware of work on the stub installer. Thanks, @mviar!

In D223066#7670844, @nalexander wrote:

In D223066#7669961, @mviar wrote:

@nalexander does something like this seem feasible?

I'd like to explore experimenting with different variants of the stub installer than include known growth levers like set to default and pin to taskbar. I know we've done at least one traffic cop experiment sending folks to different download pages in the past. Have we experimented with moving set to default into the installer flow before? @pdahiya mentioned pin to taskbar was included in the past, and I'm curious why it was removed.

Sure, stuff like this is definitely possible. However, the stub installer is 0-click by design: you launch it and you get Firefox, with no blocking user input. We'd definitely want product input on changing that.

In terms of what component actually applies the default -- the more that stays with Firefox, the better things are. Set-as-default is quite complicated and running the code in the installer is not attractive; we want all of Gecko available to us. And, in some cases, the APIs in question need the running process to _be_ Firefox, the process we want to act on. This is mostly why we removed pin to taskbar from the installer: we got a really awkward screen talking about setup.exe and not Firefox; and the resulting pin sometimes wouldn't work for firefox.exe anyway.

@nrishel, I'd like to get this onto your radar so that DI team is aware of work on the stub installer. Thanks, @mviar!

Thanks @nalexander! I've started discussion with product as it does venture from the current pattern. My idea was to make use of the existing set to default logic in BrowserContentHandler by just passing the -setDefaultBrowser flag if the box is checked (see last couple changed lines in stub.nsi below).

I should also note the idea wouldn't be to land this code in production, but to experiment with offering the resulting executable (or some variation(s)) to a percentage of users via an experiment using traffic cop.