Re: Intent to implement and ship: Web Authentication

[Anders Rundgren]

On Friday, December 2, 2016 at 10:27:30 PM UTC+1, JC Jones wrote:
> Anders,
> 
> The first target I'm working on is Desktop, though I've plans in 2017 to
> support WebAuthn on Android and iOS [1], too. WebAuthn already has
> definitions suitable for Android's Key Attestation [2] and SafetyNet
> formats [3], so they'll need implementations that tie into the
> dom::WebAuthentication class.

That's great news!

Regards,
Anders

> 
> Cheers,
> J.C.
> 
> [1] https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
> [2] https://w3c.github.io/webauthn/#android-key-attestation
> [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
> 
> On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
> 
> > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren wrote:
> > > It is a pity that external tokens have become the
> > > focus when the majority will rather rely on embedded
> > > security solutions which nowadays is a standard feature
> > > in Android and Windows platforms.
> >
> > Slight clarification to the above: The IoT folks pretty much build 100% on
> > embedded security with car-keys as an obvious exception.
> >
> > On mobile I would say that over 99% of all existing security solutions
> > based on cryptographic keys are relying on embedded (or "App level") keys
> > with Apple Pay as the most advanced example.
> >
> > That is, the token vendors and security folks do not represent the actual
> > market comprising of end-users and service providers.
> >
> > Maybe this is a project primarily targeting the desktop?
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Faster blame on hg.mozilla.org / mozilla-central repo with CVS history

[Gregory Szorc]

I'm pleased to announce the immediate availability of 2 new features on
hg.mozilla.org: faster blame rendering and a mozilla-central repo with CVS
history. You can find these features at:

* https://hg.mozilla.org/experimental/mozilla-central-gd
* https://hg.mozilla.org/experimental/mozilla-central-cvs

experimental/mozilla-central-gd is a straight clone of mozilla-central with
more efficient Mercurial storage and the fast blame feature enabled.

experimental/mozilla-central-cvs contains CVS history. It should update
within seconds of pushes to mozilla-central. It also has fast blame
enabled. Note: there is no guarantee the commit hashes on this repo are
stable. Please don't rely on that!

If you encounter any issues or have feature requests, please file bugs in
the hg.mozilla.org bugzilla component or track me down.

Also, I'd love to hear feedback if these features are beneficial to you.

Read on for low-level details.

The mozilla-central-cvs repo was created by converting the CVS history from
the gecko-dev Git repo to Mercurial. Then, all commits from mozilla-central
were essentially replayed on top of that history. This was the easiest way
to perform a conversion. This does preserve all the oddities with both
histories. If I had infinite time, I'd do a "proper" conversion that prunes
badness and does things like rename detection. I'd like to leave the door
open to doing this in the future: that's partially why "experimental" is in
the URL. Bug 1265493 tracks these remaining improvements.

For changesets converted from mozilla-central, the HTML output will render
a link to the original mozilla-central changeset. See the "converted from"
line on e.g.
https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/ab117d946959.

The faster blame rendering comes courtesy of the "fastannotate" extension
available from https://bitbucket.org/facebook/hg-experimental/. The faster
blame rendering is, well, fast. We can see this clearly when invoking the
`blame` CLI command against the gecko-dev Git and mozilla-central-cvs
Mercurial repos using Git 2.11.0 and Mercurial 4.0:

dom/base/nsDocument.cpp
git blame: 8.6s
hg blame: 8.6s
hg fastannotate: 0.4s

layout/base/nsCSSFrameConstructor.cpp
git blame: 17.7s
hg blame: 11.3s
hg fastannotate: 0.4s

While vanilla Mercurial was already faster or the same speed as Git,
Mercurial with fastannotate makes things effectively instantaneous - up to
44x faster than Git!

A wrinkle in this awesome performance is that it isn't as obvious in the
web interface for large files. This is because a) the server spends a lot
of time in the templating mechanism generating HTML b) I think the emitted
HTML is causing browsers to behave a bit sub-optimally (Searchfox seems to
behave much better in this area). I believe both these issues can be
improved in Mercurial 4.1. Although a web performance guru might have to
give suggestions to optimize HTML/layout. (Please get in touch!)

Anyway, if you load a large blame page like
https://hg.mozilla.org/experimental/mozilla-central-cvs/annotate/tip/layout/base/nsCSSFrameConstructor.cpp
the output will start streaming immediately, but it could take a few
seconds for everything to appear. Still, the overall page will load
significantly faster than before because the core blame algorithm is
running faster. e.g. the HTTP request for nsCSSFrameConstructor.cpp serves
in 2.4s vs 23.6s from my machine. While not as fast as the 28x speedup to
the core algorithm, a 10x speedup is definitely noticeable :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

