1873791 - Add support for bookmarks toolbar experiments

Status: RESOLVED DUPLICATE of bug 1912333

(Firefox :: Messaging System, task, P2)

Description

[Shane Hughes [:aminomancer]]

It's possible, using setPref, to turn the bookmarks toolbar on temporarily. But at the end of the experiment, that setting will be lost. For messaging experiments, we want the ability to:

• turn on the bookmarks toolbar
• when the user visits a certain site, we will show a message pointing to the bookmarks toolbar that will ask them if they want to:
  A. bookmark that site
  B. keep the toolbar enabled
• when the experiment ends, their choice will persist permanently

This can be done like this:

1. change the Nimbus feature from setPref to fallbackPref
2. have the fallback pref browser.toolbars.bookmarks.visibility in firefox.js be newtab by default
3. have the experiment set the nimbus var to always
4. include a message in the experiment (it'll need to be a multi feature experiment with a messaging system feature) that has a CTA to set browser.toolbars.bookmarks.visibility to always
5. when the experiment ends, the nimbus var will disappear, so it will resume using the fallback pref, which (if they clicked yes) is now always instead of newtab

This doesn't change how the toolbar visibility works for users not enrolled in a bookmarks toolbar experiment. In the absence of such an experiment, NimbusFeatures.bookmarks.getVariable("enableBookmarksToolbar") will just be a wrapper for Services.prefs.getStringPref("browser.toolbars.bookmarks.visibility"). But during an experiment, it will return the experimental value instead.

So this bug is about changing the bookmarks toolbar code so that it checks a Nimbus variable instead of checking the pref directly.

Comment 1

[Shane Hughes [:aminomancer]]

CCing frontend engineers since this would require changing the frontend code that reads the pref to show/hide the toolbar.

Comment 2

[:Gijs (he/him)]

Generally CC'ing people isn't enough to get them to weigh in on things (or even get email, in lots of cases). I also don't see questions here. I also don't see enough context. Why would we do this, and what do you need from frontend?

Comment 3

[Shane Hughes [:aminomancer]]

Changing to a Nimbus variable is necessary for experiments on increasing bookmarks usage. The high level rationale for these experiments is to fulfill one of the growth levers the team identified.

We've done some preliminary experiments in this area, but the current setPref configuration is problematic: Nimbus resets the prefs it set at the end of the experiment, even if the user changed the pref through explicit interaction during the experiment. Here is the currently planned experiment design.

This requires changing most of the references to browser.toolbars.bookmarks.visibility to NimbusFeatures.bookmarks.getVariable("enableBookmarksToolbar"), so we want to make sure frontend understands what we're doing and agrees with this change. And if frontend engineers are not aware of the change, there might be some confusion if additional references are added in the future.

I think we can handle the engineering work ourselves, but I wanted to give you an opportunity to raise objections and, if all is OK, review the patch.

Comment 4

[Shane Hughes [:aminomancer]]

Since fallbackPref is deprecated, the solution for this bug has changed. Instead of what I proposed originally, the idea is to add a second pref for bookmarks toolbar visibility, reflecting the user choice - similar to the 2 auto-open prefs for Review Checker. The first (existing) pref would be controlled by the user, while the second (new) pref would be controlled by the experiment. Both prefs would have the same value on the default branch. If the first pref does not have a user value, we'd fall back to the second pref. This would support the following experiment design:

1. The experiment's bookmarks feature config automatically switches the behavior from newtab to always, for its duration, by changing the second pref - we'll call it browser.toolbars.bookmarks.userVisibility.
2. The experiment's featureCallout feature config shows a callout panel, anchored to the bookmarks toolbar (whose visibility the experiment guaranteed, per step 1).
3. The callout panel contains radio buttons or similar UI, allowing the user to choose their preferred visibility setting from newtab, always, or never. This radio group will control the first pref, browser.toolbars.bookmarks.visibility.
4. The first pref will take precedence over the second pref, so if the user chose never, the bookmarks toolbar will disappear now, so the experiment is essentially finished for that user.
5. When the experiment ends, and the user is unenrolled, the branch configs will be removed. The second pref, which was controlled by the experiment, will now be reset. The first pref will not be reset, since it was not set by the Nimbus client. So the unenrollment won't affect the bookmarks toolbar visibility if the user made a selection in the feature callout.

So, the user's selection will take effect immediately and permanently, and the transition when the experiment ends will be seamless. Users who didn't make a selection will return to the default experience (only visible on newtab).

Comment 5

[Shane Hughes [:aminomancer]]

Bumping to P1 as this blocks our Bookmark Toolbar Default On experiment.

Comment 6

[Mimi Jung]

Attachment: WIP: Bug 1873791 - Add ability to perform actions on feature callout impression

Comment 7

[Mimi Jung]

Removing iteration and setting this as P2 as we're moving forward with design A & BB instead. We still want to eventually consider having an on-show trigger but there isn't a current use case for it.

Comment 8

[Mimi Jung]

I believe this has been covered by the following two bugs:
1912333
1916852

Going to close this bug as a duplicate unless you think there's a reason to keep it open Shane? I think it makes sense to open another bug for actions on message impression/load when we decide to prioritize that but that seems separate from the scope of this bug.