Open
Bug 1215714
Opened 9 years ago
Updated 10 months ago
Use Session Data for Sync Tabs
Categories
(Firefox :: Sync, enhancement, P5)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
People
(Reporter: wmaggs, Unassigned)
References
(Blocks 1 open bug)
Details
Currently when Sync Tabs are chosen in Tabs from My Other Devices (as it soon will be in the hamburger menu and in a new Sync Tabs sidebar), tab URL is loaded only. This is true despite the fact that Sync apparently syncs all the session data for the tab (in some places called the tab context), which includes all the information used to restore recently closed tabs, including form data, scroll position, storage, pinned state, and presumably permissions and other site-specific settings.
Providing the user the same restore experience for a remote tab as they get for a recently closed local tab would be fantastic.
Updated•9 years ago
|
Flags: firefox-backlog+
Priority: -- → P2
Comment 1•9 years ago
|
||
We don't sync any of that stuff, so using it is harder than it sounds!
We sync this:
title: current.title || "",
urlHistory: urls,
icon: tabState.attributes && tabState.attributes.image || "",
lastUsed: Math.floor((tabState.lastAccessed || 0) / 1000),
Just the title, current back stack, icon URL, and an access time.
There are lots of reasons why.
1. The full tab context is not a version- or platform-independent format, and Sync is a version- and platform-independent system. Shuffling chunks of session store JS around is a recipe for pain.
2. Things like storage and cookies are very hard to get right across devices (Weave used to sync cookies, and stopped for a good reason), and imply a shift to a more sophisticated browser-in-the-cloud style of model. This would be almost building sync-within-sync without knowledge of a site's data model. Yikes.
3. Even simple stuff is hard to get right: what does scroll position mean when you shift between a phone and a laptop?
4. Some of the rest need thought. For example, if we shuffle site permissions through this channel, we'll end up with some local tabs for a domain having one set of permissions and others having another -- e.g., one Google Maps tab from your phone will be able to get your location, and another won't. That's a hard experience to message. If not that, then we're really talking about syncing each of these things (e.g., Bug 470699).
5. Finally, there's a size concern here. We upload this entire record, including every tab, every time we sync. And the other clients need to download it. Adding potentially KB of data to each tab can really add up, and puts us closer to exceeding the max size of a Sync record, after which tab sync will break completely.
If we want to keep this bug open, someone needs to walk through the available data and figure out which of it is stable and makes sense to sync, and then come up with a concrete platform-independent representation that the session store code can parse.
I'm hoping that I'll have time next year to move forward on some ideas that run at a tangent to this, but that's not a short-term fix.
Comment 2•9 years ago
|
||
> I'm hoping that I'll have time next year to move forward on some ideas that run at a tangent to this
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
Updated•9 years ago
|
Priority: P2 → P3
Updated•8 years ago
|
Severity: normal → enhancement
Priority: P3 → --
Updated•6 years ago
|
Priority: -- → P3
Updated•5 years ago
|
Priority: P3 → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•