<div dir="ltr">+ Nicole Yee<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 5, 2018 at 5:03 PM, Mark Hammond <span dir="ltr"><<a href="mailto:mhammond@mozilla.com" target="_blank">mhammond@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard does raise some other points not covered in bug 1419505. I just opened bug 1435917 (blocking bug 1415385) for this.<br>
<br>
Thanks,<br>
<br>
Mark<span class=""><br>
<br>
On 6/02/2018 10:05 am, Dave Townsend wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I think we have the sync case covered in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419505" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/s<wbr>how_bug.cgi?id=1419505</a><br>
<br></span><span class="">
On Mon, Feb 5, 2018 at 3:04 PM Richard Newman <<a href="mailto:rnewman@mozilla.com" target="_blank">rnewman@mozilla.com</a> <mailto:<a href="mailto:rnewman@mozilla.com" target="_blank">rnewman@mozilla.com</a>>> wrote:<br>
<br>
As we briefly discussed some months ago, this will cause Sync<br>
devices to collide: you'll have two profiles that both believe<br>
they're FxA device 12345 and Sync client abcdef.<br>
<br>
Avoiding this should be possible by allocating a new Sync client ID,<br>
forcing the clients collection to need a sync (lastSync = 0), and<br>
doing something similar with FxA device registration. This could<br>
potentially require the user to re-enter their FxA password, but I'm<br>
not sure.<br>
<br>
Dropping fx-data-dev, CCing FxA and Sync to discuss.<br>
<br>
On Mon, Feb 5, 2018 at 2:45 PM, Dave Townsend <<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a><br></span><span class="">
<mailto:<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>><wbr>> wrote:<br>
<br>
A new feature we are targetting for Firefox 60 involves giving<br>
each release channel a separate profile by default. In order to<br>
push users into this situation on upgrade non-release channels<br>
will make a clone of the release profile for use going forwards.<br>
Currently this is a complete copy of all files and settings from<br>
the release profile which raises a couple of immediate potential<br>
issues:<br>
<br>
The value of toolkit.telemetry.cachedClient<wbr>ID will be shared<br>
across potentially many profiles. I could probably regenerate<br>
this for each cloned profile if there is a procedure for doing this.<br>
<br>
Any unsent pings will be cloned and so may be sent as<br>
duplications. The only way to avoid this would be to not clone<br>
the ping but that might mean that those pings are never sent.<br>
I'm not sure which is preferable.<br>
<br>
Any other issues I'm not considering?<br>
<br>
______________________________<wbr>_________________<br>
Fx-data-dev mailing list<br></span>
<a href="mailto:Fx-data-dev@mozilla.org" target="_blank">Fx-data-dev@mozilla.org</a> <mailto:<a href="mailto:Fx-data-dev@mozilla.org" target="_blank">Fx-data-dev@mozilla.or<wbr>g</a>><br>
<a href="https://mail.mozilla.org/listinfo/fx-data-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/fx-data-dev</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Sync-dev mailing list<br>
<a href="mailto:Sync-dev@mozilla.org" target="_blank">Sync-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/sync-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/sync-dev</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Dev-fxacct mailing list<br>
<a href="mailto:Dev-fxacct@mozilla.org" target="_blank">Dev-fxacct@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/dev-fxacct</a><br>
</blockquote></div><br></div>