Closed Bug 1103361 Opened 10 years ago Closed 10 years ago

Start/stop sync tracker when engine is enabled/disabled by flipping the pref

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: hectorz, Assigned: hectorz)

References

Details

Attachments

(1 file, 2 obsolete files)

+++ This bug was initially created as a clone of Bug #947772 +++

In bug 947772, |onEngineEnabledChanged| of a sync tracker will only be called if the corresponding sync engine is enabled/disabled by setting its |enabled| property, not when the underlying pref is flipped.
Attached patch Patch (obsolete) — Splinter Review
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a7567d90b5bd
Assignee: nobody → bzhao
Status: NEW → ASSIGNED
Attachment #8527182 - Flags: review?(rnewman)
I'm not sure why this is necessary. Sync always calls through .enabled when changing state. Could you explain?
Flags: needinfo?(bzhao)
(In reply to Richard Newman [:rnewman] from comment #2)
> I'm not sure why this is necessary. Sync always calls through .enabled when
> changing state. Could you explain?

I think toggling an engine/item in sync pane of preferences doesn't go through .enabled.

STR:
1. Start Fx with prefs engine enabled;
2. Uncheck the prefs engine in preferences;
3. |Weave.Service.engineManager.get("prefs").enabled| is false;
4. |Weave.Service.engineManager.get("prefs")._tracker._isTracking| is true.
Flags: needinfo?(bzhao)
Comment on attachment 8527182 [details] [diff] [review]
Patch

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

Reasoning behind moving this to the tracker: the tracker is already watching for this kind of thing, and the thing we want to poke is in the tracker.

::: services/sync/modules/engines.js
@@ +645,5 @@
>      this.__defineGetter__("_tracker", function() tracker);
>      return tracker;
>    },
>  
> +  observe: function(subject, topic, data) {

Each of the trackers already observes, so I think what you want to do is add a line like:

  Svc.Prefs.observe("engine". + this.name, this);

to the Tracker constructor, and then move the new logic here to the existing observe handler in Tracker.

@@ +648,5 @@
>  
> +  observe: function(subject, topic, data) {
> +    switch (topic) {
> +      case "nsPref:changed":
> +        let engine = data.slice((PREFS_BRANCH + "engine.").length);

This isn't right. I think you want (inside the tracker):

  if (data == PREFS_BRANCH + "engine." + this.name) {
    this.onEngineEnabledChanged(...);
  }
Attachment #8527182 - Flags: review?(rnewman) → feedback+
Attached patch Patch, moved to tracker (obsolete) — Splinter Review
(In reply to Richard Newman [:rnewman] from comment #4)
> Each of the trackers already observes, so I think what you want to do is add
> a line like:
> 
>   Svc.Prefs.observe("engine". + this.name, this);
> 
> to the Tracker constructor, and then move the new logic here to the existing
> observe handler in Tracker.
Done.
> 
> This isn't right. I think you want (inside the tracker):
> 
>   if (data == PREFS_BRANCH + "engine." + this.name) {
>     this.onEngineEnabledChanged(...);
>   }
Fixed.
Attachment #8527182 - Attachment is obsolete: true
Attachment #8534136 - Flags: review?(rnewman)
Comment on attachment 8534136 [details] [diff] [review]
Patch, moved to tracker

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

Looks good! Please make sure you've tested this thoroughly before landing.

::: services/sync/modules/engines.js
@@ +53,5 @@
>    this.loadChangedIDs();
>  
>    Svc.Obs.add("weave:engine:start-tracking", this);
>    Svc.Obs.add("weave:engine:stop-tracking", this);
> +  

Nit: trailing whitespace.
Attachment #8534136 - Flags: review?(rnewman) → review+
(In reply to Richard Newman [:rnewman] from comment #6)
> 
> Looks good! Please make sure you've tested this thoroughly before landing.
Sorry but I'm not quite sure what kind of tests are considered thorough, could you be more specific? Should I run more tests (other than xpcshell) on try, like tps tests? Or should I manually confirm a try build works as expected? Thanks.
> 
> Nit: trailing whitespace.
Removed. Carrying over r+.
Attachment #8534136 - Attachment is obsolete: true
Attachment #8534959 - Flags: review+
Mostly looking for smoke tests: run the build locally, and make sure that changes are tracked when turned on, not tracked when turned off, recovered and tracked again when turned back on.
(In reply to Richard Newman [:rnewman] from comment #8)
> Mostly looking for smoke tests: run the build locally, and make sure that
> changes are tracked when turned on, not tracked when turned off, recovered
> and tracked again when turned back on.

Thanks for the clarification. Will do before requesting checkin.
(In reply to Richard Newman [:rnewman] from comment #8)
> Mostly looking for smoke tests: run the build locally, and make sure that
> changes are tracked when turned on, not tracked when turned off, recovered
> and tracked again when turned back on.

I tested the try build (w/o the whitespace fix) and it works as expected.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=b0f4f21987a1
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/9772a3da28b8
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/9772a3da28b8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla37
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: