1222594 - Desktop doesn't upload a changed tabs record frequently enough

Status: RESOLVED WONTFIX

(Firefox :: Sync, defect)

Description

[Edwin Wong [:edwong]]

This was brought up in a email thread. The sync team would like the specific steps to repro so we can evaluate technical solutions.

Comment 1

[Edwin Wong [:edwong]]

:potch - can you add your steps to repro when seeing laggy or slow sync performance on Fx for iOS

Comment 2

[Richard Newman [:rnewman]]

I don't think we need STR; we understand what's happening here.

From my largest post on the iOS list:

---
Desktop clients themselves should sync every five minutes.

Whether they decide to sync tabs at that moment is based on whether anything changed. It usually has: in practice, my own profile's success logs show that out of 1775 syncs, 1061 uploaded a tabs record and 714 did not. Most of those 714 will be sync-on-wake, Sync Now, or syncs caused by bookmarking.

Whether to sync more frequently than the timed intervals is decided by the sum of every engine's tracker's score at the time. Tabs is:

    // For page shows, bump the score 10% of the time, emulating a partial
    // score. We don't want to sync too frequently. For all other page
    // events, always bump the score.
    if (event.type != "pageshow" || Math.random() < .1) {
      this.score += SCORE_INCREMENT_SMALL;
    }

The bump is SMALL, which is 1, and we bump that on 10% of page loads and on every tab open, close, or switch event.

The multi-device sync threshold is 300.

In the absence of any other user activity — visiting history URLs (SMALL), deleting history (XLARGE), bookmarking a page (XLARGE), adding a password, etc. — that means you need to do some combination of switching, opening, closing, or navigating within tabs 300 times to trigger a sync solely via browsing.

Realistically that means we never trigger a sync specifically due to browsing behavior for multi-device clients: you simply can't do enough in 5 minutes without bookmarking or saving a password to hit the score threshold.

So: we'll upload a changed tabs record if you've browsed since we last synced, and if you take some significant action, or otherwise wait five minutes.

What Potch is seeing is:

* T=0: sync!
* Four minutes of browsing, but no bookmarking or saving of new passwords.
* T=4: close laptop.
* T=10: pull out phone. Pull to refresh. You see tabs from T=0.
---

---
> > Agreed, although it may be simpler to just sync everything more eagerly,
> > IIRC tabs are among the most churny of datatypes anyway.
> 
> It seems logical tabs are the most churny data type , so cleverness
> about updating one out of 20 tabs as opposed to brute force/rewrite
> the whole record might not help too much. I think this is a case 
> where the data type might just require special treatment. 

I think some users have few tabs open, and those tabs are churny. Those users aren't the problem: their whole set of open tabs changes frequently, because the set is very small, and the set is small so the overall impact is low.

Other users have lots of tabs open and they throw them away often: habitual Reddit consumers, for example. Those users are hard to help: their data really does churn frequently, but we can definitely get wins by frequently uploading small changes instead of frequently uploading everything.

Other users have lots of tabs open for protracted periods of time: minutes to months. There are lots of reasons for this: students trawling wikipedia, folks middle-clicking image galleries, developers, pinned tab users, tab hoarders (who use open tabs instead of bookmarks).

These users both have low churn and large record payloads, so the win is large — I'd guess that 95% or more of my tab upload is the same as in the previous sync, and that's pure waste.

Cleverness updating one tab of three isn't all that worthwhile. Cleverness in updating one tab in rapidly changing 20, or 50, or 300 is worthwhile. Cleverness in updating one tab in 100 tabs that you keep open for months and months (thousands of syncs)? Totally worth it.
 
There's a lot we can do to improve functionality and efficiency if we're willing to change the tabs record format. There's even more we can do, particularly around responsiveness, if we're willing to build a new service rather than to use Sync… but of course the investment required is much larger.


> Elsewhere Firefox Mobile is prioritizing a Send Tab feature
> to make this explicit, underlining that users think of
> Tabs as  something they need more immediately than a Bookmark
> or History item. 

Yup, and that's a case where push becomes very valuable. Send tab already works quite well from mobile to desktop if you keep your laptop asleep, but there are lots of rough edges if you stray from that.

I don't think that send tab is really a substitute for good tab sync, though: personal experience and discussions with UX suggest that the use cases are pretty disjoint, whether because sent tabs on mobile often come from other apps rather than inside the browser, or just because tab sync tends to be used in situations where you didn't plan to need that page.
---

Comment 3

[Richard Newman [:rnewman]]

Bullet-point takeaways:

* It's really hard to decide when to update the current Sync tabs record, because there's no good balance between efficiency, privacy, and timeliness. Making this better requires a new format and/or a new service.  Myself, mfinkle, and some of my UX and product co-conspirators have been thinking for a while about paradigms that alter this dynamic, but doing better on top of Sync is hard.

* Syncs almost never happen when you want them to. Doing better requires push *and* some careful thought; myself, markh, and rfkelly are probably the right people to do that thinking.

Comment 4

[Richard Newman [:rnewman]]

Mark, Chris: I think there are three tiers of solutions to this:

