Trigger a delayed sync after pairing a new device

VERIFIED FIXED in Firefox 8

Status

Cloud Services
Firefox Sync: Backend
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: philikon, Assigned: philikon)

Tracking

({verified-aurora, verified-beta})

unspecified
mozilla10
verified-aurora, verified-beta
Points:
---

Firefox Tracking Flags

(firefox8 fixed, firefox9 fixed)

Details

(Whiteboard: [verified in services])

Attachments

(1 attachment, 1 obsolete attachment)

When you add a new device it'd be good to trigger a sync after a little while (having given the new client enough time to sync down and up).
Possible interaction with Bug 675824, which involves monitoring sync status on the other device to know when to start syncing and showing progress.

Might split out the shared work into a "credential exchange progress notification channel" bug...?
(In reply to Richard Newman [:rnewman] from comment #1)
> Possible interaction with Bug 675824, which involves monitoring sync status
> on the other device to know when to start syncing and showing progress.

Aye.

> Might split out the shared work into a "credential exchange progress
> notification channel" bug...?

Pretty sure this will also need an AbstractSingletonProxyFactoryBean.
(In reply to Philipp von Weitershausen [:philikon] from comment #2)

> Pretty sure this will also need an AbstractSingletonProxyFactoryBean.

…ControllerImpl.
(Assignee)

Updated

6 years ago
Assignee: nobody → philipp
My crude implementation just schedules another Sync for activeDeviceInterval after a successful exchange. I think that's sufficiently simple yet effective.
Created attachment 563591 [details] [diff] [review]
v1

Part of this is based on the SendCredentialsController introduced in bug 675823.
Attachment #563591 - Flags: review?(rnewman)
Comment on attachment 563591 [details] [diff] [review]
v1

Review of attachment 563591 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/syncAddDevice.js
@@ +123,5 @@
>          delete self._jpakeclient;
>          self.wizard.pageIndex = DEVICE_CONNECTED_PAGE;
> +
> +        // Schedule a Sync for soonish to fetch the data uploaded by the
> +        // device we just paired with.

I would prefer "to fetch the data uploaded by the device with which we just paired", but then I'm a grammar nazi.
Attachment #563591 - Flags: review?(rnewman) → review+
Created attachment 564006 [details] [diff] [review]
v2

Addresses nit and also adds a test.
Attachment #563591 - Attachment is obsolete: true
https://hg.mozilla.org/services/services-central/rev/c44a046d72b4
Status: NEW → ASSIGNED
Whiteboard: [fixed in services]
STRs for QA:

* Pair a new device (A) with an already Sync-connected device (B)
* B should trigger a Sync with the "active interval" (by default 5 minutes), regardless of what its regular interval would be (could be 24h or 1h if it was the only device up until then.)
Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111003 Firefox/10.0a1
BuildID: 20111003153830

Connected a new device (A) to a device that already had Sync configured (B); a sync was performed in B after about 1-2 minutes.
Whiteboard: [fixed in services] → [verified in services]
(In reply to Mihaela Velimiroviciu [QA] from comment #10)
> Connected a new device (A) to a device that already had Sync configured (B);
> a sync was performed in B after about 1-2 minutes.

Was B the only device connected to the account? Because B should wait for about 5 minutes before syncing again, so if it syncs earlier than that, something else is going on.
So far, what I've seen is a sync is fired immediately.  That sets the interval to singleDevice 3600.  But it actually fires a sync five minutes later. I'm still investigating.

 
I also saw something bad adding an XP client to account. trying to reproduce it.
(In reply to Tracy Walker [:tracy] from comment #12)
> So far, what I've seen is a sync is fired immediately.

Do you mean bug 688520 or is it actually kicking off a sync immediately after the pairing?
Ah yes, that's what it is.  nevermind.

I'm also not able to reproduce the issue on XP I was looking into.  I think it may have been miss timing of account deletion and recycling.  everything is fine with clean accounts
https://hg.mozilla.org/mozilla-central/rev/c44a046d72b4
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Updated

6 years ago
Blocks: 687316
This bug essentially makes bringing back heartbeats (bug 693758) superfluous. It is a much smaller patch, has less risk, and avoids many unnecessary network requests. I am therefore nominating this instead of bug 693758 to go into Aurora and Beta to avoid poor user experience introduced by increasing the sync intervals (bug 694149).
status-firefox8: --- → affected
status-firefox9: --- → affected
tracking-firefox8: --- → ?
tracking-firefox9: --- → ?
Comment on attachment 564006 [details] [diff] [review]
v2

Nominating this patch for Aurora and Beta. Please see comment 16 for justification.
Attachment #564006 - Flags: approval-mozilla-beta?
Attachment #564006 - Flags: approval-mozilla-aurora?

Updated

6 years ago
Attachment #564006 - Flags: approval-mozilla-beta?
Attachment #564006 - Flags: approval-mozilla-beta+
Attachment #564006 - Flags: approval-mozilla-aurora?
Attachment #564006 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/32fc4eb5feec
status-firefox9: affected → fixed
https://hg.mozilla.org/releases/mozilla-beta/rev/e31583927cd7
status-firefox8: affected → fixed
tracking-firefox8: ? → ---
tracking-firefox9: ? → ---
No longer blocks: 687316
verified across channels

note to self:  watch value of services.sync.nextSync to verify this.  (don't look for a log)
Status: RESOLVED → VERIFIED
Keywords: verified-aurora, verified-beta
You need to log in before you can comment on or make changes to this bug.