Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh 
TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
agree that these concerns make sense and have nothing else to add as far as
the response goes.

On Fri, Jul 27, 2018 at 2:33 PM, Tantek Çelik 
wrote:

> > The only thing worth
> > noting is that while you say there's no need to delay for years, that may
> > well be what ends up happening, and Mozilla will essentially be "blocking
> > progress" on this front.
>
> If there were only two browser vendors (including Mozilla) then yes
> your statement would be correct.
>
> However, we have (at least) four major browser vendors, and thus it is
> incorrect to assert that Mozilla alone could be "blocking progress"
> when any 2 of the other 3 browser vendors could implement something
> and have it exit CR.
>
That's fair. I suppose there's some (now irrelevant) historical context
here: it used to be that Mozilla championed this stuff and drove others to
push accessibility forward. At present, that is not the case, and I'm
concerned it'll now be very hard to make much progress in accessibility.
Still, while that's kind of sad, I take your point that this is irrelevant
to the requirements of the charter.


> > We want "limited resources" to drive better
> > standards, yet with our resources in accessibility as limited as they
> are at
> > this point, it's entirely likely we won't get around to implementing new
> > ARIA stuff for years.
>
> That may well be. If that is your assessment, we should add that to
> our Charter response and be quite upfront that we are unlikely to
> implement new ARIA stuff for (a few?) years, and perhaps ask
> (non-F.O.) for the WG to be postponed accordingly.
>
Honestly, there is a lot of uncertainty at this point; I certainly couldn't
give any "formal" statement concerning what we might or might not
implement. FWIW, I believe Mozilla *should* implement this stuff, but that
all depends on me convincing leadership that we should provide more
resources for accessibility. :) Again, irrelevant to our charter response.


> In addition per your note about "still haven't implemented parts of
> ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those
> specs which *no browser implements* we should call those out, and ask
> that the Charter explicitly dictate dropping them in the next version
> of ARIA for failure to get uptake.
>
I'd say there's at least one implementation (probably two) of most ARIA 1.1
stuff. I'm not sure about ARIA 1.2; I haven't even had a chance to look at
it yet.

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

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Çelik 
On Thu, Jul 26, 2018 at 8:57 PM, James Teh  wrote:
> That all seems reasonable from a process perspective. The only thing worth
> noting is that while you say there's no need to delay for years, that may
> well be what ends up happening, and Mozilla will essentially be "blocking
> progress" on this front.

If there were only two browser vendors (including Mozilla) then yes
your statement would be correct.

However, we have (at least) four major browser vendors, and thus it is
incorrect to assert that Mozilla alone could be "blocking progress"
when any 2 of the other 3 browser vendors could implement something
and have it exit CR.


> We want "limited resources" to drive better
> standards, yet with our resources in accessibility as limited as they are at
> this point, it's entirely likely we won't get around to implementing new
> ARIA stuff for years.

That may well be. If that is your assessment, we should add that to
our Charter response and be quite upfront that we are unlikely to
implement new ARIA stuff for (a few?) years, and perhaps ask
(non-F.O.) for the WG to be postponed accordingly.

In addition per your note about "still haven't implemented parts of
ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those
specs which *no browser implements* we should call those out, and ask
that the Charter explicitly dictate dropping them in the next version
of ARIA for failure to get uptake.


> At that point, we have a conflict: we have Mozilla
> objecting to the minimum implementation exception, while at the same time
> not resourcing accessibility sufficiently to make any reasonable progress at
> all. I'm not sure we can have it "both ways".

This is absolutely not in conflict, because as noted, 2 of the other 3
browser vendors can make progress independent of Mozilla.

What we are saying is we are against any accessibility features being
"standardized" for which their interoperable implementability is
unproven (by anyone, not just by us).

It is much worse to have something out there claiming to be a standard
(a W3C Recommendation), when either no one is supporting it (hence
fiction), or there is only one implementation (not a standard, because
there is no interop).

Tantek


