"Choose what to Sync" for autofill

[Mark Hammond]

[Sorry for the large cross-post, and I'm explicitly CCing Ryan and Juwei
as I'm not sure what lists they are on, and this is really a decision
for them]

When a user creates a sync account, the list of available sync engines
(aka "choose what do sync") is hosted on the Firefox Accounts server.
While it seems obvious that a version of Desktop Firefox which supports
addresses/credit-cards should be offered these engines, it's not clear
what should happen for other devices. I see 2 options:

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).

2) We only offer these engines on a platform that supports the feature -
this means that the user will see different options depending on what
device they use to create this account. The main issue with this
approach is that the user who creates an account on (say) Android will
find that these engines are disabled when they connect a Desktop device
to their account, meaning they will need to go through an additional
"opt-in" process for syncing this data on desktop - just like existing
Sync users will need to.

(1) would almost certainly make the engineering work easier, and given
it avoids additional opt-in UI later, is probably more seamless from a
UX perspective. It probably makes documentation etc easier too - it's
basically the same signup experience regardless of what platform you
use. However, I can also see that (2) has benefits.

So - what shall we do? Can we live with (1)?

Cheers,

Mark

[Richard Newman]

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.

Happy to explain in more detail if folks have no idea what I'm talking about.

-R

---

From: Sync-dev <sync-dev...@mozilla.org> on behalf of Mark Hammond <mham...@mozilla.com>
Sent: Monday, June 12, 2017 5:30:10 PM
To: sync...@mozilla.org; dev-f...@mozilla.org; auto...@lists.mozilla.org; Juwei Huang; Ryan Feeley
Subject: "Choose what to Sync" for autofill

 

_______________________________________________
Sync-dev mailing list
Sync...@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev

[Mark Hammond]

On 6/13/17 12:22 PM, Richard Newman 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.

Yes, thanks Richard, that's exactly what we'd use. Part of the
complexity involves the client indicating to the FxA server what it
should show, and part of the "user complexity" is that the engines they
are offered will depend on what device they *first* use, so not only is
that first choice difficult to document with (eg) a screenshot, the
experience that new user has when on desktop is different depending on
where they created the account.

So it's not so much that "(2) is far more complex from an engineering
POV", it's more "(1) is slightly easier from an engineering POV and
offers a more consistent signup process, at the cost of offering an
engine the device doesn't yet support".

(And just to muddy the waters even more, bug 1360359 intends landing a
"round-tripping" autofill engine on Android, so Android *will* support
the engine but *will not* support the underlying feature - which is
another reason I'm leaning towards (1) - it seems to keep things
conceptually simpler)

Cheers,

Mark

>
> Happy to explain in more detail if folks have no idea what I'm talking
> about.
>
> -R

> ------------------------------------------------------------------------
> *From:* Sync-dev <sync-dev...@mozilla.org> on behalf of Mark
> Hammond <mham...@mozilla.com>
> *Sent:* Monday, June 12, 2017 5:30:10 PM
> *To:* sync...@mozilla.org; dev-f...@mozilla.org;

> auto...@lists.mozilla.org; Juwei Huang; Ryan Feeley

> *Subject:* "Choose what to Sync" for autofill

[Ryan Kelly]

On 13 June 2017 at 12:22, Richard Newman <rne...@mozilla.com> 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?

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

* 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

    * 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

* 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

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?

So - what shall we do? Can we live with (1)?

Something about the edge-cases here makes me a little uneasy, but I suspect I don't fully understand all the combinations involved.

   Ryan

[Mark Hammond]

On 6/13/17 2:05 PM, Ryan Kelly wrote:
> On 13 June 2017 at 12:22, Richard Newman <rne...@mozilla.com

> <mailto:rne...@mozilla.com>> 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

[Juwei Huang]

On Tue, Jun 13, 2017 at 2:22 PM, Mark Hammond <mham...@mozilla.com> wrote:

On 6/13/17 2:05 PM, Ryan Kelly wrote:

On 13 June 2017 at 12:22, Richard Newman <rne...@mozilla.com <mailto:rne...@mozilla.com>> 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.

It makes sense to the users new to autofill, and I’ve already covered the scenario in autofill ux spec:

https://mozilla.invisionapp.com/share/AP8TFZ22G#/185446463_1-5_Autofill

The doorhanger[1] only shows up *one time* when users login FxA and encounter the *first* form.

However, it doesn’t cover the case that users have used autofill feature before *login*.
For example, users sign up FxA in computer A when it’s Firefox 55, and use another computer B without login FxA. Now Firefox in computer B is updated to 56, and users start to use autofill in B without login FxA. If they login FxA afterward after using autofill for a while, there is no hint to tell users to sync autofill.
So I prefer, in this case, users would see sync autofill option in *login page* instead of doorhanger. In login page, users focus more on what will change if they login so I think it makes perfect sense to inform users that “autofill will be sync too” at the moment, especially users is already using autofill and know what it is. However, if we use doorhanger to handle sync, it would be a different door hanger from doorhanger[1] and it makes less sense to me to show sync option at the moment when users focus on autofilling a form.

 

    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)

To me, it’s a little weird to see autofill in one of my sync options but I cannot find anywhere to use it on my phone. If we prefer to go for this proposal, could we at least inform users that autofill only available in desktop (for now)?

 

* 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

--

Juwei

[Richard Newman]

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.

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.

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?"

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.

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.".

   * 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, 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 and upload no data, which is essentially an enablement placeholder.

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).

 

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 :/

Quite!

[Richard Newman]

To me, it’s a little weird to see autofill in one of my sync options but I cannot find anywhere to use it on my phone. If we prefer to go for this proposal, could we at least inform users that autofill only available in desktop (for now)?

