When a user explicitly dismisses a sponsored tile, it would be great if we could sync that tile's "dismissed" state to the user's other Firefox installations via Firefox Sync.

(I don't think we do that yet; if we do, please let me know and I can try to gather more data about what I'm seeing here, in case something's going awry locally for me.)

Backstory: I use Firefox on several different machines, with Sync, and I also proactively dismiss sponsored tiles when I feel like I've seen them many times & am growing weary of them (in my case usually the "smiling woman holding up a credit card" ads).

I think I've seen cases where I've dismissed the tile on one machine and then I see it a day or so later on a different machine, though I'm not entirely certain, due to the inherent unpredictability of which-sponsored-tiles-get-served-when.

When this happens, my intuition is that my "dismiss" actions are just getting stored & respected locally, and aren't getting propagated to my other systems, which then causes me frustration when I open a new tab (on some other machine) and am then staring at a sponsored-tile that I remember dismissing.

The severity field is not set for this bug.
:daleharvey, could you have a look please?

For more information, please visit auto_nag documentation.

Thinking about this a bit more, I realized this feature-request should really cover all of the new-tab "Recommended by Pocket" tiles.

(There might already be an existing bug on this, too? I faintly recall seeing one in the past, though maybe not.)

STR:

1. Have two Firefox instances ("A" and "B"), set up to sync data with each other via the same Firefox account.
2. Open a new tab in both instances. Choose some pocket recommendation tile that's showing on the new-tab page in both instances. Pretend that you find it offensive or something.
3. In instance A, dismiss that tile.
4. Initiate a sync from instance A, and then from instance B (Tools | Sync Now), to give a chance for data to flow from A to B.
5. Refresh your new-tab in instance B.

EXPECTED RESULTS:
The recommended tile that I dismissed in instance A should also be dismissed on the new-tab for instance B.

ACTUAL RESULTS:
The recommended tile is still there, potentially causing me offense or confusion ("Wait, I thought I dismissed this... Why are you showing it to me again")

Clearing needinfos as triage owner has switched (apologies for any late replies, was not overly familiar with this area of code)

AFAICT these dismissals are currently stored in browser.newtabpage.blocked. That's a JSON dictionary with hashed URLs as keys. Because they're prefs, they could be synced - though I'm not sure how conflicts would be resolved. That is, if you block tile A on one machine and tile B on another, is there a way for code to run and reconcile the tiles, Mark? Because arguably the status quo is better than if we actually overwrote what tile you'd blocked on 1 of the machines...

If there isn't a way to run code under those circumstances, can you recommend a high level approach to take if we wanted to use pref sync to keep this list in sync across devices? And what are the scaling limitations there, on the sync side?

(I'm a bit nervous that this is apparently implemented the way it is, due to size limitations on the prefs, but I suppose that is partially orthogonal to this issue as filed...)

Going to move this to an enhancement as it's not really a bug as such - and similar sync requests (e.g. bug 943182) are also enhancements.

(In reply to :Gijs (he/him) from comment #4)

AFAICT these dismissals are currently stored in browser.newtabpage.blocked. That's a JSON dictionary with hashed URLs as keys. Because they're prefs, they could be synced - though I'm not sure how conflicts would be resolved. That is, if you block tile A on one machine and tile B on another, is there a way for code to run and reconcile the tiles, Mark?

No, there's not. We could probably make that happen though. We do process each pref individually, so I guess you could imagine something hacky like a hard-coded dictionary keyed by the pref name, then a module/function pair which would be called with the current and incoming prefs or something?

If there isn't a way to run code under those circumstances, can you recommend a high level approach to take if we wanted to use pref sync to keep this list in sync across devices? And what are the scaling limitations there, on the sync side?

browser.storage.sync (ie, as used by web extensions) has semantics a bit closer to what you are after - the top-level objects are merged. An extra complication here though is that this engine only syncs if "addons" are selected to sync.

If syncing pocket-specific things is a regular request, we could also implement an engine specific to pocket. This would require UI changes to add the checkbox etc, and would require some careful design, but wouldn't be an excessive amount of work, especially if it was only desired for desktop in the short term.

(I'm a bit nervous that this is apparently implemented the way it is, due to size limitations on the prefs, but I suppose that is partially orthogonal to this issue as filed...)

Going to move this to an enhancement as it's not really a bug as such - and similar sync requests (e.g. bug 943182) are also enhancements.

FWIW, this bug is the main meta tracking "please sync X"

Thanks Mark!