On 14 June 2017 at 02:11, Richard Newman <rnew...@mozilla.com> wrote:
> * 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 >> >> >> >> Desktop does this, but TBH I'm not quite sure what Android does (and >> IIUC, iOS doesn't even offer these choices?) >> > > All Sync 1.5 clients will preserve the declined list. > > >> 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? >>> >> >> 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. >> >> 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"? >> > > On iOS we default to enabling *desktop* engines that we don't sync > <https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L24>, > unless the user declined them — they're mentioned in the copy, so we go > ahead and turn them on. > > We're establishing/following the guideline that absence from both > `engines` and `declined` means that the creating device didn't know about > that engine. > > I'd suggest that we shouldn't present options to a user without writing > them into one of the two places, even if we write with version=0 > <https://github.com/mozilla-mobile/firefox-ios/blob/master/Sync/SyncStateMachine.swift#L47> > and upload no data, which is essentially an enablement placeholder. > This makes sense to me, although it's worth calling out explicitly that it adds a dependency on client changes in Android and iOS, to ensure they preserve this new piece of information. > 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. > > 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). > > >From the FxA side, I assume this would just look like a new "acceptedSyncEngines" field in the fxa:login message, matching the current "declinedSyncEngines" field and providing the list of engines that were explicitly accepted. That seems straightforward at first glance, assuming older clients won't blow up when they encounter an unexpected field on that message... Ryan
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