I'm pretty sure I've seen one of rfeeley's mocks that address this for sign-in/sign-up, because of course this is already the case for prefs and add-ons on mobile devices. Ryan?

[Ryan Kelly]

On 14 June 2017 at 02:11, Richard Newman <rne...@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, 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 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

[Mark Hammond]

On 6/13/17 6:10 PM, Juwei Huang wrote:
> 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.
>
>

> It makes sense to the users new to autofill, and I’ve already covered
> the scenario in autofill ux spec:
> https://mozilla.invisionapp.com/share/AP8TFZ22G#/185446463_1-5_Autofill
>

> The doorhanger[1] only shows up **one time** when users login FxA and
> encounter the *first* form.

Thanks the the pointer to that mockup.

Thinking more about this, and given the other sub-thread re Android and
rnewman/rfkelly's comments, I think what we need to do is, roughly, (2).
The lazy me wanted (1), but I don't think that works.

* Desktop will add support for the engines, disabled by default.

* For account creation, only Desktop Firefox 56+ will be offered the new
engines. It will flip the state of the new engines to enabled if they
are selected and will update the "declined" set otherwise.

* Android can support the round-tripping engine (bug 1360359), but *will
not* have that engine exposed in any UI - neither the web-based "create
account" flow, nor the local "sync options". It will only get that UI
support when it gets the autofill feature, at which time it will replace
that round-tripping engine. In the meantime, it will do the round-trip
sync whenever they aren't. Grisha, does that sound good?

So in effect, people creating an account on Android/ESR will be in the
same position as all existing users are.

> However, it doesn’t cover the case that users have used autofill feature
> before *login*.
> For example, users sign up FxA in computer A when it’s Firefox 55, and
> use another computer B without login FxA. Now Firefox in computer B is
> updated to 56, and users start to use autofill in B without login FxA.
> If they login FxA afterward after using autofill for a while, there is
> no hint to tell users to sync autofill.

Yes, that's a good point.

> So I prefer, in this case, users would see sync autofill option in
> *login page* instead of doorhanger.

For various reasons, I don't think we can make that happen for 56 (the
server simply doesn't know if it applies at signin time, and the client
doesn't know as it's not yet signed in.)

However, I expect these users are somewhat edge-cases. The absolute
worst-case is that they need to visit about:prefs and enable the engine
- and that might be OK for MVP.

> However, if we use
> doorhanger to handle sync, it would be a different door hanger from
> doorhanger[1] and it makes less sense to me to show sync option at the
> moment when users focus on autofilling a form.

Yes, we could show a slightly amended doorhanger at any time. I agree
that simply interacting with the feature may not be a good time, but
maybe it's not that bad given these users are unfortunate to be in this
state at all. Or maybe just the next time they save a profile (ie, at
the same time we would have first prompted for local saving)?

> To me, it’s a little weird to see autofill in one of my sync options but
> I cannot find anywhere to use it on my phone. If we prefer to go for
> this proposal, could we at least inform users that autofill only
> available in desktop (for now)?

As above, the lazy me was hoping we could get away with just showing it
everywhere, but I'm now convinced that's not going to work - Android
shouldn't offer this engine.

So, my current thinking says the UX looks roughly like:

* Desktop user creating account on 56+: new engines offered at creation
time. May or may not have opted in to the local feature, but it doesn't
matter - that's the simple case.

* Desktop user upgrading to 56 with existing Sync account: (ie, existing
sync users). New engines appear in about:prefs but are disabled. First
time doorhanger shown for the local feature the "also sync?" checkbox is
in the doorhanger, and this flips the new engines to enabled.

* Android/ESR user creating an account (1): Not presented with the new
engines. Signin in to the account on desktop will *not* present the
engines - hopefully it's a fairly new profile so they haven't yet opted
in to formautofill on the profile.

* Android/ESR user creating an account (2): Not presented with the new
engines. Signin in to the account on desktop, but *have* already opted
in to the local feature. This is Juwei's scenario above - worst case,
must find about:prefs, best case is that we show a modified doorhanger.

And what this means to engineering:

* New engines are landed with pref defaulted to disabled.
* FxAccounts/Browser handshake is extended to indicate if the new
engines should be enabled, and whether they were actually shown. Or
maybe UA sniff - we can work those details out.
* Desktop changes a little so if it is sure the new engines were
displayed and they weren't declined, we explicitly enable the engine.
* Android/iOS doesn't change at all.
* The "declined" feature basically does as it was designed to do - the
engine will not be marked as "declined" when the account is created on
Android (and obviously isn't marked as declined for existing users). Yay
Richard ;)

So the only 2 outstanding questions I see are:

* This *doesn't* handle a case where the *entire* autofill feature is
disabled for some obscure reason (eg, addon breakage? Something else?).
I propose we commit to this feature in 56+, so even if the entire
feature *is* disabled, we assume it is temporary and still offer the
engine and continue as normal, assuming it will be back any second now :)

* The edge case from Juwei (ie, somehow already have opted in to the
local feature without being asked about sync) is, largely, ignored - we
make a best-effort for a modified doorhanger, but would accept those
users might need to visit about:prefs in the worst case.

Does that sound OK?

Thanks,

Mark

[Juwei Huang]

Thank you Mark for clarifying all the complicated use cases! You always have the clearest logic in the thread :)

I've discussed your idea( which is to ignore the edge case for now) with Joe C and we both agree on it. Since it's not the-end-of-the-world use case and users still can go to preferences to enable autofill sync, I guess we can ignore this case in 56.

So it sounds good to me (and Joe)!

Juwei

--

Juwei

[Richard Newman]

* New engines are landed with pref defaulted to disabled.

This is a great time to point at Bug 1322428, which would go a long way towards broadening our funnel.