I wasn't able to enable Rust by default this week. While it's working
for most developers, there are some automation jobs which aren't ready
for the change. We'll address those and continue to improve the
`./mach boostrap` installer behaviour before flipping the switch.

Thanks to everyone for your support and testing feedback!

 -r

On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles  wrote:
> tl;dr This is a heads-up that all gecko developers should install rust.
>
> Next week I plan to switch our default build config to require Rust
> when building Firefox.[1] If you compile Firefox from the C++ source,
> please install the Rust language environment now.
>
> You can install Rust by running `./mach bootstrap` which will download
> and run the rustup installer for you.[2]
>
> We recommend the installer at https://rustup.rs/ (despite being beta)
> because it makes staying up to date and cross-compilation easy. If you
> want more control, or to experiment with rust, you can install
> directly from that website.
>
> The main thing is to have up-to-date versions of the `rustc` and
> `cargo` executables in the path of your build shell. Rust releases
> every six weeks, just like Firefox, and we generally require the
> latest stable release to compile mozilla-central. You can stay current
> by running `rustup update`.
>
> You'll still be able to build without a rust compiler by adding:
>
>   ac_add_options --disable-rust
>
> to your mozconfig. This is a temporary work-around; we expect to
> remove that option and require Rust unconditionally early next year as
> non-optional features start to depend on it.
>
> Rust language in Gecko is an important part of Project Quantum. I'm
> excited to be taking this next step toward that future. We first
> shipped Rust code to users in Firefox 48, so it's long past time this
> aspect of our default builds matched what we release.[3]
>
> Thanks for your attention,
>  -r
>
> [1] Enabling rust is https://bugzil.la/1283898
> [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> [3] If you have issues with the installer or build, please file issues
> blocking our tracking bug at https://bugzil.la/oxidation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[J.C. Jones]

Anders,

The first target I'm working on is Desktop, though I've plans in 2017 to
support WebAuthn on Android and iOS [1], too. WebAuthn already has
definitions suitable for Android's Key Attestation [2] and SafetyNet
formats [3], so they'll need implementations that tie into the
dom::WebAuthentication class.

Cheers,
J.C.

[1] https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
[2] https://w3c.github.io/webauthn/#android-key-attestation
[3] https://w3c.github.io/webauthn/#android-safetynet-attestation

On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren wrote:
> > It is a pity that external tokens have become the
> > focus when the majority will rather rely on embedded
> > security solutions which nowadays is a standard feature
> > in Android and Windows platforms.
>
> Slight clarification to the above: The IoT folks pretty much build 100% on
> embedded security with car-keys as an obvious exception.
>
> On mobile I would say that over 99% of all existing security solutions
> based on cryptographic keys are relying on embedded (or "App level") keys
> with Apple Pay as the most advanced example.
>
> That is, the token vendors and security folks do not represent the actual
> market comprising of end-users and service providers.
>
> Maybe this is a project primarily targeting the desktop?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Ehsan Akhgari]

On 2016-12-01 11:21 PM, Boris Zbarsky wrote:
> On 12/1/16 10:40 PM, Bill McCloskey wrote:
>> As part of the Quantum DOM project, we're going to be "labeling" all
>> runnables in the browser to say which document they're operating on.
> 
> Is the intent basically to get rid of NS_DispatchToMain/CurrentThread,
> or at least get their usage down to a minimum?

We won't get rid of them.  For one thing, this project is really focused
in the stuff that happens on the main thread of the content process, and
those APIs are used elsewhere.  But yes, the usage of those APIs should
go down to a minimum.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Ehsan Akhgari]

On 2016-12-02 12:42 PM, Tom Tromey wrote:
>> "Bill" == Bill McCloskey  writes:
> 
> Bill> As part of the Quantum DOM project, we're going to be "labeling" all
> Bill> runnables in the browser to say which document they're operating on.
> 
> I wonder whether this can be used to fix the various "run to completion"
> bugs we've encountered in the debugger.  I don't know if I understand
> the problems there well enough to do them justice, but basically the
> issue is that the debugger needs to delay some runnables but not others,
> and the approach currently used lets some slip through.  This shows up
> in a very confusing way for the user, like some XHR callbacks still
> being invoked while supposedly paused in the debugger.
> 
> The meta bug for the devtools side of this is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1074448
> It has links to all the scenarios where we've encountered the bad behavior.
> 
> The wish-list fix is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=715376
> aka "implement per-page event queue, to allow timeout 
> grouping/prioritization/etc".
> I wonder specifically if Quantum DOM is going to fix this one.

