Desktop Sync currently has rudimentary support for notifying other clients when a "collection" has changed. While the capability is general, the current implementation is limited to notifying when the "clients" collection has changed

Firefox View (and the rest of the synced tabs UI) would benefit from getting a push notification when tabs are changed on another device - they could poll less frequently and the tabs would appear without delay.

The challenges here include

• push isn't as reliable as we would like. If consumers can't actually rely on this notification, they will then end up doing all the same polling they do now - we'll have increased complexity significantly.

• tabs are "written" frequently - on desktop they are synced within 5 seconds of a tab switch, so the volume of push notifications would be significant. We need to ensure the entire system (our back-end, our connections to mobile push systems, etc) are capable of dealing with this with reasonable costs.

• If we assume that all devices would read remote tabs on getting this notification, it would increase the frequency of tab syncing by all devices significantly - even though in most cases the tabs read would not actually be used (ie, today we force a tab sync as the UI is interacted with - this would cause us to sync tabs just incase the UI might be interacted with soon. Our storage servers must be prepared for this extra load.

• any such changes need to ride trains, so it will be months after implementing this before it can be relied on by front ends.

• our mobile sync implementations aren't really in a great place for this work - the sync implementation and the push implementation aren't coupled in a way that makes this easy. Further, the mobile platforms don't even support the rudimentary support desktop has - we should try and get parity in this regard too.

It's likely this bug will turn into a meta bug, but opening this now so we can get it on our roadmap.

Thank you for writing this up :markh!

I'll come back with some more thought-out analysis, but I wanted to briefly note a couple of other considerations.

• Apple has support for background push notifications. I believe is newish, as there are some notes in and around firefox-ios that imply that all push notifications require UI. However, background push notifications get throttled, and Apple recommends limiting to two or three per hour. That said, I'm sure there is a way we work with the limitation, given that our use case only adds value to the user if the app is foregrounded anyways. I doubt we'll be too sad if a user didn't get their synced tabs when the app was backgrounded. We will however want to make sure we carefully navigate the limitations so we don't get flagged by Apple.

• Another infrastructure to think about is the FxA infrastructure. In order to send commands, we have to interact with FxA, which in-turn will forward the messages to push. We could possibly skip the FxA step, maybe we can have clients send messages to auto-push directly? This naively sounds OK, as I believe we don't want to persist and poll the push messages (since there will be so many of them!)

(In reply to Tarik Eshaq from comment #1)

given that our use case only adds value to the user if the app is foregrounded anyways. I doubt we'll be too sad if a user didn't get their synced tabs when the app was backgrounded. We will however want to make sure we carefully navigate the limitations so we don't get flagged by Apple.

Thanks Tarik. For Firefox View on Desktop, it's probably only necessary that iOS sends notifications. So while there's devil in the detail, devices which send this notification could probably filter who it sends them to based on these kinds of considerations? And as you note below, the sending of these notifications doesn't involve the mobile OS at all.

• Another infrastructure to think about is the FxA infrastructure. In order to send commands, we have to interact with FxA, which in-turn will forward the messages to push. We could possibly skip the FxA step, maybe we can have clients send messages to auto-push directly? This naively sounds OK, as I believe we don't want to persist and poll the push messages (since there will be so many of them!)

This does indeed sound like the right thing to do for anything where we don't really care if it gets lost or not.

it's probably only necessary that iOS sends notifications

That definitely simplifies things! It's already possible for mobile devices to filter desktops from the devices list (the device list includes if a device is a mobile or desktop!)

One thing we could do as we get started is to add client telemetry. We can record:

• How often tab changes happen across different clients
• How many desktop devices the device has in it's devices list

This could give us a hand-wavy rough estimate of the compute-related impact something like this can have on our push infrastructure.

We might also want to think about the storage impact, Push stores notifications if it can't deliver them right away to desktop - with notifications happening at every tab change that's not a trivial additional storage cost - I'm not sure if we can evaluate that using the same client telemetry but maybe it's a good starting point.

Maybe there is work to do here in autopush too, where we can define a different class of notifications that autopush doesn't persist for desktop. But I don't really understand the push infra so JR will most definitely have a better answer here :P