> On Fri, Jul 27, 2018 at 11:27 AM, Tantek Çelik 
> wrote:
>>
>> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
>> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
>> > wrote:
>> >
>> >> So some comments on the ARIA charter at
>> >> https://www.w3.org/2018/03/draft-aria-charter :
>> >> ...
>> >> I guess it seems OK to have only one implementation
>> >> if there's really only going to be one implementation on that
>> >> platform... but allowing it in general (i.e.,  seems less than ideal,
>> >
>> > It is. However, the problem is that accessibility in general is severely
>> > lacking in resources across browser vendors (especially Mozilla!; we're
>> > currently working with just 2 engineers). Even where browser vendors
>> > agree
>> > on how something *should* be done, it often takes months or years before
>> > it
>> > gets implemented, primarily due to the aforementioned resource shortage.
>> > We
>> > (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA
>> > 1.2.
>> > The reality is that if multiple implementations were required for
>> > sign-off,
>> > it'd probably delay the process for years.
>>
>> Respectfully, I disagree with that use of process, and those
>> unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
>> have been dropped and/or postponed to future versions.
>>
>> The reality is that if a standard does not reflect what is
>> implemented/implementable (and yes, economic constraints / costs,
>> resource are a legitimate reason to criticize something as not being
>> implementable), then it should not be in the standard.
>>
>> A better answer when something lacks multiple implementations is:
>> 1. if there is only one implementation, move it to an informative
>> (non-normative) appendix
>> 2. if there are zero implementations, cut it and postpone it to the
>> next +0.1 version
>>
>> By following such a methodology, there is no need to delay "for
>> years". You ship the spec (go to PR) with what happens to be supported
>> as of that point in time, then work on the next +0.1 version to ship
>> the next year and repeat, hopefully increasing the number of features
>> that are interoperable implemented.
>>
>> > and
>> >> allowing only 75% of mappings to be implemented to count as
>> >> success seems pretty bad.
>> >>
>> > Same issue as above regarding limited resources.  Still, this one is a
>> > little more concerning because it raises questions about whether the
>> > remaining 25% will *ever* be implementable.
>>
>> Right, same issue with implementability, and same answer (1, 2 above).
>>
>> We (especially Mozilla) want "limited resources" to be a forcing
>> function to drive better standards, simpler to implement, test, debug,
>> secure, etc.
>>
>> No user benefits from

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh 
That all seems reasonable from a process perspective. The only thing worth
noting is that while you say there's no need to delay for years, that may
well be what ends up happening, and Mozilla will essentially be "blocking
progress" on this front. We want "limited resources" to drive better
standards, yet with our resources in accessibility as limited as they are
at this point, it's entirely likely we won't get around to implementing new
ARIA stuff for years. At that point, we have a conflict: we have Mozilla
objecting to the minimum implementation exception, while at the same time
not resourcing accessibility sufficiently to make any reasonable progress
at all. I'm not sure we can have it "both ways".

Jamie

On Fri, Jul 27, 2018 at 11:27 AM, Tantek Çelik 
wrote:

> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
> wrote:
> >
> >> So some comments on the ARIA charter at
> >> https://www.w3.org/2018/03/draft-aria-charter :
> >> ...
> >> I guess it seems OK to have only one implementation
> >> if there's really only going to be one implementation on that
> >> platform... but allowing it in general (i.e.,  seems less than ideal,
> >
> > It is. However, the problem is that accessibility in general is severely
> > lacking in resources across browser vendors (especially Mozilla!; we're
> > currently working with just 2 engineers). Even where browser vendors
> agree
> > on how something *should* be done, it often takes months or years before
> it
> > gets implemented, primarily due to the aforementioned resource shortage.
> We
> > (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA
> 1.2.
> > The reality is that if multiple implementations were required for
> sign-off,
> > it'd probably delay the process for years.
>
> Respectfully, I disagree with that use of process, and those
> unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
> have been dropped and/or postponed to future versions.
>
> The reality is that if a standard does not reflect what is
> implemented/implementable (and yes, economic constraints / costs,
> resource are a legitimate reason to criticize something as not being
> implementable), then it should not be in the standard.
>
> A better answer when something lacks multiple implementations is:
> 1. if there is only one implementation, move it to an informative
> (non-normative) appendix
> 2. if there are zero implementations, cut it and postpone it to the
> next +0.1 version
>
> By following such a methodology, there is no need to delay "for
> years". You ship the spec (go to PR) with what happens to be supported
> as of that point in time, then work on the next +0.1 version to ship
> the next year and repeat, hopefully increasing the number of features
> that are interoperable implemented.
>
> > and
> >> allowing only 75% of mappings to be implemented to count as
> >> success seems pretty bad.
> >>
> > Same issue as above regarding limited resources.  Still, this one is a
> > little more concerning because it raises questions about whether the
> > remaining 25% will *ever* be implementable.
>
> Right, same issue with implementability, and same answer (1, 2 above).
>
> We (especially Mozilla) want "limited resources" to be a forcing
> function to drive better standards, simpler to implement, test, debug,
> secure, etc.
>
> No user benefits from unimplemented standards.
>
> If anything, such "specifiction" causes harm in that it can cause
> false expectations of what "works", wasting web developer time and
> resources.
>
> Tantek
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Makoto Kato 
Mark, does you or anyone update the document [*1] for new contributors?
This MDN page still uses mozreview's way, and current mozreview document in
readthedocs has exactly good for new contributors, but phabricator's
document [*2] isn't good for new comer because installation steps for
Windows users isn't enough (Some new contributors uses Windows according to
#introduction channel of IRC).  Should we ask to MDN content team?  Of
course, if arcanist is installed by ./mach bootstrap, it is no problem.


-- Makoto Kato

*1
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_Get_your_code_reviewed
*2 http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html

On Fri, Jul 27, 2018 at 3:37 AM, Mark Côté  wrote:

> To follow up on some previous threads, here is the plan for deprecating,
> archiving, and decommissioning MozReview.
>
> The MozReview shutdown deadline is approaching. Although enhanced
> commit-series support is still in progress (see update below), MozReview
> users should start familiarizing themselves with Phabricator now. We have a
> guide specifically for MozReview users to ease the transition (which will
> be updated when the commit-series work is finalized): https://moz-conduit.
> readthedocs.io/en/latest/mozreview-migration-guide.html
>
> From August 6 to August 20, use of MozReview will be restricted to updates
> to existing reviews. In other words, review cycles in progress will be
> given until August 20 to be completed, but no new commit series will be
> permitted.
>
> On August 20, we will remove public access to MozReview and archive
> patches. Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket. The “stub attachments” in
> Bugzilla that currently redirect to MozReview will be updated to link to
> the appropriate S3 bucket. Review flags and bug comments will be preserved.
>
> After archiving is complete and verified, the MozReview servers will be
> decommissioned.
>
> We will also be writing a simple redirection service to map specific
> MozReview reviews to associated BMO comments, review requests to associated
> bugs, and review-request diffs to the appropriate S3 buckets. This service
> will be up shortly after MozReview is decommissioned.
>
> We realize and apologize that this is a fairly short timeline; however,
> the current location of the MozReview servers is in the process of being
> shut down, and thus it is urgent that we decommission this service soon to
> allow an orderly exit.
>
> As for enhanced support for series of commits in Phabricator, the new
> command-line interface to submit, update, and apply series (bug 1471678) is
> currently in review. The first release will support Mercurial only, but
> git-cinnabar support will follow shortly (the code is designed with it in
> mind). Work on series support in Lando (bug 1457525) is progressing; we
> will be posting screenshots of the new UI shortly. It should be ready in
> 2-3 weeks.
>
> Please note that we eventually plan to decommission Splinter as well;
> however, we know we need some time to work out the kinks in Phabricator.
> Splinter will remain operational near-term, but we ask everybody to
> familiarize themselves with Phabricator and file bugs when things don't
> work. *Please do not wait for Splinter EOL to try Phabricator; we need your
> feedback before then in order to act on it.*
>
> Mark
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Çelik 
On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  wrote:
>
>> So some comments on the ARIA charter at
>> https://www.w3.org/2018/03/draft-aria-charter :
>> ...
>> I guess it seems OK to have only one implementation
>> if there's really only going to be one implementation on that
>> platform... but allowing it in general (i.e.,  seems less than ideal,
>
> It is. However, the problem is that accessibility in general is severely
> lacking in resources across browser vendors (especially Mozilla!; we're
> currently working with just 2 engineers). Even where browser vendors agree
> on how something *should* be done, it often takes months or years before it
> gets implemented, primarily due to the aforementioned resource shortage. We
> (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA 1.2.
> The reality is that if multiple implementations were required for sign-off,
> it'd probably delay the process for years.

Respectfully, I disagree with that use of process, and those
unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
have been dropped and/or postponed to future versions.

The reality is that if a standard does not reflect what is
implemented/implementable (and yes, economic constraints / costs,
resource are a legitimate reason to criticize something as not being
implementable), then it should not be in the standard.

A better answer when something lacks multiple implementations is:
1. if there is only one implementation, move it to an informative
(non-normative) appendix
2. if there are zero implementations, cut it and postpone it to the
next +0.1 version

By following such a methodology, there is no need to delay "for
years". You ship the spec (go to PR) with what happens to be supported
as of that point in time, then work on the next +0.1 version to ship
the next year and repeat, hopefully increasing the number of features
that are interoperable implemented.

> and
>> allowing only 75% of mappings to be implemented to count as
>> success seems pretty bad.
>>
> Same issue as above regarding limited resources.  Still, this one is a
> little more concerning because it raises questions about whether the
> remaining 25% will *ever* be implementable.

Right, same issue with implementability, and same answer (1, 2 above).

We (especially Mozilla) want "limited resources" to be a forcing
function to drive better standards, simpler to implement, test, debug,
secure, etc.

No user benefits from unimplemented standards.

If anything, such "specifiction" causes harm in that it can cause
false expectations of what "works", wasting web developer time and
resources.

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

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh 
On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  wrote:

> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :
> ...
> I guess it seems OK to have only one implementation
> if there's really only going to be one implementation on that
> platform... but allowing it in general (i.e.,  seems less than ideal,

It is. However, the problem is that accessibility in general is severely
lacking in resources across browser vendors (especially Mozilla!; we're
currently working with just 2 engineers). Even where browser vendors agree
on how something *should* be done, it often takes months or years before it
gets implemented, primarily due to the aforementioned resource shortage. We
(Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA 1.2.
The reality is that if multiple implementations were required for sign-off,
it'd probably delay the process for years.

and
> allowing only 75% of mappings to be implemented to count as
> success seems pretty bad.
>
Same issue as above regarding limited resources.  Still, this one is a
little more concerning because it raises questions about whether the
remaining 25% will *ever* be implementable.

Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.
>
Ah, yes, that does seem like a problem.

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

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Mike Hommey 
On Thu, Jul 26, 2018 at 06:31:34PM -0400, Mark Côté wrote:
> The problem there is that the review repo will be bundled and stored. We
> don't want to run another Mercurial server indefinitely. Although, if the
> parent is a public changeset (as I believe most are), we could put a link
> to that commit in mozilla-central somewhere.

Does it need to be "another mercurial server", though? It could be
moved to hg.mozilla.org, under some archive hierarchy or something.
Or its heads could be added to try (for the gecko mozreview repo).

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

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Mark Côté 
The problem there is that the review repo will be bundled and stored. We
don't want to run another Mercurial server indefinitely. Although, if the
parent is a public changeset (as I believe most are), we could put a link
to that commit in mozilla-central somewhere.

Mark


On Thu, Jul 26, 2018 at 5:55 PM, Karl Tomlinson  wrote:

> Mark Côté writes:
>
> > On August 20, we will remove public access to MozReview and archive
> > patches. Every landed, in-progress, and abandoned patch will be
> downloaded
> > from MozReview and stored in an S3 bucket. The “stub attachments” in
> > Bugzilla that currently redirect to MozReview will be updated to link to
> > the appropriate S3 bucket. Review flags and bug comments will be
> preserved.
>
> > We will also be writing a simple redirection service to map specific
> > MozReview reviews to associated BMO comments, review requests to
> associated
> > bugs, and review-request diffs to the appropriate S3 buckets.
>
> Could the stub attachments and review-request diffs (but not
> interdiffs of course) redirect to the commits in the review repo
> (at https://reviewboard-hg.mozilla.org/gecko/ or wherever this
> ends up), please?
>
> The parent revision is important to the meaning of a patch, and
> it is not clear that navigation from the S3 buckets to the
> mercurial revisions in the review repo will be easy.
> ___
> 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: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Çelik 
On Thu, Jul 26, 2018 at 9:09 AM, L. David Baron  wrote:
> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :

tl;dr: We should show general support for work happening in this area
(per Jamie's email), however we should point out critical flaws in the
charter ("75%" etc.), formally object unless they are fixed, and add
explicit support/agreement with any other parties similarly formally
objecting.

Details inline:

> So one concern I've heard about these charters and that I probably
> share is that the ARIA charter says:
>
>   For every platform with mappings in an Accessibility API Mapping
>   specification, at least one implementation of 75% of the mappings
>   being tested on that platform will demonstrate implementability on
>   that platform. Multiple implementations of each platform are not
>   required because some platforms have only one implementation. For
>   features that are not platform-specific, passing test results in
>   at least two different implementations will be documented to
>   demonstrate implementability.
>
> This is a substantial weakening of the W3C's usual rules for
> demonstrating interoperability, and seems likely to be a bad
> precedent.

Yes and yes.

IIRC we had similar concerns about a previous Proposed Recommendation,
regarding the "at least one implementation ... on that platform", that
was accessibility related, and exiting CR without a confirmed (via
test suite) implementation for every feature. I can't seem to find it
in dev-platform however.

>  I guess it seems OK to have only one implementation
> if there's really only going to be one implementation on that
> platform...
> but allowing it in general (i.e.,  seems less than ideal, and

Is there some way we can ask to make this tighter (less loose)?

E.g. on platforms which only one existing implementation of previous
related spec(s)?

Like if a platform has multiple implementations already, then it is
reasonable to require 2+ implementations passing tests.

> allowing only 75% of mappings to be implemented to count as
> success seems pretty bad.

I read that as only 75% as being implementable, and 25% being
aspirational, which is not a good way to do standards, for anyone.  We
don't want specs with 25% specifiction.

We should insist that all features (including all mappings) be:
1. demonstrated to be implementable
2. pass the tests for them

If a feature is not implemented, or if it lacks tests, it should not
be able to exit CR.

We should formally object on this "75%" point.

> Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.

Agreed, we should insist (FO) that be fixed (removed?).

> I think otherwise this seems fine.

Those were the big problems I found as well.

We should see if anyone else has filed similar criticisms and
explicitly state agreement with any that seem to agree in spirit with
the problems we see.

> On Thursday 2018-07-12 16:06 +1000, James Teh wrote:
>> I (and others in the accessibility team) think we should support these
>> charters. The ARIA working group is especially important in the future
>> evolution of web accessibility. I have some potential concerns/questions
>> regarding the personalisation semantics specifications from APA, but
>> they're more spec questions at this point and I don't think they need to be
>> raised with respect to charter. Certainly, cognitive disabilities is an
>> area that definitely needs a great deal more attention on the web, and the
>> APA are seeking to do that.
>>
>> Thanks.
>>
>> Jamie
>>
>> On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:
>>
>> > The W3C is proposing revised charters for:
>> >
>> >   Accessible Platform Architectures (APA) Working Group
>> >   https://www.w3.org/2018/03/draft-apa-charter
>> >
>> >   Accessible Rich Internet Applications (ARIA) Working Group
>> >   https://www.w3.org/2018/03/draft-aria-charter
>> >
>> >   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
>> >
>> > Mozilla has the opportunity to send comments or objections through
>> > Friday, July 27.
>> >
>> > The changes relative to the previous charters are:
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Fapa-charter=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Faria-charter=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
>> >
>> > Please reply to this thread if you think there's something we should
>> > say as part of this charter review, or if you think we should
>> > support or oppose it.
>> >
>> > -David

Thanks,

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

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Karl Tomlinson 
Mark Côté writes:

> On August 20, we will remove public access to MozReview and archive
> patches. Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket. The “stub attachments” in
> Bugzilla that currently redirect to MozReview will be updated to link to
> the appropriate S3 bucket. Review flags and bug comments will be preserved.

> We will also be writing a simple redirection service to map specific
> MozReview reviews to associated BMO comments, review requests to associated
> bugs, and review-request diffs to the appropriate S3 buckets.

Could the stub attachments and review-request diffs (but not
interdiffs of course) redirect to the commits in the review repo
(at https://reviewboard-hg.mozilla.org/gecko/ or wherever this
ends up), please?

The parent revision is important to the meaning of a patch, and
it is not clear that navigation from the S3 buckets to the
mercurial revisions in the review repo will be easy.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Developer Outreach - Web Platform Research and Recommendations

2018-07-26 Thread James Graham 

On 26/07/2018 19:15, Dietrich Ayala wrote:


Why are we doing this?

The goals of this effort are to ensure that the web platform technologies we're 
investing in are meeting the highest priority needs of today's designers and 
developers, and to accelerate availability and maximize adoption of the 
technologies we've prioritized to meet these needs.


I think this is a great effort, and all the recommendations you make 
seem sensible.


Taking half a step back, the overriding goal seems to be to make 
developing for the web platform a compelling experience. I think one way 
to subdivide this overall goal is into two parts


* Ensure that the features that are added to the platform meet the 
requirements of content creators (i.e. web developers).


* Ensure that once shipped, using the features is as painless as 
possible. In particular for the web this means that developing content 
that works in multiple implementations should not be substantially more 
expensive than the cost of developing for a single implementation.


The first point seems relatively well covered by your plans; it's true 
that so far the approach to selecting which features to develop has been 
ad-hoc, and there's certainly room to improve.


The second point seems no less crucial to the long term health of the 
web; there is a lot of evidence that having multiple implementations of 
the platform is not a naturally stable equilibrium and in the absence of 
continued effort to maintain one it will drift toward a single dominant 
player and de-facto vendor control. The cheaper it is to develop content 
that works in many browsers, the easier it will be to retain this 
essential distinguishing feature of the web.


There are a number of things we can do to help ensure that the cost to 
developers of targeting multiple implementations is relatively low:


1) Write standards for each feature, detailed enough to implement 
without ambiguity.


2) Write a testsuite for each feature, ensure that it's detailed enough 
to catch issues and ensure that we are passing those tests when we ship 
a new feature.


3) Ensure that the performance profile of the feature is good enough 
compared to other implementations (in particular if it's relatively easy 
to hit performance problems in one implementation, that may prevent it 
being useful in that implementation even though it "works")


4) Ensure that developers using the feature have a convenient way to 
develop and debug the feature in each implementation.


5) Ensure that developers have a convenient way to do ongoing testing of 
their site against multiple different implementations so that it 
continues to work over time.


There are certainly more things I've missed.

On each of those items we are currently at a different stage of progress:

1) Compared to 14 years ago, we have got a lot better at this. Standards 
are usually written to be unambiguous and produce defined behaviour for 
all cases. Where they fall short of this we aren't always disciplined at 
providing feedback on the problems, and there are certainly other areas 
we can improve.


2) We now have a relatively well established cross-browser testsuite in 
web-platform-tests. We are still relatively poor at ensuring that 
features we implement are adequately tested (essentially the only 
process here is the informal one related to Intent to Implement emails) 
or that we actually match other implementations before we ship a feature.


3) Performance testing is obviously hard and whilst benchmarks are a 
thing, it's hard to make them representative of the entire gamut of 
possible uses of a feature. We are starting to work on more 
cross-browser performance testing, but this is difficult to get right. 
The main strategy seems to just to try to be fast in general. Devtools 
can be helpful in bridging the gap here if it can identify the cause of 
slowness either in general or in a specific engine.


4) This is obviously the role of devtools, making it convenient to 
develop inside the browser and possible to debug implementation-specific 
problems even where a developer isn't using a specific implementation 
all the time. Requiring devtools support for new features where it makes 
sense seems like a good step forward.


5) This is something we support via WebDriver, but it doesn't cover all 
features, and there seems to be some movement toward vendor-specific 
replacements (e.g. Google's Puppeteer), which prioritise the goal of 
making development and testing in a single browser easy, at the expense 
of cross-browser development / testing hard. This seems like an area 
where we need to do much better, by ensuring we can offer web developers 
a compelling story on how to test their products in multiple browsers.


So, to bring this back to your initiative, it seems that the only point 
above you really address is number 4 by recommending that devtools 
support is required for shipping new features. I fully agree that this 
is a good

Performance profiling improvements #2

2018-07-26 Thread Panos Astithas 
Hello there!

It has been almost 3 months since our last update on the Firefox Profiler.
In that time the Performance Tools team and our awesome contributors have
made numerous improvements that will hopefully make your jobs easier, for
all of you trying to make Firefox fast, for good.

Here are the highlights:

   -

   First of all we added documentation 
   including short videos, on how to use the profiler and some case studies
   about how performance investigations are often conducted. You can find
   links to the docs in the button list above the timeline and in the
   perf-html.io landing page.
   -

   Secondly, we added a new Network tab that contains information about the
   network requests that occurred during profiling. We plan to make this new
   panel look more like the devtools network panel soon.
   -

   Since the profiler can now collect network requests that sometimes
   contain privacy-sensitive information, the Share button has an additional
   checkbox in the popup panel to choose whether to include these network
   requests in the uploaded profile. This checkbox is unchecked by default to
   protect user privacy. If a profile has been shared without network
   information by mistake (and vice versa), an additional button to "Share
   with URLs" (or "Share without URLs") will appear next to the Permalink
   button.
   -

   There is also a new sidebar that can be opened from the button on the
   right side of the tab list to inspect individual stack frames in the Call
   Tree and Flame Graph, and soon in the rest of the panels as well.
   -

   The Call Tree now displays an activity category indicator (a colored
   box) next to the stack frame. The category types are color-coded and
   hovering over the colored box displays the category name in a tooltip (JS,
   Graphics, Layout, etc.). Soon we will start displaying the activity
   information in the thread timelines, which will make it easier to find the
   interesting parts at a glance.
   -

   Another useful visual polish is that selecting a time range by dragging
   the cursor over the timeline will now display the time range duration in
   the time breadcrumb bar. Zooming in on this range will add the duration to
   the breadcrumb bar, while deselecting the range will make it disappear.
   -

   The profiler is now smarter about idle threads that are rarely useful to
   inspect and hides them by default. They can be shown again using the thread
   context menu (right click on the thread list).
   -

   For things the profiler can't be smart about, we added configuration
   options to better fit the various use cases. The add-on panel used for
   starting and stopping the profiler now includes options to use a single
   thread for Stylo (sequential styling) and disable responsiveness probes,
   among others.
   -

   In that same panel, it is now possible to profile all threads of a
   specific process, instead of the specified threads in every process. The
   syntax to use for the former is, for example |pid=1234|, whereas the syntax
   for the latter is e.g. |GeckoMain,Compositor,StyleThread|.
   -

   Finally there is now support for profiling Fennec, by following the
   instructions in the docs
   . Soon we expect
   to be able to profile Focus Nightly that ships with GeckoView.


Feel like taking the profiler for a spin to check out all these new
features? That’s fantastic! While you do that, if you spot anything that
seems to be suboptimal, please file a bug and tag it with [qf] in the
whiteboard. Our performance team is eager for more performance bugs to
triage.

Happy profiling!

Panos, on behalf of the perf tools team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Mark Côté 
We aren't planning on archiving those to S3 buckets; that would add more
complexity, since we can't just scrape Review Board for them, and from what
we can tell not too many patches have unpublished historical context.

That said, and I forgot to mention this in my announcement, we'll be
putting a bundle of the review repo up on S3 as well for anyone who wants
to dig deeper.

Mark


On Thu, Jul 26, 2018 at 3:02 PM, Botond Ballo  wrote:

> On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté  wrote:
> > Every landed, in-progress, and abandoned patch will be downloaded
> > from MozReview and stored in an S3 bucket.
>
> I think I've asked this before, but plans were uncertain at the time:
> will the history of patches (i.e. otherwise unpublished ancestors that
> are currently stored in the MozReview repo) be archived as well?
>
> Thanks,
> Botond
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

2018-07-26 Thread Botond Ballo 
On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté  wrote:
> Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket.

I think I've asked this before, but plans were uncertain at the time:
will the history of patches (i.e. otherwise unpublished ancestors that
are currently stored in the MozReview repo) be archived as well?

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

Plan for Sunsetting MozReview

2018-07-26 Thread Mark Côté 
To follow up on some previous threads, here is the plan for deprecating,
archiving, and decommissioning MozReview.

The MozReview shutdown deadline is approaching. Although enhanced
commit-series support is still in progress (see update below), MozReview
users should start familiarizing themselves with Phabricator now. We have a
guide specifically for MozReview users to ease the transition (which will
be updated when the commit-series work is finalized):
https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html

From August 6 to August 20, use of MozReview will be restricted to updates
to existing reviews. In other words, review cycles in progress will be
given until August 20 to be completed, but no new commit series will be
permitted.

On August 20, we will remove public access to MozReview and archive
patches. Every landed, in-progress, and abandoned patch will be downloaded
from MozReview and stored in an S3 bucket. The “stub attachments” in
Bugzilla that currently redirect to MozReview will be updated to link to
the appropriate S3 bucket. Review flags and bug comments will be preserved.

After archiving is complete and verified, the MozReview servers will be
decommissioned.

We will also be writing a simple redirection service to map specific
MozReview reviews to associated BMO comments, review requests to associated
bugs, and review-request diffs to the appropriate S3 buckets. This service
will be up shortly after MozReview is decommissioned.

We realize and apologize that this is a fairly short timeline; however, the
current location of the MozReview servers is in the process of being shut
down, and thus it is urgent that we decommission this service soon to allow
an orderly exit.

As for enhanced support for series of commits in Phabricator, the new
command-line interface to submit, update, and apply series (bug 1471678) is
currently in review. The first release will support Mercurial only, but
git-cinnabar support will follow shortly (the code is designed with it in
mind). Work on series support in Lando (bug 1457525) is progressing; we
will be posting screenshots of the new UI shortly. It should be ready in
2-3 weeks.

Please note that we eventually plan to decommission Splinter as well;
however, we know we need some time to work out the kinks in Phabricator.
Splinter will remain operational near-term, but we ask everybody to
familiarize themselves with Phabricator and file bugs when things don't
work. *Please do not wait for Splinter EOL to try Phabricator; we need your
feedback before then in order to act on it.*

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

Developer Outreach - Web Platform Research and Recommendations

2018-07-26 Thread Dietrich Ayala 
Hello! Kadir Topal and I are on the Developer Outreach team, and have spent 
some time this year looking at web platform development and adoption patterns.

We presented some initial findings and recommendations at the San Francisco 
workweek, and are now looking for broader feedback from the Gecko developer 
community.

Why are we doing this?

The goals of this effort are to ensure that the web platform technologies we're 
investing in are meeting the highest priority needs of today's designers and 
developers, and to accelerate availability and maximize adoption of the 
technologies we've prioritized to meet these needs.

We've interviewed a number of Gecko developers and our standards-process 
participants, and looked at the overall lifecycle of some web features to 
identify pain points, bottlenecks and blind spots. We’ve also looked for 
patterns that were effective at driving multi-vendor implementation, or 
improving the rate of adoption by designers and developers.

Based on the work so far, we’ve initiated a few different efforts, and also 
have some recommendations for how we make and ship the web that best meet the 
needs of developers.

Research

One of the big gaps we've identified is around research. To our knowledge, no 
browser vendor is doing broad research into the needs of modern designers and 
developers for the purpose of influencing the direction of the web platform. 
And while we do a lot of usability research in browser features and our web 
properties, we don't do this with our web APIs and CSS properties. We're 
proposing two research efforts:

* Research services for Web platform development teams - A researcher will work 
with you to find the right audience and gather their feedback through surveys 
and real user testing as you’re building web platform features. We're 
interviewing candidates now for a contract position to trial this.

* Annual MDN Developer Needs Report - We'll publish an annual report of 
designer and developer needs, both on the web and off of it, to help guide 
prioritization of web platform development efforts.

Measurability

The web platform contains >9k unique parts 
(https://twitter.com/dietrich/status/998978915912663040). We're measuring a 
tiny percentage of it, and only on Nightly. Some browser vendors measure some 
parts of CSS and share those numbers publicly, but we need to measure real 
world usage of high-priority features in Firefox in order to reasonably 
determine whether the features we’re investing in are actually being adopted by 
Firefox users. Measurability is also key to understanding if our adoption 
efforts in Developer Outreach and Developer Marketing are actually having 
impact over time.

We've started work to expand Gecko’s use-counters to cover more of the web 
platform and also to turn on reporting on the release channel.

Some challenges are ensuring no PII in the reported data, that client-side 
performance isn’t impacted, and determining an effective sample size for 
meaningful results without overwhelming data processing requirements on the 
server.

Bug for enabling use-counters on release: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1477433

Bug for auto-generating use-counters in WebIDL: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1470241

Web Platform Development Recommendations

From the work so far, we've identified a few actions we're recommending to 
product owners, module owners, reviewers and developers:

* 1. Use-counters: As mentioned above, we’re enabling use-counters on release. 
We recommend that teams and reviewers request that use-counters are added in 
patches for new web platform features.

* 2. Tools: We’re recommending that new web features ship with devtools support 
in the same release to maximize adoption. This is already happening to some 
extent, but should be the default.

* 3. Use the MDN Developer Needs report for guidance in deciding what to 
implement, and prioritization. Ok, this doesn’t exist yet. But when it does, we 
should use it as an input when determining where we put engineering time.

What we need from you...

* What do you think about the recommendations above? What challenges do you 
see? What solutions do you recommend?

* What research should we do next? We’re considering further research into 
things like identification of complexity in the web stack for web designers and 
developers, a better articulation of which use-cases make the web *not* an 
option, and whole-lifecycle workflows (eg, developers consider “server side” as 
part of the web, while browser vendors might not). What research would help you 
in your work making Gecko?

* Do you have ideas for maximizing adoption? We’re only looking at a few small 
areas that we think we can have impact. What else should we be looking at?

Thanks,

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

Re: Intent to implement: Visual Viewport API

2018-07-26 Thread tpodder 
On Monday, July 23, 2018 at 10:22:48 PM UTC-4, Boris Zbarsky wrote:
> On 7/23/18 7:36 PM, Tanushree Podder wrote:
> > Secure contexts: Yes
> 
> I'm not sure what this line means here.  The spec does not restrict this 
> API to secure contexts, right?  Do we plan to thus restrict it in our 
> implementation?
> 

Chrome supports the Visual Viewport API for non-secure contexts. As the spec 
does not mention any restrictions to secure contexts, we will also default to 
Chrome's behavior and make the API available to non-secure contexts for now. 
However, I have filed an issue 
(https://github.com/WICG/visual-viewport/issues/57) to discuss if the API 
should be restricted to secure contexts.  

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

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread L. David Baron 
So some comments on the ARIA charter at
https://www.w3.org/2018/03/draft-aria-charter :

So one concern I've heard about these charters and that I probably
share is that the ARIA charter says:

  For every platform with mappings in an Accessibility API Mapping
  specification, at least one implementation of 75% of the mappings
  being tested on that platform will demonstrate implementability on
  that platform. Multiple implementations of each platform are not
  required because some platforms have only one implementation. For
  features that are not platform-specific, passing test results in
  at least two different implementations will be documented to
  demonstrate implementability.

This is a substantial weakening of the W3C's usual rules for
demonstrating interoperability, and seems likely to be a bad
precedent.  I guess it seems OK to have only one implementation
if there's really only going to be one implementation on that
platform... but allowing it in general (i.e.,  seems less than ideal, and
allowing only 75% of mappings to be implemented to count as
success seems pretty bad.


Also, the two references to a deliverable of the SVG working group
when the SVG working group isn't currently chartered seems
problematic.


I think otherwise this seems fine.

-David

On Thursday 2018-07-12 16:06 +1000, James Teh wrote:
> I (and others in the accessibility team) think we should support these
> charters. The ARIA working group is especially important in the future
> evolution of web accessibility. I have some potential concerns/questions
> regarding the personalisation semantics specifications from APA, but
> they're more spec questions at this point and I don't think they need to be
> raised with respect to charter. Certainly, cognitive disabilities is an
> area that definitely needs a great deal more attention on the web, and the
> APA are seeking to do that.
> 
> Thanks.
> 
> Jamie
> 
> On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:
> 
> > The W3C is proposing revised charters for:
> >
> >   Accessible Platform Architectures (APA) Working Group
> >   https://www.w3.org/2018/03/draft-apa-charter
> >
> >   Accessible Rich Internet Applications (ARIA) Working Group
> >   https://www.w3.org/2018/03/draft-aria-charter
> >
> >   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, July 27.
> >
> > The changes relative to the previous charters are:
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
> > 2Fwww.w3.org%2F2015%2F10%2Fapa-charter=https%3A%
> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
> > 2Fwww.w3.org%2F2015%2F10%2Faria-charter=https%3A%
> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
> >
> > -David
> >
> > --
> > 턞   L. David Baron http://dbaron.org/   턂
> > 턢   Mozilla  https://www.mozilla.org/   턂
> >  Before I built a wall I'd ask to know
> >  What I was walling in or walling out,
> >  And to whom I was like to give offense.
> >- Robert Frost, Mending Wall (1914)
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> >

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stopgap for Commit Series in Phabricator

2018-07-26 Thread Kris Maglione 
Here's an approximate equivalent for hg which doesn't require 
Arcanist:


https://bitbucket.org/kmaglione/hgext/src/default/phabricator.py

It's a slightly modified version of stock hg Phabricator plugin 
(which we apparently have gps to thank for inspiring) which 
handles parsing bug IDs and reviewers from commit messages.


You just need to add something like this to your .hgrc:

[phabricator]
url = https://phabricator.services.mozilla.com/
callsign = MOZILLACENTRAL

[auth]
mozilla.schemes = https
mozilla.prefix = phabricator.services.mozilla.com
mozilla.phabtoken = cli-...

and then use `hg phabsend` to push a commit series (or `hg phabread` 
to import one).


On Wed, Jul 25, 2018 at 04:31:51PM -0400, Nika Layzell wrote:

While our services team is working on making a reliable & maintained tool
for handling commit series with Phabricator, I threw together something
small to use as a stop-gap for pushing large commit series to Phabricator
and updating them.

It currently works as a wrapper around Arcanist, and *only supports git*
(as I don't know how hg works enough to get it to work reliably), but
should allow pushing a range of commits as revisions without touching the
working tree, automatic dependency relationships, bug number filling, and
reviewer field population.

I called it 'phlay' (splinter => flay; flay + phabricator => phlay).

GitHub: https://github.com/mystor/phlay
Tweet w/ short demo clip:
https://twitter.com/kneecaw/status/1021434807325163523

I've used it to push pretty-much all of my recent patch series to
Phabricator, and it's saved me a good amount of time, so I figured I'd let
people know. Feel free to poke me on IRC if you have questions.

- nika


--
Kris Maglione

[T]he people can always be brought to the bidding of the leaders.
That is easy.  All you have to do is tell them they are being attacked
and denounce the pacifists for lack of patriotism and exposing the
country to danger.  It works the same way in any country.
--Herman Göring

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