Re: FxA application registration request: Firefox for Fire TV

[Michael Comella]

Hi Shane,

When do the credentials merged to the dev server move onto the production
Firefox Accounts server?
- Mike

On Tue, Jul 2, 2019 at 4:43 PM Michael Comella  wrote:

> Hi Shane,
>
> On Tue, Jul 2, 2019 at 4:22 AM Shane Tomlinson 
> wrote:
>
>> Hi Mike,
>> Those docs are a bit out of date now and need to be updated (on Q3's OKR
>> list), sorry for the confusion. It shouldn't be a problem to get you set up
>> with OAuth credentials.
>>
>> As mentioned in the docs development occurs against the
>> https://stable.dev.lcip.org FxA stack. stable is a prod-like stack that
>> is updated every Thursday. Note that it's user database is distinct to
>> https://accounts.firefox.com, so developers will need to create and
>> verify an account there to sign into the app. OAuth credentials for
>> https://accounts.firefox.com are reserved for your beta/production apps.
>>
>> I have created a PR to provision creds
>> <https://github.com/mozilla/fxa-dev/pull/468> on
>> https://stable.dev.lcip.org for you. If that looks good to you, we can
>> get that deployed soon.
>>
>
> Given my limited knowledge, this looks good to me.
>
> When would create beta/production credentials?
>
>>
>> Will Firefox for Fire TV access Sync data? I'm assuming so.
>>
>
> In the short term (Q3), we only intend to receive tabs. We have no current
> plans to use sync data otherwise.
>
>>
>> I know from speaking to Chenxia that there are a few wriggles that need
>> to be ironed out for Fx for Fire TV, especially around navigation and
>> input. Email verification is going to be interesting too, I wonder if users
>> will find it obvious how to verify their email. We have been talking about
>> making all users verify their email address by typing a TOTP-like code
>> <https://github.com/mozilla/fxa/issues/457> that is sent to their email
>> address, in this case, since Firefox for Fire TV is input constrained, it
>> might make sense to have continue with the existing behavior and have users
>> click a link instead.
>>
>
> Our intent is to land a proof-of-concept FxA sign in integration ASAP to
> be able to test all the flows on device and figure out the optimal user
> experience. Bram, our UX designer, may have already done some research with
> your team here but fwiw, I'm missing context on it.
>
> Thanks for the quick response – let me know if you have any questions or
> suggestions for me! I don't have much context on the FxA integration so I'm
> currently in the process of figuring it out in this issue
> <https://github.com/mozilla-mobile/firefox-tv/issues/2445>.
> - Mike
>
>>
>> Shane
>>
>> On Tue, Jul 2, 2019 at 2:17 AM Michael Comella 
>> wrote:
>>
>>> Hey dev-fxacct (CC firefox-tv list for context),
>>>
>>> The Firefox for Fire TV app is integrating FxA sign in and I'd like to
>>> get credentials to enable sign in. I don't fully understand the
>>> documentation
>>> <https://mozilla.github.io/application-services/docs/accounts/welcome.html#becoming-a-firefox-accounts-relier>
>>> – it suggests that our app is an "OAuth relier" (what does that mean?) and
>>> that we have a "service" (is the app considered a service?) – but from
>>> reading the docs and looking at samples
>>> <https://github.com/mozilla-mobile/android-components/tree/master/samples/firefox-accounts>,
>>> I think if we provide the following info, we can get credentials to allow
>>> users to log into FxA:
>>>
>>> name: "Firefox for Fire TV"
>>> redirect_uri: https://accounts.firefox.com/oauth/success/
>>>
>>> fwiw, like the sample linked above, we'd intend to intercept the
>>> redirect URL, grab the returned credentials, and redirect the user to a
>>> native UI screen (as per our mocks)
>>> <https://whimsical.com/Mbrga1N3KwHiJpExhSR23m>. Additionally, since we
>>> can't create additional WebViews on Fire OS and we only support a single
>>> tab, we have to use the user's current browsing session so we'd consider
>>> removing the FxA sign in pages from the user's browsing history.
>>>
>>> Let me know if there are any issues. Thanks!
>>> - Mike
>>> ___
>>> Dev-fxacct mailing list
>>> Dev-fxacct@mozilla.org
>>> https://mail.mozilla.org/listinfo/dev-fxacct
>>>
>>
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: FxA application registration request: Firefox for Fire TV

