<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 June 2017 at 12:22, Richard Newman <span dir="ltr"><<a href="mailto:rnewman@mozilla.com" target="_blank">rnewman@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div>
<div>
<div id="m_3330490048230076833x_compose-container" style="direction:ltr">
<span><span></span></span>
<div>
<div style="direction:ltr">Bear in mind that we have 'declined' in meta/global, which is intended to support exactly this scenario.</div>
<div><br>
</div>
<div style="direction:ltr">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'.</div>
<div><br>
</div>
<div style="direction:ltr">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.</div>
<div><br>
</div></div></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font size="2"><span style="font-size:10pt"><div class="m_3330490048230076833PlainText">
<br>
1) We always offer these new engines in anticipation of the user <br>
eventually using a version of Firefox that supports them. The main issue <br>
with this is that it may cause confusion for the user - for example, if <br>
they create an account on Android, they may be confused when they can't <br>
find the addresses/credit-card feature on that platform. Similarly for <br>
users who happen to sign up on, say, Firefox ESR (which presumably will <br>
not get this support until the next ESR release).<br>
<br></div></span></font></div></blockquote><div><br></div><div>To be sure I understand what's proposed here:</div><div><br></div><div>* FxA always shows the new options in the choose-what-to-sync screen, defaulting them to unselected</div><div><br></div><div>* If the user does not select the new datatypes, then we include them in "declinedSyncEngines" when we message login state to the browser, and:</div><div>    * New browsers that support the feature, will know not to sync it, and will write it declined engines list on the server<br></div><div>    * 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<br></div><div><br></div><div>* If the user does select the new datatypes, then they don't show up in "declinedSyncEngines", and:</div><div>    * New browsers that support the feature will turn on syncing of those types, writing them explicitly into /meta/global on the server<br></div><div>    * But old browsers that don't support the feature will not do anything different</div><div><br></div><div>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></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font size="2"><span style="font-size:10pt"><div class="m_3330490048230076833PlainText">
So - what shall we do? Can we live with (1)?<br>
<br></div></span></font></div></blockquote><div><br></div><div>Something about the edge-cases here makes me a little uneasy, but I suspect I don't fully understand all the combinations involved.</div><div><br></div><div>   Ryan</div><div><br></div></div></div></div>