Open
Bug 1156075
Opened 10 years ago
Updated 3 years ago
Message when tab sync has been remotely disabled
Categories
(Firefox for iOS :: Sync, defect)
Tracking
()
NEW
People
(Reporter: rnewman, Unassigned)
References
Details
When we support datatype elections on iOS, we'll be doing per-device choices. That leads to its own problems with meta/global.
But until then, we have to handle a meta/global with no "tabs" entry -- i.e., the user has turned off tab sync, and that's why we'll (fail|null-succeed) to fetch any.
In the short term we could treat this simply as "No tabs from other devices" -- i.e., synced successfully, but no tabs. IIRC we have assets for this in Bug 1144760.
If there's small-print, we could do better, explaining *why*. There's probably a decent-sized set of users who turned off tab sync in the single-device case, and now have a reason to turn it on.
Reporter | ||
Updated•10 years ago
|
Summary: Handle tab sync being disabled remotely → Handle tab sync being remotely disabled
Comment 1•10 years ago
|
||
Given kar's support for shipping iOS v1 without being able to configure the set of synced datatypes, this becomes relatively more important. See also Bug 1139038 and Bug 1139045.
Summary: Handle tab sync being remotely disabled → Message when tab sync has been remotely disabled
Reporter | ||
Comment 2•10 years ago
|
||
After Bug 1167824 this will be due to one of two things:
* A FatalError raised from ClientsSynchronizer. This is not common.
* An EngineNotEnabledError raised from TabsSynchronizer.
Depends on: 1167824
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•