1929652 - [SPIKE] need simple, cross-context targeting for desktop first run

Status: NEW

(Firefox :: Messaging System, task, P2)

Description

[Dan Mosedale (:dmosedale, :dmose)]

As a user who wants to target messages (and potentially experiments?) to avoid displaying a message during the first run after a user installs, I should be able to use a simple, well-documented attribute in both the messaging system and Nimbus experiment contexts.

Maybe also during the first run in a new (selectable or otherwise) profile? That could easily be spun into another bug, however.

Some discussion about the current state of affairs: in bug 1867871, comment 3, I wrote:

isFirstRun is not documented on the targeting page at all. My understanding is that because isFirstRun is passed by the installer, it probably won't work with other installation mechanisms (MSIX, Linux packaging stuff, ...). Worth verifying and adding.

and :aminomancer replied:

Targeting first run is currently somewhat informal. isFirstRun is only defined in the nimbus client targeting context (but not in the messaging system context). It returns the value of a pref. I think this pref starts as true, but then gets set to false after normandy is initialized for the first time. So it's only true during that first initialization of experiments (and other older types of studies).

isFirstStartup is also only defined in the nimbus client context. I think this is the one you're actually supposed to use in experiment advanced targeting configs, since the other one relies on an old normandy pref. From what I heard recently from Beth, this normandy code will be removed by the end of the year. It's the one that actually reflects the state of the --first-startup flag.

But in messages, we've been using !previousSessionEnd to exclude first run. We're not sure how reliable this is. It's stored in ASRouter's IndexedDB so, while it's unlikely to be erroneously cleared, I think it is per-profile, unlike isFirstStartup which is only true for that specific firefox launch. And there might be situations where it fails to be created, like maybe if Firefox crashes, the ASRouter uninit code does not run.

If we do include nimbus-only targeting attributes like isFirstStartup in the source doc, we should add a

⚠ NOTE: This targeting attribute is only available for the JEXL expressions of experiments' advanced targeting configs, which are defined in the experimenter repository. Targeting expressions for messages do not have access to this attribute.

I'm not sure if we can expose this attribute to messages, because it's only true for a brief window during startup. On the first run, it starts out as true, and then the code awaits the first evaluation of nimbus enrollments, and when that finishes, its value changes.

However, we could store some state in the FirstStartup module to indicate that it was initialized in this session. It doesn't init at all if it's not first startup. So an initialized property would suffice to permanently record that it is the first run. In fact, we could probably use FirstStartup.state !== FirstStartup.NOT_STARTED. But as you noted, there are ways to run Firefox where we may not have control of the command line arguments for the first firefox process. I guess you could combine the two so they cover some of each others' weaknesses: !isFirstStartup && !previousSessionEnd. But that still excludes situations where it's the first time a profile is run, but not the first time this firefox installation is run.

Perhaps this is the sort of thing we can rely on the new profile management state storage system for, to store a variable across all profiles.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Fixing the MSIX stuff is captured in bug 1929651.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

After discussing this with :rhelmer, who originally implemented the --first-install flag, he suggested talking to the desktop-integration teams about how this could be implemented on each platform using something not dependent on the installation method.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

That discussion also made it clear that one of the first things we probably want to do is to pull together a fairly explicit set of requirements, likely including at least some of

• usable for Nimbus enrollment
• usable for FxMS targeting
• doesn't become unset at any time during the first run
• is available suitably early during startup (how early?)
• same name as on mobile? (it would require we wait until the Normandy isFirstRun is removed, I think)
• handles pave-over installs?
• has defined (possibly configurable?) behavior for selectable profiles

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Marking this as a spike to formalize the above into an actual set of requirements and then play around to see what's practical and propose a design.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Setting to 5 points as a way to "point-box" this effort, and P2, since it seems like despite importance, we would not block this release on it.