Once the labeling of runnables is finished, we will know which DocGroup
(or TabGroup if the DocGroup isn't known at runnable dispatch time) a
runnable belongs to.  For the Quantum DOM project purposes we will
probably end up splitting the event queue into one queue per TabGroup.
That way, not running a TabGroup would be as simple as skipping over the
queue belonging to the TabGroup from the main event loop.

With this infrastructure in place, we should be able to "suspend" an
entire TabGroup when a page inside it is being debugged, for example.
Or something similar along those lines, depending on what the exact
needs from the devtools side are.  That way, things such as XHR
callbacks will be runnables waiting in the suspended TabGroup's queue,
which will be processed when the TabGroup is resumed.

(Note that we may also be able to do this at the DocGroup level for
devtools, if that's more appropriate.)

Does this sounds like a useful answer?

Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Tom Tromey]

> "Bill" == Bill McCloskey  writes:

Bill> As part of the Quantum DOM project, we're going to be "labeling" all
Bill> runnables in the browser to say which document they're operating on.

I wonder whether this can be used to fix the various "run to completion"
bugs we've encountered in the debugger.  I don't know if I understand
the problems there well enough to do them justice, but basically the
issue is that the debugger needs to delay some runnables but not others,
and the approach currently used lets some slip through.  This shows up
in a very confusing way for the user, like some XHR callbacks still
being invoked while supposedly paused in the debugger.

The meta bug for the devtools side of this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1074448
It has links to all the scenarios where we've encountered the bad behavior.

The wish-list fix is:
https://bugzilla.mozilla.org/show_bug.cgi?id=715376
aka "implement per-page event queue, to allow timeout 
grouping/prioritization/etc".
I wonder specifically if Quantum DOM is going to fix this one.

thanks,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Johnny Stenback]

Excellent, thank you!


- jst

On Fri, Dec 2, 2016 at 7:28 AM, Andrew McCreight 
wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
>
> > If you want to get started before that, please make sure to
> >> file a bug on what you're doing before you start. That should avoid
> >> duplicating work.
> >>
> >
> > Is there an overall tracking bug people could check to see which things
> > are already filed or in-progress?
> >
>
> I filed bug 1321812 just now to use as a meta bug.
>
>
>
> >
> > -Boris
> >
> > P.S.  This is awesome.  ;)
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Andrew McCreight]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:

> If you want to get started before that, please make sure to
>> file a bug on what you're doing before you start. That should avoid
>> duplicating work.
>>
>
> Is there an overall tracking bug people could check to see which things
> are already filed or in-progress?
>

I filed bug 1321812 just now to use as a meta bug.



>
> -Boris
>
> P.S.  This is awesome.  ;)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Presentation API on Fennec

[Boris Zbarsky]

On 12/2/16 6:11 AM, Shih-Chiang Chien wrote:

We implement 1-UA mode described in spec. Session resumption and many-to-1
session is not available in this mode.

.

Google have release this API on both desktop and Android browser for 2-UAs
mode (see https://www.chromestatus.com/feature/6676265876586496), which
allows web page to communicate with Chromecast receiver apps. They are
implementing 1-UA mode as well, see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo


Just to make sure I understand:

1)  Google ships "2-UAs" mode.  On which platforms?
2)  We are planning to ship 1-UA mode on Android only, for the moment.
3)  Google is implementing 1-UA mode on desktop only, for the moment.

Is that a correct summary of the current interop situation?

If it is, I have some questions:

A) How are sites expected to make use of this in practice given the above?
B) If a site is written to Google's 2-UAs implementation, what happens 
when it runs in Firefox with the 1-UA implementation?  Can it detect 
that it's dealing with a 1-UA implementation instead of a 2-UAs one? 
Does it need to do such detection?  Do sites do it in practice?


Do we have any indications from Apple or Microsoft as to whether they 
plan to implement this API?


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Presentation API on Fennec

[Shih-Chiang Chien]

Hi all,

In Bug 1318214  I've
default enabled Presentation API on Fennec nightly, which allow web page to
use Google Chromecast/Nexus Player as a extended screen.

We implement 1-UA mode described in spec. Session resumption and many-to-1
session is not available in this mode.

The release plan of this API on Firefox desktop is still under discussion.

Google have release this API on both desktop and Android browser for 2-UAs
mode (see https://www.chromestatus.com/feature/6676265876586496), which
allows web page to communicate with Chromecast receiver apps. They are
implementing 1-UA mode as well, see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo

For interoperability, W3C Second Screen CG have initiate the discussion of
defining open protocol for presentation control and video casting.

If you found any issue please file bugs and set dependency to Bug 1184036
.

link to spec: https://www.w3.org/TR/presentation-api/

Platform coverage: Firefox for Android

Estimate of target release: Firefox 53

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform