1524028 - Enable ReturnToAMO by default in Beta/Release 66

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Tim Spurway [:tspurway]]

The feature is currently pref'd off. Let's deploy this feature in 66 by landing a pref on patch and uplifting it to beta.

Comment 1

[:shell escalante]

Is there anyone planning to take this bug? ETA? Ideally getting written and flipped in Beta 66.

Comment 2

[Tim Spurway [:tspurway]]

ricky is taking it!

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

Attachment: Bug 1524028 - Enable ReturnToAMO by default

MozReview-Commit-ID: 4FmeyYLhnDp

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/19cf89dc14e6
Enable ReturnToAMO by default r=andreio

Comment 5

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/19cf89dc14e6

Comment 6

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/activity-stream/pull/4776

Comment 7

[Ricky Rosario [:rrosario, :r1cky]]

Comment on attachment 9042083 [details]
Bug 1524028 - Enable ReturnToAMO by default

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1524028

User impact if declined

The return to AMO feature won't be enabled.

Is this code covered by automated tests?

Yes

Has the fix been verified in Nightly?

No

Needs manual test from QE?

Yes

If yes, steps to reproduce

See User Story.

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

It has had thorough QA.

String changes made/needed

N/A

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

The last comment from ddurst in Trello mentioned that we can't pref this on for Mac users.
David, Tim, I'm going to hold off here on uplift until I'm clear about the plan.

Comment 9

[Tim Spurway [:tspurway]]

x

Comment 10

[David Durst [:ddurst]]

Sorry, updated the plan in Trello. This should fail gracefully on Mac, making this Windows-only (and only for users installing Firefox from an AMO detail page, where the extension is one of a blessed set). The mac issue shouldn't block this being pref'd on by default in beta through to release.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, we can uplift for beta 8 then. It will be preffed off in beta 7 since we are now out of early beta and then should be turned back on in beta 8.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9042083 [details]
Bug 1524028 - Enable ReturnToAMO by default

Setting back to "?" for the next beta build on Thursday.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9042083 [details]
Bug 1524028 - Enable ReturnToAMO by default

OK for beta uplift; this is going to ride to 66 release on by default.

Comment 14

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/releases/mozilla-beta/rev/bfed614819c3

Comment 15

[Vlad Jiman]

We've verified the following versions: 66.0b7, 66.0b8 and 67.0a1 using Windows 10 x64 and macOS 10.13.6.

Testing has shown a possible problem on the Windows platform for versions beta 8 and Nightly as described below:

Windows - Beta 8 and latest Nightly:

• When a new profile is created and opened, the about:welcome page is showing the RTAMO flow (i.e. the install Iridium page) by default, without having to force attribute it via ASrouter. This behavior is not reproducing on the macOS platform.

MacOS - Beta 8 and latest Nightly:

• When a new profile is created and opened, the classic onboarding card is displayed (i.e. sign in to Sync); the about:welcome page does not open the RTAMO flow, unless we force:attribute it via ASrouter.

On the other hand, the feature is pref'd off on beta 7 for both macOS and Windows platforms and pref'd on for beta 8 and Nightly as expected.

Please confirm that the problem described above is indeed an issue based on which we can file a new bug.

Comment 16

[Ricky Rosario [:rrosario, :r1cky]]

The Windows issue in Comment 15 sounds like a possible bug. :andreio, can you confirm?

Comment 17

[Andrei Oprea [:andreio]]

I don't see a beta 8 tag at this time.
https://hg.mozilla.org/releases/mozilla-beta/tags
Can you please confirm the build id used in testing? I could not confirm the bug in beta 7 on windows.

Comment 18

[Vlad Jiman]

The issue we described reproduces on 67 and the 66 beta 8 - (20190213041922) build which we took from comment #14. Please let me know if you manage to confirm it

Comment 19

[Vlad Jiman]

After further testing with Andrei, it appears that the problem is only reproducible on machines that have used the Force Attribution method, a file is written and will persist throughout profile switches and fx versions, but it will not affect normal users, if anyone thinks it should be fixed I can log a new bug with low severity.

Regarding the validation of the bug: As I previously stated, testing has been carried out on the following platforms: 66.0b7, 66.0b8 and 67.0a1 using Windows 10 x64 and macOS 10.13.6 to make sure the switch is as mentioned in previous comments: off on Beta 7, on for Beta 8 and Nightly. As no other major issues were identified and the switch works as expected, I will mark these versions as verified.