[Michael Comella]

Hi Shane,

On Tue, Jul 2, 2019 at 4:22 AM Shane Tomlinson 
wrote:

> Hi Mike,
> Those docs are a bit out of date now and need to be updated (on Q3's OKR
> list), sorry for the confusion. It shouldn't be a problem to get you set up
> with OAuth credentials.
>
> As mentioned in the docs development occurs against the
> https://stable.dev.lcip.org FxA stack. stable is a prod-like stack that
> is updated every Thursday. Note that it's user database is distinct to
> https://accounts.firefox.com, so developers will need to create and
> verify an account there to sign into the app. OAuth credentials for
> https://accounts.firefox.com are reserved for your beta/production apps.
>
> I have created a PR to provision creds
> <https://github.com/mozilla/fxa-dev/pull/468> on
> https://stable.dev.lcip.org for you. If that looks good to you, we can
> get that deployed soon.
>

Given my limited knowledge, this looks good to me.

When would create beta/production credentials?

>
> Will Firefox for Fire TV access Sync data? I'm assuming so.
>

In the short term (Q3), we only intend to receive tabs. We have no current
plans to use sync data otherwise.

>
> I know from speaking to Chenxia that there are a few wriggles that need to
> be ironed out for Fx for Fire TV, especially around navigation and input.
> Email verification is going to be interesting too, I wonder if users will
> find it obvious how to verify their email. We have been talking about
> making all users verify their email address by typing a TOTP-like code
> <https://github.com/mozilla/fxa/issues/457> that is sent to their email
> address, in this case, since Firefox for Fire TV is input constrained, it
> might make sense to have continue with the existing behavior and have users
> click a link instead.
>

Our intent is to land a proof-of-concept FxA sign in integration ASAP to be
able to test all the flows on device and figure out the optimal user
experience. Bram, our UX designer, may have already done some research with
your team here but fwiw, I'm missing context on it.

Thanks for the quick response – let me know if you have any questions or
suggestions for me! I don't have much context on the FxA integration so I'm
currently in the process of figuring it out in this issue
<https://github.com/mozilla-mobile/firefox-tv/issues/2445>.
- Mike

>
> Shane
>
> On Tue, Jul 2, 2019 at 2:17 AM Michael Comella 
> wrote:
>
>> Hey dev-fxacct (CC firefox-tv list for context),
>>
>> The Firefox for Fire TV app is integrating FxA sign in and I'd like to
>> get credentials to enable sign in. I don't fully understand the
>> documentation
>> <https://mozilla.github.io/application-services/docs/accounts/welcome.html#becoming-a-firefox-accounts-relier>
>> – it suggests that our app is an "OAuth relier" (what does that mean?) and
>> that we have a "service" (is the app considered a service?) – but from
>> reading the docs and looking at samples
>> <https://github.com/mozilla-mobile/android-components/tree/master/samples/firefox-accounts>,
>> I think if we provide the following info, we can get credentials to allow
>> users to log into FxA:
>>
>> name: "Firefox for Fire TV"
>> redirect_uri: https://accounts.firefox.com/oauth/success/
>>
>> fwiw, like the sample linked above, we'd intend to intercept the redirect
>> URL, grab the returned credentials, and redirect the user to a native UI
>> screen (as per our mocks) <https://whimsical.com/Mbrga1N3KwHiJpExhSR23m>.
>> Additionally, since we can't create additional WebViews on Fire OS and we
>> only support a single tab, we have to use the user's current browsing
>> session so we'd consider removing the FxA sign in pages from the user's
>> browsing history.
>>
>> Let me know if there are any issues. Thanks!
>> - Mike
>> ___
>> Dev-fxacct mailing list
>> Dev-fxacct@mozilla.org
>> https://mail.mozilla.org/listinfo/dev-fxacct
>>
>
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: FxA context query param values - mob_ios_v1, mob_android_v1 - are they still needed?

[Michael Comella]

Hi Shane.

No, I don't think these values are still needed. FirefoxData was a project
that never really took off and will soon be obsoleted by the cross-platform
Firefox sync implementations, if it hasn't been already!

