1262797 - When device changes, services.sync.client.GUID should (ask to) be re-generated

Status: RESOLVED DUPLICATE of bug 1234181

(Firefox :: Sync, defect)

Description

[Raphael Schweikert]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

I restored my mac from the time-machine backup of another mac. I’ve kept using both macs after that.

I’d noticed that about:sync-tabs stopped working but didn’t think it was related. Also about:sync-tabs was introduced with cloudsync so I thought maybe it just wasn’t supported with Weave. Other things like bookmarks, prefs, addons and the like were syncing fine.
Only when also the new synced tabs panel appeared with a recent version of Firefox (45, I think) and still didn’t work did I start to worry.
I run my own sync 1.5 (weave) server and went on to file a ticket with their implementation saying syncing tabs wasn’t working but not before I started debugging the issue by myself.

That’s when I figured out that the synced tabs were discarded in https://dxr.mozilla.org/mozilla-central/rev/68c0b7d6f16ce5bb023e08050102b5f2fe4aacd8/services/sync/modules/engines/tabs.js#119 because the synced id matched the services.sync.client.GUID pref, which has never changed from the time I’d first restored the machine.

Steps to reproduce:

1. Log into Weave.
2. Duplicate the profile folder (onto a new machine).
3. Start both profiles and open a few tabs in each.
4. Expect about:sync-tabs to show the open tabs from the other profile after sync.


Actual results:

about:sync-tabs remains empty.


Expected results:

Firefox should have noticed the machine has changed/the profile has moved and offered to re-generate the sync GUID. 

Many OS have means of getting an identifier of the current machine and the location of the profile folder should also be known. If either has changed since the last sync, the GUID should be re-generated, or at least the user should be asked whether the profile had been moved or copied (similar to what VMWare asks when opening a moved/copied VM: https://kb.vmware.com/kb/1541).

Note that this solution would be a problem for users of Firefox portable where both the machine and the the path to the profile folder regularly change but I think this could be mitigated by an additional pref (or is there one already?) that marks this profile as portable and, if set to true, would make sure the GUID never changes.

Comment 1

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

Thanks - this is already tracked in bug 1234181