On 6/13/17 2:05 PM, Ryan Kelly wrote:
On 13 June 2017 at 12:22, Richard Newman <[email protected]
<mailto:[email protected]>> wrote:
Bear in mind that we have 'declined' in meta/global, which is
intended to support exactly this scenario.
A user signing up on Android or iOS can upload a meta/global without
"payments" (or whatever), but it also won't be in 'declined'.
Desktop can use that hook — a locally supported engine that's
neither remotely enabled nor remotely declined — to offer the new
data type at the appropriate time.
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?
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.
1) We always offer these new engines in anticipation of the user
eventually using a version of Firefox that supports them. The main
issue
with this is that it may cause confusion for the user - for example, if
they create an account on Android, they may be confused when they can't
find the addresses/credit-card feature on that platform. Similarly for
users who happen to sign up on, say, Firefox ESR (which presumably will
not get this support until the next ESR release).
To be sure I understand what's proposed here:
* FxA always shows the new options in the choose-what-to-sync screen,
defaulting them to unselected
I believe the intent is to default them as selected. Note that the user
may or may not have opted in to the local feature at this point. This is
much like "passwords", where the user may be presented with the option
to sync passwords, with the default being true, even though they may not
yet have opted in to actually saving passwords locally (or even may have
explicitly disabled the feature in about:prefs)
* If the user does not select the new datatypes, then we include them in
"declinedSyncEngines" when we message login state to the browser, and:
* New browsers that support the feature, will know not to sync it,
and will write it declined engines list on the server
Given it will default to enabled, this will be the case if the user
de-selects it - but yeah.
* 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?)
* If the user does select the new datatypes, then they don't show up in
"declinedSyncEngines", and:
* New browsers that support the feature will turn on syncing of
those types, writing them explicitly into /meta/global on the server
* But old browsers that don't support the feature will not do
anything different
There's a little bit of handwaving here, as the local preferences for
these engines will need to default to disabled, so when existing Sync
users get an upgraded Firefox with support for these engines they will
not be automatically enabled. Thus, it's probably not strictly necessary
for these engines to end up in declined (even though they will), but
probably *is* necessary for Desktop to be confident that an engine was
actually *offered*, so the local preference for the engine is changed
from its default disabled state to enabled.
IOW, the webchannel handling code at
http://searchfox.org/mozilla-central/source/services/fxaccounts/FxAccountsWebChannel.jsm#283
will need to get smarter - it currently only explicitly disables
engines, but will need to change to explicitly enable engines we know
were offered but were not declined.
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"?
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 :/
Cheers,
Mark
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
