Closed Bug 1429814 Opened 6 years ago Closed 6 years ago

Create custom funnelcake build that installs a given add-on during Firefox installation

Categories

(Firefox :: Installer, enhancement, P2)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: RT, Unassigned)

References

Details

User Story

As a product manager I want to test if letting users install an add-on along with Firefox drives Firefox downloads.

Notes: 
- this test will be done through making a custom build available for download on a AMO page (very limited scale). Basic QA will be applied.
- this bug covers the creation of the build allowing to pre-install an add-on.
- There is no new UX, the install process and first Firefox launch experience are unchanged besides the fact that an add-on happens to be installed when the user first opens the browser.
- This bug does not cover requirements for the download page that get handled separately

Acceptance criteria:
- Custom funnelcake build includes the custom stub installer
- The custom stub installer downloads a Web extension theme (https://addons.mozilla.org/en-US/firefox/addon/youtube-dark-purple/) during the installation process. The Web extension theme gets installed when Firefox is first opened.
- No door hanger gets displayed when Firefox is first launched. We recognize the need for user information but the technical complexity of using the add-on door hanger means we could not meet the timelines requested (ship by end of January a limited test). A WebExtension theme also does not typically require access to user data.

Plan:
- Deliver custom build by Jan 22nd
- Test done by Jan 26th
- Launch test by Jan 29th

Attachments

(5 files, 2 obsolete files)

      No description provided.
User Story: (updated)
User Story: (updated)
Matt, Kev and Scott the theme to be https://addons.mozilla.org/en-US/firefox/addon/youtube-dark-purple/
Thanks for confirming if that's all you need to work on the build.
User Story: (updated)
Flags: needinfo?(mhowell)
Okay, this patch implements the feature described in the user story, for the addon mentioned in the previous comment. This is not yet the generalized version, it's hard-coded to the Dark Purple Youtube Theme addon.

Romain, I think I remember you saying you had talked to Sylvestre about this test, but it looks like he's out on PTO right now; did he mention what we need to do to kick off getting a test build created?
Flags: needinfo?(mhowell) → needinfo?(rtestard)
I was assuming we had not technical dependencies on relman for this.
Sylvestre, can you please point us to the right person to get help to sign a test build?
Flags: needinfo?(rtestard) → needinfo?(sledru)
This is a build of the stub installer with the above patch.
Comment on attachment 8944433 [details]
Stub installer build - for testing only

To clarify, this build is for QA use, not for user testing.
If you need a binary signature, this will probably be on releng. 
Catlee is on pto, so, redirecting to Jordan
Flags: needinfo?(sledru) → needinfo?(jlund)
It's been a while since we have done a funnelcake. Normally we create N funnelcakes by repacking off some specific version, sign, and upload to candidates dir. It sounds like here we just need to sign a stub installer?

Nick is our funnelcake expert. Nick, do you have any context here? Have we signed bits out band like this before outside normal procedure? Is this on your radar for upcoming funnelcakes?
Flags: needinfo?(jlund) → needinfo?(nthomas)
I haven't seen this bug before, thanks for looping me in. Normally we'd ask for bugs to be filed in Release Engineering :: Releases: Custom Builds, but this is a new type of funnelcake (aren't they all!) so I see how it was set up differently.

So, this looks like a one-off signing request, so that AMO can host the custom stub installer which installs the add-on. Will QA work need the testing stub to be signed, or just the final stub ? I was able to click around Windows 10's protections and run the stub in comment #4 as it is.

There doesn't appear to have any of the usual funnelcake tagging we use for tracking retention of the cohort, should there be some ? We'd need to lay down a distribution\distribution.ini file to achieve that, unless there is some other mechanism not mentioned here.
Flags: needinfo?(nthomas)
I have tested the build from comment 4 and it passes all the tests.

Here is a link with the test report https://testrail.stage.mozaws.net/index.php?/reports/view/775

Please let me know in case you need other infos from me.
> There doesn't appear to have any of the usual funnelcake tagging we use for
> tracking retention of the cohort, should there be some ? We'd need to lay
> down a distribution\distribution.ini file to achieve that, unless there is
> some other mechanism not mentioned here.

We'll want to track users of this funnelcake in telemetry (retention, engagement, ...). Matt do we need to add distribution.ini as suggested?
Flags: needinfo?(mhowell)
(In reply to CosminB from comment #9)
> I have tested the build from comment 4 and it passes all the tests.
> 
> Here is a link with the test report
> https://testrail.stage.mozaws.net/index.php?/reports/view/775
> 
> Please let me know in case you need other infos from me.

Thanks, Cosmin!

(In reply to Romain Testard [:RT] from comment #10)
> We'll want to track users of this funnelcake in telemetry (retention,
> engagement, ...). Matt do we need to add distribution.ini as suggested?

Going that route would mean making a full funnelcake build. Since we're trying to keep this simple, we could use attribution instead; I can just manually add that to a signed stub installer file, and it also ends up in telemetry.
Flags: needinfo?(mhowell)
> (In reply to Romain Testard [:RT] from comment #10)
> > We'll want to track users of this funnelcake in telemetry (retention,
> > engagement, ...). Matt do we need to add distribution.ini as suggested?
> 
> Going that route would mean making a full funnelcake build. Since we're
> trying to keep this simple, we could use attribution instead; I can just
> manually add that to a signed stub installer file, and it also ends up in
> telemetry.

Sounds good. From what I'm hearing in 57 attribution is finally working!
Nick, did the above answer your question? To summarize, I think we can use attribution parameters instead of a funnelcake ID for this case. Is there any other information you need to know?
Flags: needinfo?(nthomas)
Yes, I think so. What are our next steps ? Should RelEng sign the build from comment #4 as a release build ? Is there a plan for adding attribution/hosting/downloads ?
Flags: needinfo?(nthomas)
(In reply to Nick Thomas [:nthomas] (UTC+13) from comment #14)
> Yes, I think so. What are our next steps ? Should RelEng sign the build from
> comment #4 as a release build ?

Thanks. Yes, that would be perfect.

> Is there a plan for adding attribution/hosting/downloads ?

I think we settled on the idea of adding attribution, but that can only be done on a signed file (one carrying the special dummy certificate we made for that purpose); I cam do that step manually. This thing is going to get its own landing page for targeted users to download it from, but the details for that are still being worked on.
mhowell, could you please provide a setup-stub.exe which includes your patch. I can then sign that, repack into a stub installer, and sign that.
Flags: needinfo?(mhowell)
Yep, here you go. This is the same setup-stub.exe that's in the attached testing build.
Flags: needinfo?(mhowell)
Attached file Firefox Installer.exe (obsolete) —
Release-signed stub installer based on attachment 8947617 [details]. Includes dummy cert but no attribution code added (cue mhowell)

It seems to work as expected. In this case it would be nice to open Youtube in a tab so you can see it working straight away.

Working notes:
* signed attachment 8947617 [details] manually (creating attachment 8948323 [details])
* pushed a custom repackage config to try - https://hg.mozilla.org/try/rev/bf015e483d6379e380d74da57513dacc7f3501c3
* created a repackage task based on a Nightly job, using try push and signed setup-stub.exe - https://tools.taskcluster.net/groups/ORY-8WY8T3a3eHp8PezDnA/tasks/ORY-8WY8T3a3eHp8PezDnA/details
* manually signed resulting target.stub-installer.exe including dummy cert, and attached with this comment
Attachment #8948323 - Attachment is obsolete: true
(In reply to Nick Thomas [:nthomas] (UTC+13) from comment #19)
> Created attachment 8948328 [details]
> Firefox Installer.exe
> 
> Release-signed stub installer based on attachment 8947617 [details].
> Includes dummy cert but no attribution code added (cue mhowell)

Thanks Nick, that's perfect.

> It seems to work as expected. In this case it would be nice to open Youtube
> in a tab so you can see it working straight away.

Works straight away for me; as quickly as I can get a YouTube tab open, it's always purple.

I don't know if anyone has any preference as to which particular attribution values are used. My idea is to set the campaign field to something like "addon-bundle-201802" and leave the other fields blank, but I'm not really sure how this data is used in practice so I don't know if that's the best way or if we'd want something else.
Is it possible for firstrun to auto-open a second tab on YouTube so that the user doesn't have to open it themselves?
Scott has been talking to the developer to see if he's willing to do that. NI'ing Scott for an update.
Flags: needinfo?(sdevaney)
I've added the attribution value that I suggested in comment 20. I can easily change it if anyone wants something different; otherwise, this file is finished and ready to go for user testing.
Attachment #8948328 - Attachment is obsolete: true
After a few back and forth email exchanges, it appears the developer is not interested in adding a startup page to the experience. I've specifically mentioned it twice now.
Flags: needinfo?(sdevaney)
Blocks: 1437185
I tested the build from comment 23 and noticed that I can reproduce the Bug 1437185.

I noticed that the signed version is Firefox 58.0.2 (20180206200532), the version that I used for testing from the comment 4 at that time was Firefox 60.

Matt could you confirm please if these changes are intended?
Flags: needinfo?(mhowell)
Attached file Logs.zip
I attached the logs from the browser console that are displayed when I start the Firefox for the first time.
(In reply to CosminB from comment #25)
> I tested the build from comment 23 and noticed that I can reproduce the Bug
> 1437185.
> 
> I noticed that the signed version is Firefox 58.0.2 (20180206200532), the
> version that I used for testing from the comment 4 at that time was Firefox
> 60.
> 
> Matt could you confirm please if these changes are intended?

58.0.2 is the expected version; it should be the latest version on the release channel as of whenever that installer is run. I may have changed how I built the more recent binary, I haven't been keeping track of that as well as I should have.

Bug 1437185 is of course not expected, but having looked at it I don't think it's anything to worry about; see my comment there.
Flags: needinfo?(mhowell)
Depends on: 1441271
Priority: -- → P2
Depends on: 1444189
This project ended up going a different direction.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: