Closed Bug 1524028 Opened 10 months ago Closed 9 months ago

Enable ReturnToAMO by default in Beta/Release 66


(Firefox :: Messaging System, defect, P1)




Firefox 67
67.1 - Jan 28 - Feb 10
Tracking Status
firefox65 --- unaffected
firefox66 + verified
firefox67 --- verified


(Reporter: tspurway, Assigned: rrosario)


(Blocks 1 open bug)


(Keywords: github-merged)

User Story

In a fresh Firefox profile. On OSX make sure this is launched from the Applications folder and not from the installer.

> in order to confirm RTAMO is enabled

1. enable `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled`
2. navigate to `about:newtab#asrouter`, go to the "Targetting" section and scroll to the bottom
3. click `Force attribution`
4. navigate to `about:welcome` and confirm that the RTAMO message is shown


(2 files)

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.

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

Flags: needinfo?(tspurway)

ricky is taking it!

Assignee: nobody → rrosario
Flags: needinfo?(tspurway)
Priority: P2 → P1

MozReview-Commit-ID: 4FmeyYLhnDp

User Story: (updated)
Pushed by
Enable ReturnToAMO by default r=andreio
Flags: qe-verify+
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Whiteboard: [qa-triaged]

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?


Has the fix been verified in Nightly?


Needs manual test from QE?


If yes, steps to reproduce

See User Story.

List of other uplifts needed


Risk to taking this patch


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

It has had thorough QA.

String changes made/needed


Attachment #9042083 - Flags: approval-mozilla-beta?
Keywords: github-merged

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.

Flags: needinfo?(tspurway)
Flags: needinfo?(ddurst)
Attachment #9042083 - Flags: approval-mozilla-beta? → approval-mozilla-beta-


Flags: needinfo?(tspurway)

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.

Flags: needinfo?(ddurst)

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 on attachment 9042083 [details]
Bug 1524028 - Enable ReturnToAMO by default

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

Attachment #9042083 - Flags: approval-mozilla-beta- → approval-mozilla-beta?

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.

Attachment #9042083 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Flags: needinfo?(rrosario)

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

Flags: needinfo?(rrosario) → needinfo?(andrei.br92)

I don't see a beta 8 tag at this time.
Can you please confirm the build id used in testing? I could not confirm the bug in beta 7 on windows.

Flags: needinfo?(andrei.br92)
Flags: needinfo?(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

Flags: needinfo?(vlad.jiman) → needinfo?(andrei.br92)

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.

Flags: qe-verify+
Flags: needinfo?(andrei.br92)
QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]
Component: Activity Streams: Newtab → Messaging System
You need to log in before you can comment on or make changes to this bug.