1. Stopgap: make desktop sync tabs (or everything else) more frequently. That trades perf, network usage, server resources for improved timeliness. We could just change the timer, or we could figure out some event (new tab?) that bumps score more, or something else.

2. Intermediate: define a 'tabs2' collection or a new version of the 'tabs' format with a better schema (see my paragraphs beginning "Cleverness" in Comment 2). This requires implementation on three platforms, as well as some way to roll over between them.

3. Best/hardest/least well-defined: proper task continuity (what me and mfinkle have been calling "Queue" or "tabs in the cloud").

I propose that this bug is #1, and we can file a new bug blocking Bug 745408 if you want to do #2.

Do you want to prioritize this one or WONTFIX it?

WONTFIX makes some sense to me because no matter what we do, we will never be timely enough; even if we dump all of your tabs into JSON and upload them every 60 seconds, we'll still have users close their laptops and wonder why their phone doesn't show what they did 30 seconds ago.

We can't feasibly stream your full tab snapshot every time you navigate, so I wonder if this is worth tweaking at all.

Comment 5

[Ryan Kelly [:rfkelly]]

> Desktop doesn't upload a changed tabs record frequently enough

Is it specifically Desktop's behaviour that we're worried about, or is it all devices in general and Potch was reporting Desktop as a special case?

Anyway, before we do anything about option (1), we should find a way to determine what "frequently enough" means for users.  ISTM that a good proxy for the occurrence of this bug is something like "user clicks 'Sync Now' from within a tabs-from-other-devices view", but I don't know if we have any telemetry around that.

Comment 6

[Mark Hammond [:markh] [:mhammond]]

I honestly don't have a feel for how "expensive" sync is for an average (ha!) user. It seems largely invisible on my main profiles, so I doubt I'd notice if it synced every minute (apart from the spinning UI going off more often!). The typical sync seems to take ~1s for me. But I'm always on fast machines with good internet - and as you say, I bet users looking for remote tabs often use the feature *exactly because* they just closed their laptop, so it's just a bigger band-aid. OTOH, the 5-minute interval was really just a judgement call - there's nothing wrong with making a new one ;) Say 2.5 minutes - a trivial change and at least *some* ppl might see improvement.

> or we could figure out some event (new tab?)

That would miss simple navigation in the same tab - catching "everything" would likely be a high-volume but bursty stream. It would be interesting find out - the "how much tab data" is something we need to know for any longer term work anyway.

> 2. Intermediate: ... requires implementation on three platforms, as well 
> as some way to roll over between them.

Yep - not going to happen for a number of months I expect.


> 3. Best/hardest/least well-defined: proper task continuity (what me and
> mfinkle have been calling "Queue" or "tabs in the cloud").

Yep - I think that's what we should do instead of (2) :)

> We can't feasibly stream your full tab snapshot every time you navigate, so
> I wonder if this is worth tweaking at all.

I don't feel strongly, but I also don't see why 5 minutes is any more magic than 2.5 minutes is, and the latter is obviously 1/2 as - err - bad? :)

Comment 7

[Chris Karlof [:ckarlof]]

In support of rfk's point, I feel the inputs to help us determine the most impactful way to improve synced tab performance are poor. If we some knowledge/research/data that informs us how typical users are using synced tabs, someone please add it here. 

"tab sync tends to be used in situations where you didn't plan to need that page" is an opinion that I find affinity with. For situations where a user "needs this tab there, now", we're competing with "email self a link", and that's some stiff competition wrt simplicity, availability, reliability, and transparency.

On a positive note, "Activity Steam" and "Search" are likely two top line initiatives for the Firefox org year, and I expect tab sync in general is an issue that'll re-surface then.

Comment 8

[Richard Newman [:rnewman]]

(In reply to Ryan Kelly [:rfkelly] from comment #5)
> Is it specifically Desktop's behaviour that we're worried about, or is it
> all devices in general and Potch was reporting Desktop as a special case?

All devices, but desktop has particular disadvantages:

* Android can sync while you're not using it, including while the device is asleep, and does so. That doesn't help with the immediately-switch-devices case, but it definitely helps with common delayed scenarios.

* Mobile devices are typically in your pocket, so there's a recovery strategy. Your laptop is in your bag, or on your office desk…


(In reply to Chris Karlof [:ckarlof] from comment #7)
> In support of rfk's point, I feel the inputs to help us determine the most
> impactful way to improve synced tab performance are poor. If we some
> knowledge/research/data that informs us how typical users are using synced
> tabs, someone please add it here. 

I think we have some problems here, in that we have a rusty solution that won't have have captured a population big enough to draw good conclusions, but I bet Gemma has decent insights nonetheless.


(In reply to Mark Hammond [:markh] from comment #6)
> But I'm always on fast machines with good internet…

Aye. Run Firefox off a USB key or over a satellite link from the south of France and you might hate Sync even more :D



> I don't feel strongly, but I also don't see why 5 minutes is any more magic
> than 2.5 minutes is, and the latter is obviously 1/2 as - err - bad? :)

If we're in a failure state, halving the interval will double the amount of redundant work and bandwidth usage. See, for example, Bug 969252.

Phrased differently: the confidence to go faster comes from reliability. That's why I'm leery of making a change without having a good amount of confidence in the benefits.