Accessibility review process

2020-11-11 Thread James Teh
(Also cross-posting to firefox-dev.)

Hi all,

Tl;dr: The Mozilla Accessibility Release Guidelines outline what is needed
to make user interfaces accessible to people with disabilities. If you
would like help from the accessibility team to determine whether your
change is accessible, you can now set the a11y-review flag on a bug in
Bugzilla and fill in the comment template.

While the accessibility team has always performed accessibility reviews,
the process around this has hitherto been very ad hoc and unclear. To
address this, we have now formalised the process for requesting an
accessibility review. You can find it documented here:

https://firefox-source-docs.mozilla.org/bug-mgmt/processes/accessibility-review.html

For convenience, I've included the text at the bottom of this email.

This process references the Mozilla Accessibility Release Guidelines, which
have existed for a while but haven't been widely publicised. Among other
things, you can use these as a checklist to guide you in what to consider
to ensure an accessible user interface, whether that be during design,
development or determining shipping readiness. That document is here:

https://wiki.mozilla.org/Accessibility/Guidelines

If you have any questions or feedback, please feel free to reach out to me
directly.

Thanks!

jamie
--
Accessibility Review Introduction

At Mozilla, accessibility is a fundamental part of our mission to ensure
the internet is "open and accessible to all," helping to empower people,
regardless of their abilities, to contribute to the common good.
Accessibility Review is a service provided by the Mozilla Accessibility
team to review features and changes to ensure they are accessible to and
inclusive of people with disabilities.
Do I Need Accessibility Review?

You should consider requesting accessibility review if you aren't certain
whether your change is accessible to people with disabilities.
Accessibility review is optional, but it is strongly encouraged if you are
introducing new user interface or are significantly redesigning existing
user interface.
When Should I Request Accessibility Review?

Generally, it's best to request accessibility review as early as possible,
even during the product requirements or UI design stage. Particularly for
more complex user interfaces, accessibility is much easier when
incorporated into the design, rather than attempting to retro-fit
accessibility after the implementation is well underway.

The accessibility team has developed the Mozilla Accessibility Release
Guidelines  which
outline what is needed to make user interfaces accessible. To make
accessibility review faster, you may wish to try to verify and implement
these guidelines prior to requesting accessibility review.

The deadline for accessibility review requests is Friday of the first week
of nightly builds for the release in which the feature/change is expected
to ship. This is the same date as the PI Request deadline.
How Do I Request Accessibility Review?

You request accessibility review by setting the a11y-review flag to
"requested" on a bug in Bugzilla and filling in the template that appears
in the comment field. For features spanning several bugs, you may wish to
file a new, dedicated bug for the accessibility review. Otherwise,
particularly for smaller changes, you may do this on an existing bug. Note
that if you file a new bug, you will need to submit the bug and then edit
it to set the flag.
Questions?

If you have any questions, please don't hesitate to contact the
Accessibility team:

   - #accessibility on Matrix
   

   or Slack
   - Email: accessibil...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Enabled CRLite in Nightly

2020-11-11 Thread Martin Thomson
Great news JC.

I've been watching this with interest.  It's one of those rare cases
where we get a win-win-win.  Faster page loads, better security
through more reliable revocation information, and better privacy.

It's taken a lot of effort, but it's definitely worth it.

On Thu, Nov 12, 2020 at 8:08 AM J.C. Jones  wrote:
>
> CRLite ships compressed revocation information for the public Web to
> Firefox users, four times a day. We have a blogpost series on CRLite at the
> Security Blog  (with another
> post coming later this month), there’s additional information at Github
> , and for the Gecko-side, a meta-bug
> .
>
> We’ve been collecting telemetry on how much CRLite can speed up first TLS
> connections
> 
> all year. Since August, we’ve been publishing the datasets consistently
> four times per day, with “stashes” (delta updates) averaging about 66 kB. (
> https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters
> )
>
> If you’d like to poke around inside the filter data, see
> https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter
>
> Nightly is now preferring CRLite  for
> revocation information, meaning fresh TLS connections will skip OCSP when
> CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
> “Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
> telemetry: it’s mostly expected to speed up the outliers in the graph,
> since revocation checks get cached, and it is likely to have the largest
> effects for Firefox users with slower network connections.
>
> We don’t expect breakage from this change, as we’ve grown fairly confident
> in the dataset, but this is going to remain in Nightly for now.
>
> After this speed-up testing, our likely next step is to add telemetry to
> compare live OCSP results against CRLite’s results for outlier-accuracy
> (encountering revocations is rare, so care is needed). We’ll ultimately run
> both the accuracy and the speedup tests in early Beta as well.
>
> We’ll develop Release-path plans based on early Beta testing and telemetry.
>
> For more information, come see us in #crlite in Slack or #crlite:mozilla.org
> on Matrix
> 
> .
>
> - J.C. on behalf of Mozilla Crypto Engineering
> ___
> 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


Enabled CRLite in Nightly

2020-11-11 Thread J.C. Jones
CRLite ships compressed revocation information for the public Web to
Firefox users, four times a day. We have a blogpost series on CRLite at the
Security Blog  (with another
post coming later this month), there’s additional information at Github
, and for the Gecko-side, a meta-bug
.

We’ve been collecting telemetry on how much CRLite can speed up first TLS
connections

all year. Since August, we’ve been publishing the datasets consistently
four times per day, with “stashes” (delta updates) averaging about 66 kB. (
https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters
)

If you’d like to poke around inside the filter data, see
https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter

Nightly is now preferring CRLite  for
revocation information, meaning fresh TLS connections will skip OCSP when
CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
“Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
telemetry: it’s mostly expected to speed up the outliers in the graph,
since revocation checks get cached, and it is likely to have the largest
effects for Firefox users with slower network connections.

We don’t expect breakage from this change, as we’ve grown fairly confident
in the dataset, but this is going to remain in Nightly for now.

After this speed-up testing, our likely next step is to add telemetry to
compare live OCSP results against CRLite’s results for outlier-accuracy
(encountering revocations is rare, so care is needed). We’ll ultimately run
both the accuracy and the speedup tests in early Beta as well.

We’ll develop Release-path plans based on early Beta testing and telemetry.

For more information, come see us in #crlite in Slack or #crlite:mozilla.org
on Matrix

.

- J.C. on behalf of Mozilla Crypto Engineering
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Fission Newsletter #9

2020-11-11 Thread Neha Kochar
Greetings Everyone,

A lot has been accomplished since our last newsletter so we are back with
more Fission news in our Newsletter #9.

Experimenting with Fission in Nightly

With the completion of Fission milestone M6b, Fission Nightly experiment
was launched for 5% of Nightly on October 13. We observed surprisingly good
results in the first three weeks and decided to increase the experiment
percentage to 10% of Nightly on November 3. We continue to monitor the
results and the experiment data

is looking very good. One of the notable impressive ones is lower
checkerboarding severity with Fission enabled (read here

if you’re interested in finding out what does checkerboarding represent).


Other performance and memory probes are also showing Fission results within
the noise level when compared to the non-Fission measurements, which is
great!. Below are some examples of this.




Arriving at the Finish Line

We are very glad to report the completion of Frontend migration of all
framescripts to JSActors. Also, equally happy to report that printing of
out-of-process iframes is now working and complete. If you still see any
issues, please report them for the `Core::Printing:Output` component
blocking the meta printing-fission
 bug.

Fission Performance

Visual metrics performance dashboards have been added for Fission at
https://arewefastyet.com
 for
Linux64. Some of the sites are showing performance regressions for Fission
and we are looking into debugging and adding optimizations to improve those.

Session Storage Moved to the Parent Process

One of the major themes with Fission has been the move from content
processes to parent process. Continuing with that theme, Session Storage
has also been moved to the parent process in Bug 1654080
.

See your processes

Fission added a new about:processes page to show users more information
about the different processes Firefox uses and the corresponding origins
loaded in them. It groups the same sites from different tabs and frames
together for better readability and shows corresponding CPU and memory
usage. Double-clicking on any row representing a tab in about:processes
will take you to that tab. Also, the last column in about:processes allows
the user to kill a tab or a process by clicking on the ‘x’. Bug 1674084
 enabled
about:processes to ride the trains starting with Firefox 84.


Help Firefox get Fission-ready

You can help us test Fission on Firefox Nightly by enabling Fission in
about:preferences#experimental followed by restarting Firefox for it to
take effect.


For any follow-ups or comments or questions, you can find us at #fission in
Slack and Matrix/Element.

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