Thanks for asking.
- Mike

On Mon, Nov 5, 2018 at 5:03 AM Shane Tomlinson 
wrote:

> Hi Michael,
>
> Last May we added two new FxA `context` query parameters to support mobile
> development, mob_ios_v1, and mob_android_v1. Are these still used/needed?
> In [1], the last comment is "not actively working on this issue". In [2], I
> don't see any entries for either context leading me to believe they are
> unused.
>
> If these values are no longer needed, I'd like to remove them so they
> can't be used unexpectedly.
>
> Thanks,
> Shane
>
> [1] - https://github.com/mozilla-mobile/FirefoxData-android/issues/21
> [2] - https://sql.telemetry.mozilla.org/queries/52856/source#140579
>
>
>
>
>
> Hey Michael,
>
>
> Last May we added two new FxA `context` query parameters to support mobile
> development, mob_ios_v1, and mob_android_v1. Are these still used/needed?
> In [1], the resolution of the issue is ?not actively working on this
> issue?. In [2], I don?t see any entries for either context.
>
>
>
> If these are no longer needed, I?d like to remove them so they can?t be
> used unexpectedly.
>
>
>
>
> Thanks,
>
> Shane
>
> [1] - https://github.com/mozilla-mobile/FirefoxData-android/issues/21
> [2] - https://sql.telemetry.mozilla.org/queries/52856/source#140579
>
>
>
>
>
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Re: Minutes from July 18 Mobile Tech Leads meeting

[Michael Comella]

Hey everyone.

Nick and I clarified our understanding of coroutines via IRC. Between this
email and IRC, it seems Nick's primary concern is that it may be difficult
to make the FFI libraries internally threadsafe [1]. By default, coroutines
dispatch to the `CommonPool`, where 1) coroutines can be dispatched to
arbitrary common pool threads and 2) an already dispatched coroutine, after
suspension, can resume on an arbitrary thread in the common pool.

Unfortunately, I don't understand the FFI thread safety in Rust issue well
enough to provide a single solution, however, some varied solutions to
thread safety are:
- Coroutines optionally suspend when they call a function with the
`suspend` keyword. afaik, if you never call one of these functions, you'll
never suspend and you'll remain on a single thread. This is hard to
enforce, however.
- Use a single dedicated thread for all FFI calls by running on a dedicated
CoroutineContext: see `newSingleThreadContext
<https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/new-single-thread-context.html>
`
- (may not be possible) Implement a new
CoroutineContext/CoroutineDispatcher that dispatches to a thread pool but
will resume only on the same thread. CoroutineContexts can be built on top
of Executor, if that's helpful.
- If your problem is sequential calls rather than which actual thread the
coroutines run on, you can use a coroutine `mutex
<https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental.sync/-mutex/index.html>`
which will suspend until the resource can be acquired.

For our raw conversation, see the IRC logs
<https://mozilla.logbot.info/mobile/20180723#c15057582>.

Hope it helps! Please let me know if you have more questions!
- Mike

[1]: https://mozilla.logbot.info/mobile/20180724#c15058851 (and previous
day)

On Fri, Jul 20, 2018 at 9:44 AM Nicholas Alexander 
wrote:

