Re: Intent to ship: CSS Grid

2016-11-15 Thread Simon Sapin 

On 16/11/16 01:40, Mats Palmgren wrote:

Note about the 'subgrid' feature:
We will *not* support the subgrid feature of CSS Grid in this first
release.  This feature is marked as "at-risk" in the spec and thus
not needed for spec compliance.  (Chrome is likewise not going to
support subgrid in their first release.)


I don’t have a strong opinion on subgrid specifically, and other 
arguments can be made, but I’d like to note:


It is marked at-risk in the spec *because* several vendors had said they 
might not support it at first. So using this to justify not supporting 
it is a circular argument.


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

Intent to ship: CSS Grid

2016-11-15 Thread Mats Palmgren 

As of Gecko 52, I intend to let CSS Grid ride the trains on all platforms.
https://drafts.csswg.org/css-grid/
This also includes all parts of the CSS Box Alignment spec that are
relevant to Grid layout:
https://drafts.csswg.org/css-align-3/

It has been developed behind the "layout.css.grid.enabled" preference,
and has been enabled by default in Nightly and Aurora for some time now.

Other UAs shipping this or intending to ship it are:
Chrome - intends to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hBx1ffTS9CQ
Safari - is implementing it (independently):
https://bugs.webkit.org/show_bug.cgi?id=60731
Edge - status unknown to me

Note about the 'subgrid' feature:
We will *not* support the subgrid feature of CSS Grid in this first
release.  This feature is marked as "at-risk" in the spec and thus
not needed for spec compliance.  (Chrome is likewise not going to
support subgrid in their first release.)

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/jSmfRivZOrU/ZMPcwySUEW4J

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1217086

CSS Grid meta bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid

