1584163 - All Sponsored cards are dismissed when any card is saved/archived/deleted to/from Pocket, bookmarked, unbookmarked, or dismissed

Status: RESOLVED DUPLICATE of bug 1581570

(Firefox :: New Tab Page, defect, P1)

Description

[Andreea Cupsa [:acupsa], Experiments QA]

[Tracking Requested - why for this release]:
Regression that blocks sponsored cards from showing up when any cards are bookmarked or saved to Pocket.

[Affected versions]:

• Firefox Beta 70.0b9, Build ID: 20190923154733
• Firefox Nightly 71.0a1, Build ID: 20190925215653

[Affected Platforms]:

• All Windows
• All Mac
• All Linux

[Prerequisites]:

• Have a new Firefox profile with the following preferences set:
  • browser.search.region to US

[Steps to reproduce]:

1. Open the browser with the profile from the prerequisites.
2. Open a new tab.
3. Click the Context Menu button from any card from the Recommended by Pocket section.
4. Click on the Bookmark button.
5. Observe the sponsored cards from the Recommended by Pocket section.

[Expected result]:

• The Sponsored cards from the Recommended by Pocket section are still displayed.

[Actual result]:

• The Sponsored cards are no longer displayed in the Recommended by Pocket section.

[Regression Range]:

• Due to the fact that this issue is not reproducible on Firefox Release 69 I ran a regression range and reached the following pushlog:
  7:42.10 INFO: application_version: 70.0a1
  Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
  8:01.00 INFO: Narrowed inbound regression window from [28ed211a, f71ac7e6] (4 builds) to [170a5ba0, f71ac7e6] (2 builds) (~1 steps left)
  8:01.00 INFO: No more inbound revisions, bisection finished.
  8:01.00 INFO: Last good revision: 170a5ba09a6f9847405bc522b4984f33dface562
  8:01.00 INFO: First bad revision: f71ac7e684fc2d2964e236ad944c72e1e73af756
  8:01.00 INFO: Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=170a5ba09a6f9847405bc522b4984f33dface562&tochange=f71ac7e684fc2d2964e236ad944c72e1e73af756

It looks like the issue was introduced with this export. It might have been caused by one of these bugs: bug 1566652 or bug 1566653.

[Notes]:

• This issue is also reproducible when saving to Pocket any Recommended by Pocket card.
• Attached a screen recording with the issue here.

@thecount, could you please take a look at this?

Comment 1

[Andreea Cupsa [:acupsa], Experiments QA]

After further investigation it seems that this issue is reproducible when:

• Dismissing a top site
• Bookmarking any card from the Recommended by Pocket and Highlights section
• Saving to Pocket any card from the Recommended by Pocket and Highlights section
• Dismissing any card from the Recommended by Pocket and Highlights section
• Archiving in Pocket any card from the Highlights section
• Deleting from Pocket any card from the Highlights section
• Removing bookmark from a card from the Highlights section
• Bookmarking or removing a bookmark from any other website while not being on the about:newtab page.

Comment 2

[Jessilyn Davis]

Scott is offline until 10/7 - Gavin and Nan, can you look at this ASAP and see what it'll take to get a fix uplifted into Beta?

Comment 3

[Nan Jiang [:nanj]]

I did some preliminary investigation on this, looks like it didn't get the layout.components[..].placement from the endpoint, so any user interaction on the Top Stories section would disappear all spocs.

Sumita, could you check if we have placement included in the component feed? The endpoint I was using is https://getpocket.cdn.mozilla.net/v3/newtab/layout?version=1&consumer_key=$apiKey&layout_variant=basic.

Comment 4

[Sumita Sami]

Had a brief convo with Nan. I am still not sure how the placement object is impacting spocs showing up, and that seems to be tied to the work that Scott did here: https://github.com/mozilla/activity-stream/commit/5fb6a1a33da6ce343369284eaa13c088ba7d7f6e.

From the backend side, placement is not a required property when asking for spocs: we introduced it for things like topsites and textpromo because we wanted to differentiate these spocs from the type of spocs that are usually returned by a call to Adzerk through backend. I suspect the issue with the code is within the patch I linked above. I'm more than happy to help with this, but I'd need gvn or someone else with actual front end expertise.

Comment 5

[Gavin Suntop [:gvn] (they/them)]

Looks like this issue was fixed in https://github.com/mozilla/activity-stream/commit/c9c543c221b4e86aa1ccb8f161df2609b348858c

Comment 6

[Nan Jiang [:nanj]]

K, we've found out that this issue is a dup of bug 1581570, Scott has already fixed it and flagged it for 70 uplift, let's use that bug to track the progress.