> Mike,
>
> Thanks so much for teaching us some things.
>
> On Thu, Jul 19, 2018 at 1:20 PM, Michael Comella 
> wrote:
>
>> Thanks for the updates, Nick – it's interesting to hear what other teams
>> are doing and how it may affect me. :) One quick thought:
>>
>>
>>> Rust code should be synchronous
>>
>>
>> I haven't thought about this enough to have an opinion on whether this is
>> the right decision or not. However, this may encourage the Rust library
>> consumers to make a mistake I once made with Kotlin coroutines: *I want
>> to share so others don't make the same mistake.*
>>
>> While you can create an obscenely large number of coroutines, there is a
>> limit to the number that can run concurrently: this limit is defined by the
>> thread pool they run on. The default built-in `CommonPool` has a fixed
>> number of threads. If you run blocking code (e.g. potentially synchronous
>> Rust code ^) on this thread pool, i*t prevents other coroutines from
>> beginning to run* until the blocking code completes. Here's a
>> demonstration using Android.
>> <https://github.com/mcomella/BlockingCoroutinesExample>
>>
>
> I was concerned about this, for slightly different reasons: I care about
> the same thread of execution servicing the next FFI call, i.e., that FFI
> calls don't rotate between threads non-deterministically.  But I think it's
> very similar to the situation you warn about.  I took an action item to
> read more about Kotlin co-routines, and summarized (in the notes) like this:
>
>
>-
>
>  AI: nalexander to read more about how Kotlin coroutines are
>  implemented
>  -
>
> [nalexander] OK, I’ve done this.  Based on the Kotlin 1.1+
> coroutines documentation
> <https://kotlinlang.org/docs/reference/coroutines.html>,
> Kotlin coroutines are implemented as a CPS transformation and an 
> internal
> state machine.  That state machine is pumped from a single 
> thread. That’s
> very similar to clojure/core.async
> <https://github.com/clojure/core.async> and means that
> there’s no thread pool servicing coroutines!  Any additional 
> thread must be
> the result of the application (or a library).  That means
> that all my hypothetical concerns about coroutines invoking FFI 
> methods on
> multiple threads are not justified.
>
> Am I incorrect?  Please correct me if so!
>
> Why is this a problem? *If you're a library (e.g. android-components)
>> that uses the same fixed thread pool as the application, you may block the
>> application's coroutines from starting quickly!* For example, if the
>> library makes several calls to read configuration files fro

Re: Minutes from July 18 Mobile Tech Leads meeting

[Michael Comella]

Thanks for the updates, Nick – it's interesting to hear what other teams
are doing and how it may affect me. :) One quick thought:


> Rust code should be synchronous


I haven't thought about this enough to have an opinion on whether this is
the right decision or not. However, this may encourage the Rust library
consumers to make a mistake I once made with Kotlin coroutines: *I want to
share so others don't make the same mistake.*

While you can create an obscenely large number of coroutines, there is a
limit to the number that can run concurrently: this limit is defined by the
thread pool they run on. The default built-in `CommonPool` has a fixed
number of threads. If you run blocking code (e.g. potentially synchronous
Rust code ^) on this thread pool, i*t prevents other coroutines from
beginning to run* until the blocking code completes. Here's a demonstration
using Android. 

Why is this a problem? *If you're a library (e.g. android-components) that
uses the same fixed thread pool as the application, you may block the
application's coroutines from starting quickly!* For example, if the
library makes several calls to read configuration files from disk, each on
a new coroutine on the CommonPool, these may block all of the CommonPool
threads. If all the threads are blocked and the application spawns a
coroutine on the CommonPool to do background processing before rendering
the results in the UI, the application's coroutine (and thus the UI update)
will wait until the library's coroutines finish blocking before it runs.

---

Some possible solutions to this are:
- Use a separate thread pool for blocking calls (here's an open ticket for
a system-wide IO thread pool
)
- Use non-blocking IO (supported in Java 7+ with nio
)

Hope it helps!
- Mike

On Wed, Jul 18, 2018 at 8:28 PM Nicholas Alexander 
wrote:

> We had a Mobile Tech Leads Meeting earlier today (NA/AU timezones).  Due
> to PTO, it was a smaller group than usual.
>
> A very brief and opinionated summary of our discussion (from this doc
> 
> ):
>
>1. *How do we manage threading* between consumers (primarily Android
>invoking Rust from Java/Kotlin, but also iOS invoking Rust from Swift) and
>Rust libraries?
>- Discussion focused on JVM thread pools and Kotlin coroutines.
>   - Strong desire to not expose concurrency in the API surface
>   - Initial proposal, subject to much further discussion:
>   -
> *Rust code should be synchronous *
>  - *Rust code should expect to be invoked from multiple threads*
>  - *Rust code should expect to be serialized (via Java
>  `synchronize` keyword or equivalent)*
>  2. There was some discussion of dependency injection for logging
>and telemetry.
>   - markh will be leading that discussion for telemetry.
>
> There's more in the notes but that's the gist.
>
> Your interlocutor,
> Nick
>
> ___
> android-components mailing list
> android-compone...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/android-components
>
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct