<div dir="ltr"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's not obvious to me when that "appropriate time" would be though; do users who miss seeing the option during signup have to discover it by going into their sync preferences, or are we considering some sort of in-product messaging to advertise it?</blockquote></span><span class=""><br></span>
I believe the intention is that when a doorhanger is shown for the user to opt-in to the feature itself (ie, to storing address/credit-card information locally), there will be an additional checkbox shown for sync users where they can also opt-in to syncing the data.<span class=""><br></span></blockquote><div><br></div><div>The original case envisioned for tracking declined was that a device can choose to show a doorhanger at the granularity of the individual sync, typically on a first or second sync of a capable device, or when a feature is first added to the browser for existing users.</div><div><br></div><div>If you're an existing autofill user on desktop, and you sign up for FxA on your iOS device, then when you sign in on your desktop and we begin syncing we can say "Do you want to sync your autofill data?"</div><div><br></div><div>If you're using an older version of Firefox and upgrade, we can see that we're now able to sync autofill, and offer it to the user during their first sync after restarting, or at any later date.<br></div><div><br></div><div>At the moment of syncing we also know which devices you use, and we enhanced the client record format in part to allow better decision making around this sort of thing, so we could e.g., only offer to turn on syncing if you have another desktop of a version that can use the data, and prompt accordingly: "Do you want to sync your autofill data to Firefox on Richard's iMac? You can change your mind later in Preferences.".<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">   * Old browsers that do not support the feature, will write the new values into declined engines list on the server without understanding what it is</blockquote></span><br><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></span><span class="">
<br></span>
Desktop does this, but TBH I'm not quite sure what Android does (and IIUC, iOS doesn't even offer these choices?)<span class=""><br></span></blockquote><div><br></div><div>All Sync 1.5 clients will preserve the declined list.<br></div><div> <span class=""></span><br><span class="">
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is that accurate?  If a user opts-in to the new datatypes when signing up on Android, and then signs in on their desktop device, how does the new device know to respect the user's original opt-in?<br>
</blockquote>
<br></span>
hrm - that's a good point. When Desktop signs in it can look in "declined", but the lack of the new engine there could mean either (a) user was presented with the option and accepted the engine or (b) user created the account before the engine was first offered.<br>
<br>
Bugger. I'll need to think about this some more and welcome all other thoughts. Richard, do you have any here? Maybe we should also write "accepted"?<br></blockquote><div><br></div><div>On iOS <a href="https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L24">we default to enabling <i>desktop</i> engines that we don't sync</a>, unless the user declined them — they're mentioned in the copy, so we go ahead and turn them on. <br></div><div><br></div><div>We're establishing/following the guideline that absence from both `engines` and `declined` means that the creating device didn't know about that engine.</div><div><br></div><div>I'd suggest that we shouldn't present options to a user without writing them into one of the two places, <a href="https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L47">even if we write with version=0</a> and upload no data, which is essentially an enablement placeholder.</div><div><br></div><div>I think that rule eliminates the ambiguity, no? Present in declined = user said no; present in engines = user said yes; not present = user didn't make a choice.</div><div><br></div><div>From the dialogs above, "Yes" would write to engines, "No" would write to declined, and dismissing the dialog would take no action (perhaps writing a pref to avoid reprompting too soon).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

In the mean time though, it would still be interesting to know what the UX *preference* is for this, even if it turns out we might need to adjust that to suit reality :/</blockquote><div><br></div><div>Quite!<br></div></div>