Closed Bug 1593777 Opened 5 years ago Closed 5 years ago

[Post-Skyline] Setup WNP for users coming from equal to or greater than 70.0 and receiving the 70.0.2 release (actual release number TBD)

Categories

(Release Engineering :: Release Requests, task)

Product:
Release Engineering
Component:
Release Requests
Type:
task
Priority:
Not set
Severity:
major

Tracking

(firefox70blocking wontfix)

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox70 blocking wontfix

People

(Reporter: erenaud, Unassigned)

References

(
URL
)

Details

(Whiteboard: [releaseduty] [rca - product decision])

Request is to have the product point to the /whatsnew page in the Firefox 70.0.x (dot) release and show it (WNP). The content for the page can be seen in https://www.mozilla.org/firefox/66.0/whatsnew/all/ (ignore the version #)

Specification for this dot release:

locale version --> new version whatsnew
all listed 70.0 --> 70.0.x WNP-70.0.x
all listed <70 --> 70.0.x WNP-70.0

WNP Production schedule:

Eric can you specify which already existing WNP you want to show to which users?

Flags: needinfo?(erenaud)

According to Michele Warther we want to show https://www.mozilla.org/en-US/firefox/66.0/whatsnew/all/ to all users who update to 70.0.2.

Flags: needinfo?(erenaud)
Summary: [Post-Skyline] Setup WNP for users coming from <70.0.5 and receiving the 70.0.5 release (actual release number TBD) → [Post-Skyline] Setup WNP for users coming from equal to or greater than 70.0 and receiving the 70.0.2 release (actual release number TBD)

Alex - would you mind reviewing my update description? 1593777#c0

Flags: needinfo?(agibson)

Just to confirm if I understand this correctly:

  1. Users who open this URL should see the WNP that promotes Firefox Monitor:

  2. Users who open this URL should see the WNP that promotes Firefox on Mobile:

Is that correct?

Flags: needinfo?(agibson) → needinfo?(erenaud)

So, users updating from versions before 70 will see the Monitor page,
Users updating from versions before 70.0.2 (including 70.0.1) will see the Mobile page.

Note, we could also show users currently still updating to 70.0.1, one of these pages (right now, they don't see any WNP)

(In reply to Liz Henry (:lizzard) from comment #6)

Users updating from versions before 70.0.2 (including 70.0.1) will see the Mobile page.

The bug this was duplicated from depended on bug 1547830, which is a Firefox change that allowed showing a whats-new-page on a dot release. That change only was applied to 67.0.1 and 68.0, so even if whats_new_page.yml is updated to target 70.0/70.0.1 -> 70.0.2 users, I'm pretty sure Firefox 70.0.2 will not show the page without a code change.

https://hg.mozilla.org/releases/mozilla-release/file/FIREFOX_70_0_1_RELEASE/browser/components/BrowserContentHandler.jsm#l689

(In reply to Alex Gibson [:agibson] from comment #5)

Just to confirm if I understand this correctly:

  1. Users who open this URL should see the WNP that promotes Firefox Monitor:

  2. Users who open this URL should see the WNP that promotes Firefox on Mobile:

Is that correct?

Correct, yes. thanks Alex

I see Mardak. Do we need to request this be reopened 1556811 to implement the same behavior introduced in Trailhead?

Flags: needinfo?(erenaud) → needinfo?(edilee)

(In reply to Liz Henry (:lizzard) from comment #6)

So, users updating from versions before 70 will see the Monitor page,
Users updating from versions before 70.0.2 (including 70.0.1) will see the Mobile page.

Hello,
Does this apply for both users that are logged in and logged out before the update?

Flags: needinfo?(lhenry)

Sounds like we need a patch here.

Jim or Mardak, should this WNP show whether or not users are logged in?

Flags: needinfo?(lhenry)

(In reply to Ed Lee :Mardak from comment #7)

(In reply to Liz Henry (:lizzard) from comment #6)

Users updating from versions before 70.0.2 (including 70.0.1) will see the Mobile page.

The bug this was duplicated from depended on bug 1547830, which is a Firefox change that allowed showing a whats-new-page on a dot release. That change only was applied to 67.0.1 and 68.0, so even if whats_new_page.yml is updated to target 70.0/70.0.1 -> 70.0.2 users, I'm pretty sure Firefox 70.0.2 will not show the page without a code change.

https://hg.mozilla.org/releases/mozilla-release/file/FIREFOX_70_0_1_RELEASE/browser/components/BrowserContentHandler.jsm#l689

Yes agreed. I believe in addition to a balrog/update-server change (which could be configured in-tree[1] or in balrog itself manually) we need something like this trailhead patch[2] to support a 70.0 -> 70.0.* wnp. That needs to land and be built with a future dot release.

[1] https://searchfox.org/mozilla-central/source/browser/config/whats_new_page.yml#19
[2] https://hg.mozilla.org/releases/mozilla-release/rev/ad5f0d47928f96a6bb998da9eb52284f63ac036e

(In reply to Jordan Lund (:jlund) from comment #12)
[2] https://hg.mozilla.org/releases/mozilla-release/rev/ad5f0d47928f96a6bb998da9eb52284f63ac036e

as tomprince pointed out, this also assumes the in-product code hasn't changed since

Using the whats_new_page.yml mechanism, I don't think logged-in-ness can be considered when opening the page. However, the page can use UITour to show different content based on logged-in-ness as usual (with the caveat of 2% of users seem to have the wrong permission as per bug 1557153 comment 66 we worked around this wrong permission issue in bug 1557153).

Bug 1547830's patch, which landed in 67 release and 68 beta, no longer cleanly applies to current mozilla-central through mozilla-release. Looks like there's a conflicting change from bug 1555088 which landed in firefox 70. We could reopen bug 1556811 or directly uplift something to mozilla-release to allow the whats_new_page.yml page after some engineering work to get the show-on-dot-release functionality working without regressing the performance / activeUpdate changes from bug 1555088.

Otherwise, the usual show-whats-new-page-on-major-version-upgrade behavior could be used instead of the on-dot-release behavior, which would reach much fewer people. Alternatively, we show the whats_new_page with a moments remote message that can use the is-logged-in targeting (as well as targeting based on locale based on which ones are localized).

Depends on: 1547830
Flags: needinfo?(edilee)
See Also: → 1557153, 1556811

If we don't care if users are logged in or not, will it make the patch much easier/less risky?

Flags: needinfo?(edilee)

This probably doesn't belong in the release engineering component any more. Maybe UI Tours or Messaging?

Depends on: 1595570

Liz - MaryEllen just announce that the dot release (and WNP with it) has been killed. I'm retracting this request and closing the issue.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(lhenry)
Resolution: --- → INVALID

OK. Well, we all learned from the fire drill I guess. Thanks Eric!

status-firefox70: affected → wontfix
Flags: needinfo?(lhenry)

whats-new-page isn't set up to trigger differently based on logged-in-ness and it's done very early at startup, so not having the trigger would be much simpler.

Flags: needinfo?(edilee)

This bug has been identified as part of a pilot on determining root causes of blocking and dot release drivers.

It needs a root-cause set for it. Please see the list at https://docs.google.com/document/d/1FFEGsmoU8T0N8R9kk-MXWptOPtXXXRRIe4vQo3_HgMw/.

Add the root cause as a whiteboard tag in the form [rca - <cause> ] and remove the rca-needed keyword.

If you have questions, please contact :tmaity.

Keywords: rca-needed
Keywords: rca-needed
Whiteboard: [releaseduty] → [releaseduty] [rca - product decision]
You need to log in before you can comment on or make changes to this bug.