The Devtools team is implementing specific tools for Grid:
https://bugzilla.mozilla.org/show_bug.cgi?id=1181227
(some of which will ship in 52 I'm told)


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

Re: window.frames

2016-11-15 Thread adeebahashwan 
On Sunday, June 12, 2011 at 3:06:24 PM UTC-3, johnjbarton wrote:
> window.frames.toString() says "[object Window]". 
> Object.keys(window.frames) looks like window. How can I determine that 
> the window.frames is actually an array of windows?
> 
> jjb

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

nsISupportsArray and friends are deprecated, slated for removal in 55

2016-11-15 Thread Eric Rahm 
nsISupportsArray, nsICollection, nsIEnumerator, nsIBidirectionalEnumerator
have all been marked as deprecated in their IDL declarations as of Firefox
52 (currently dev edition).

This is not a new thing -- they've been semi-deprecated for 12 years [1] --
we just never fully removed them.

Over the years there's been a ton of work to remove usages of the
interfaces. I recently did a fair amount of work in bug 792209 [2] to
finish off getting rid of all remaining usage in mozilla-central and to
make our alternative, nsIArray, behave like nsISupportsArray in order to
make it easier to transition add-ons.

*What does this mean?*

Not that much, just please don't use those interfaces. You should see a
slew of warnings if you do (in C++ at least).

*How can I help?*

*comm-central* - mailnews/calendar still has some usage [3], if you have
some spare cycles to help out I'm sure they would appreciate it. If we
can't get rid of the usage by release 55 I still plan on removing the IDL
files from mozilla-central, it's possible we can move the definitions to
comm-central instead.

*add-ons* - Are you an add-on dev? Do you know an add-on dev? Transition
your code from using those interfaces or encourage the developer of your
favorite add-on to do so.


*What do I use instead?*

*nsIArray* and *nsIMutableArray* along with nsISimpleEnumerator are the
recommended replacements. For the most part they are drop-in compatible
with nsISupportsArray.

In C++ code if you need a new mutable array just use:

> nsCOMPtr arr = nsArray::Create();
>

In JavaScript:

> let arr = Cc["@mozilla.org/array;1"].createInstance(Ci.nsIMutableArray);


-e

[1]
https://groups.google.com/d/msg/netscape.public.mozilla.xpcom/RDWISpaMqAY/FUCS7G9ZKKIJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=792209
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=394167
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

FYI: SOFT tree close for TCW Scheduled Tree Closing Maintenance Window 2016-11-19 07:00a PST 5 hours

2016-11-15 Thread Hal Wine 
The tree closing this weekend will be a SOFT CLOSE -- there will be period
of time where new commits to hg.mozilla.org will be disabled, but the rest
of the automation infrastructure will be operational. Some minor work might
cause an unlucky job to burn - devs will need to retrigger those jobs.

Thanks to gps & the dev services team for improving our options with
hg.mozilla.org, which is what is letting us not have a hard close! \o/

For any other questions or concerns, please contact the MOC as indicated
below.
-- Forwarded message --
From: m...@mozilla.com 
Date: Mon, Nov 14, 2016 at 10:20 AM
Subject: TCW Scheduled Tree Closing Maintenance Window 2016-11-19 07:00a
PST 5 hours
To:


bcc:all-moco-mofo@

Start Date/Time: 2016-11-19 07:00a PST
End date/time: 2016-11-19 12:00p PST

Impact to Users:

   -

   HG will be hard hatted during a 4 hour window while NFS work is
   completed starting at 7a,  This will necessitate a hard tree closure.
   - Patching for Releng DNS, Proxy servers and WebOps servers will occur
   also starting at 7a.  We expect impact to users to be minimal.


Tracker Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1313152


If you have questions about this issue, please email m...@mozilla.com or
visit #moc in IRC.  We appreciate your patience while we perform this
maintenance work.

Thank you,

Mozilla Operations Center



start end Change Bugzilla Description Owner Group
7:00 7:00

close trees :kmoir releng
7:00 7:30 CHG0010980

Patch releng DNS servers :digi systems
7:00 11:00 CHG0010953

https://bugzilla.mozilla.org/show_bug.cgi?id=1312452 Split mozilla/users
from main hg NFS mount :gcox systems
7:30 8:30 CHG0010979

Patch DC proxies :digi systems
7:30 10:30 CHG0011035

https://bugzil.la/1312845 Kernel updates across 32 machines :fox2mike webops
11:00 12:00

reopen trees :kmoir releng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Intent to implement and ship: Web Authentication

2016-11-15 Thread J.C. Jones 
Apologies, this got caught in a filter. Re-sending for posterity on the
list.
-- Forwarded message --
From: J.C. Jones
Date: Tue, Nov 15, 2016 at 12:01 PM
Subject: Re: Intent to implement and ship: Web Authentication
To: berniepa...@gmail.com
Cc: dev-platform@lists.mozilla.org


Hey Bernie,

That's one possibility, but I expect WebAuthn to support the U2F
attestation payloads in its MakeCredential and GetAssertion calls, and then
Firefox will implement the U2F HID protocol initially rather than jumping
to CTAP v1.1.

Cheers,
J.C.

On Mon, Nov 14, 2016 at 6:08 PM,  wrote:

> Le lundi 14 novembre 2016 22:41:37 UTC+1, berni...@gmail.com a écrit :
> > Le lundi 14 novembre 2016 18:34:11 UTC+1, JC Jones a écrit :
> > > Bernie,
> > >
> > > You're right that the current WD does not contain the "U2F HID token"
> > > attestation format, but the WG is _intending_ to add it [1] -- and
> support
> > > for such devices -- in Working Draft 4 [2] as soon as a larger
> in-document
> > > refactor is complete.
> > >
> > > I won't guarantee success at this point, but I believe it likely that
> > > WebAuthn will ultimately support most fielded U2F HID-compliant
> devices.
> > >
> > > [1] https://github.com/w3c/webauthn/issues/214
> > > [2] https://github.com/w3c/webauthn/milestone/8
> > >
> > > Cheers!
> > > J.C.
> > >
> > >
> > >
> > > On Sun, Nov 13, 2016 at 4:36 PM, Bernie wrote:
> > >
> > > > Le vendredi 11 novembre 2016 22:18:58 UTC+1, JC Jones a écrit :
> > > > > The W3C Web Authentication Working Group [1] was formed to produce
> a
> > > > > browser-facing standard for using strong, cryptographic scoped
> > > > credentials
> > > > > to authenticate to web applications in an un-phishable way. The
> Working
> > > > > Group began working from specifications produced by the FIDO
> Alliance,
> > > > but
> > > > > through the W3C process ensured there was a web-focus to the final
> > > > result.
> > > > >
> > > > > We have been tracking the Web Authentication standard since last
> year’s
> > > > > FIDO U2F announcement [2],  and we believe Web Authentication
> provides a
> > > > > valuable augmentation to web application security in an inclusive
> way. We
> > > > > are proposing to implement the current draft specification for Web
> > > > > Authentication [3], and then track the evolution through to its
> final
> > > > > Recommendation state.
> > > > >
> > > > > Background: The Mozilla Foundation joined the FIDO Alliance to
> support
> > > > the
> > > > > work of providing augmented security to user logins across the
> Web. We
> > > > > encouraged FIDO to evolve their browser specifications within the
> W3C, to
> > > > > enable larger community involvement than simply Alliance members.
> This
> > > > > specification is a result of that wider effort.
> > > > >
> > > > > Web Authentication defines a way to use credentials from a secure
> element
> > > > > to authenticate to web applications using public key cryptography.
> As
> > > > with
> > > > > FIDO U2F, the browser’s role is mainly to provide the interface
> between
> > > > the
> > > > > secure element (such as a USB dongle) and the web application, and
> to
> > > > > enforce a scoped security model to bind the resulting attestation
> to the
> > > > > specific web application.
> > > > >
> > > > > Web Authentication support is currently in development for
> Microsoft Edge
> > > > > [4] [5]. Google Chrome’s support is also in-development.  Several
> > > > websites
> > > > > have deployed support for U2F, the predecessor to WebAuthn,
> including
> > > > > Gmail, Dropbox, and Github. Additionally, there are many U2F
> devices in
> > > > use
> > > > > today which will function with the Web Authentication API.
> > > > >
> > > > > Proposed: To implement the Web Authentication API, with support
> for the
> > > > USB
> > > > > U2F HID token attestation format.
> > > > >
> > > > > Please send comments on this proposal to the list no later than 21
> > > > November
> > > > > 2016.
> > > > >
> > > > > [1] https://www.w3.org/blog/webauthn/
> > > > >
> > > > > [2] https://groups.google.com/d/msg/mozilla.dev.platform/
> > > > > IVGEJnQW3Uo/Eu5tvyLmCgAJ
> > > > >
> > > > > [3] https://www.w3.org/TR/webauthn/
> > > > >
> > > > > [4] https://blogs.windows.com/msedgedev/2016/04/12/a-world-
> > > > > without-passwords-windows-hello-in-microsoft-edge/#XKWsxS6Pw
> LOtBYrG.97
> > > > >
> > > > > [5] https://developer.microsoft.com/en-us/microsoft-edge/
> > > > platform/status/
> > > > > webauthenticationapi/?q=webauth
> > > > >
> > > > > - J.C., Crypto Engineering
> > > >
> > > > Hi,
> > > >
> > > > the company I am working for is a small member of the the FIDO
> alliance.
> > > > We are offering our own U2F USB HID tokens (and soon U2F BLE
> devices...)
> > > >
> > > > As far as I know, there are still several debates inside the
> Alliance but
> > > > until recently it was never clearly stated that present U2F
> tokens/devices
> > > > will be compatible

Changes to OrangeFactor Robot comments in intermittent test failure bugs

2016-11-15 Thread Geoffrey Brown 
"OrangeFactor Robot" comments in bugs for intermittent test failures now
have additional information:

1. Daily and weekly comments now include the push count and failure rate.
For example:

  7 failures in 606 pushes (0.012 failures/push) were associated with this
bug yesterday.

Previously, only the failure count ("7 failures") was reported, sometimes
leading to misconceptions about changes to failure rate (a test failed 3
times yesterday, but 30 times today -- did the test change today...or were
the trees closed yesterday!?).

The push count is still only a very rough approximation of the number of
times the test was run. Sometimes tests are skipped on certain platforms,
skipped on a push to reduce load, or retried/repeated on a single push. In
particular, since SETA regularly skips some test jobs, the number of test
runs per push will vary across test jobs, so the failure rate of one test
relative to another test may not be meaningful.

Use the failure rate to compare changes in the rate of occurrence of one
bug over time; do not use it to compare one bug to another.

2. The weekly comments for the most frequent failures now include the bug's
rank -- its position in that week's top 50 most frequent failures tracked
by OrangeFactor. For example:

  This is the #12 most frequent failure this week.

This is an indication of the relative frequency of this bug compared to
other intermittent test failure bugs: The #12 bug had more tracked failures
than the #13 bug. This may be an effective guide for prioritizing work on
intermittent test failure bugs.

3. The weekly comments for bugs with more than 50 failures in the week now
include:

  ** This failure happened more than 50 times this week! Resolving this bug
is a high priority. **

These high-frequency failures consistently account for a large percentage
of test failures. In the last 7 days, just 36 high-frequency bugs (less
than 4% of the 987 bugs tracked by OrangeFactor) accounted for 4111
failures (about 41% of the 8902 failures tracked by OrangeFactor).

If you can contribute to the resolution of one of these bugs, please make
it a priority: Quick resolution of these bugs can reduce overall test
failure counts dramatically, helping everyone watching treeherder.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform