Re: Want to learn TLS certificate verification best practices

[Ben Cottrell]

Hi Gervase,

On Mon, Oct 03, 2016 at 09:49:20AM +0100, Gervase Markham wrote:
> This question might be better off in mozilla.dev.tech.crypto.

OK, understood. Thanks for the redirect.

Although, you've given me enough to chew on already that I'm not
likely to immediately go post over there, either. I think your
response was immensely helpful, specifically the pointer to Brian
Smith. His writeup at  is
very much along the lines of the kind of best-practices document
I was hoping to find.

I'm going to go away and chew on RFC4158 (which I wasn't aware
of previously) for a while, and if I have more questions after
that I will post on mozilla.dev.tech.crypto.

You rock! Thanks!

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

Intent to ship: TouchEvents (Windows), touch-action (all platforms), accessible caret

[Kartikaya Gupta]

In Firefox 52 I intend to ship support for TouchEvents on Windows
e10s. TouchEvent support has already been enabled on Android for a
long time and has been enabled on Linux e10s as well (if you have
MOZ_USE_XINPUT2=1 in your environment). The pref that controls this
feature is dom.w3c_touch_events.enabled. The pref has been enabled on
Nightly for a number of months, and bug 1244402 is now letting it ride
the trains. Chrome/Opera and Safari on iOS all support Touch Events,
and it is specced at [1].

Additionally, I also intend to ship support for the CSS touch-action
property, which is defined in the Pointer Events spec [2]. Note that
our support for touch-action currently does NOT include support for
the Pointer Events Level 2 property values such as pan-up/pan-down.
Touch-action will be supported on all platforms that support touch
input (i.e. Android, Linux e10s with MOZ_USE_XINPUT2=1, and Windows
e10s). The pref that controls this feature is
layout.css.touch_action.enabled. This pref has also been enabled on
Nightly for a number of months now and bug 1244402 is letting it ride
the trains. Touch-action is supported in IE/Edge, Chrome/Opera, and
partly in Safari.

Note also that along with enabling these features, touch scrolling on
Windows e10s will now be handled natively by APZ in the compositor
rather than being converted into wheel events by the OS, which should
enhance scrolling responsiveness and control. To round out touch
support, we are also enabling the "accessible caret" for text
selection on desktop platforms where TouchEvents are supported. This
allows the user to manipulate text selection using the touch-friendly
carets you already see in Firefox for Android. This is controlled by
the pref layout.accessiblecaret.enabled_on_touch. As with the
web-facing features, these have been enabled on Nightly builds for a
while and now are going to ride the trains.

Aside 1: on current Nightly, you *still* need to set
browser.tabs.remote.force-enable to true on Windows touch devices to
get e10s enabled. This is due to the instability caused by some
accessibility code, but the plan is to have those bugs fixed and that
restriction eliminated in Firefox 52 as well, hopefully within the
next week or two.

Aside 2: sorry for lumping all these things in one email, but they're
all related and mostly need to ship together.

Cheers,
kats

[1] https://www.w3.org/TR/touch-events/
[2] https://www.w3.org/TR/pointerevents/ (section 9)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: upcoming meeting announcement - intermittent orange hacking

[Ehsan Akhgari]

Given the platform-wide D&I meeting scheduled for the same date and time,
is this going to be rescheduled for this week?

Thanks!

On Mon, Oct 3, 2016 at 3:01 PM, jmaher  wrote:

> Every 2 weeks on Friday at 9 PDT [1] we will be hosting a meeting to
> discuss intermittent oranges.  The format will be a chance for people with
> previous topics to relate status and findings, then the rest of the meeting
> discuss and surface ideas to consider investigating more.
>
> Our topics for the October 7th meeting are:
> * [jmaher] defining intermittent oranges (are there logical categories we
> can break failures into?)
> * [gbrown] disabling unreliable tests (sheriffs point of view vs
> developers point of view, and what makes sense to ship a quality product)
>
> Please consider joining us or reaching out to us to give input, share
> ideas and your perspective.
>
> I do not plan to post ahead of every meeting, but I will mention in
> November where we are as well as options to learn more at an upcoming work
> week.
>
> [1] https://wiki.mozilla.org/Auto-tools/Projects/Stockwell/Meetings
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



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

Re: Removal of B2G from mozilla-central

[Axel Hecht]

On 04/10/16 17:40, Fabrice Desre wrote:

On 10/04/2016 08:34 AM, Axel Hecht wrote:


I'd favor to remove at least anything related to l10n from b2g. It never
really worked, and is a half-maintained copy of the almost-working stuff
in mobile.

In my local branches that try to create a test on broken l10n
infrastructure, both mobile and b2g show up, and my preferred way to fix
b2g would be to remove it (the l10n parts).


What b2g specific l10n parts are you talking about? Can you provide links?



https://dxr.mozilla.org/mozilla-central/source/b2g/locales/jar.mn has a 
bunch of overrides, and many of those are wrong also for fennec.


b2g isn't as horrible as mobile is as it doesn't use the "browser" 
chrome package, but still.


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

Re: Removal of B2G from mozilla-central

[Axel Hecht]

On 04/10/16 12:16, Gabriele Svelto wrote:

* b2g

   ~20K lines which would also drop considerably due to the removal of
the APIs, completely self-contained



I'd favor to remove at least anything related to l10n from b2g. It never 
really worked, and is a half-maintained copy of the almost-working stuff 
in mobile.


In my local branches that try to create a test on broken l10n 
infrastructure, both mobile and b2g show up, and my preferred way to fix 
b2g would be to remove it (the l10n parts).


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

Re: Removal of B2G from mozilla-central

[Fabrice Desre]

On 10/04/2016 08:34 AM, Axel Hecht wrote:


I'd favor to remove at least anything related to l10n from b2g. It never
really worked, and is a half-maintained copy of the almost-working stuff
in mobile.

In my local branches that try to create a test on broken l10n
infrastructure, both mobile and b2g show up, and my preferred way to fix
b2g would be to remove it (the l10n parts).


What b2g specific l10n parts are you talking about? Can you provide links?

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

Re: Removal of B2G from mozilla-central

[Gabriele Svelto]

On 04/10/2016 01:22, Gregory Szorc wrote:
> https://dxr.mozilla.org/mozilla-central/search?q=gonk seems to
> contradict your assertion that gonk is well-contained.

I thought that the analysis in my first post was sufficiently detailed
but here's one with line numbers to get a more accurate idea:

- All gonk references and code in the following directory will be
removed entirely because it's needed only for B2G-specific APIs and
those are already being removed. This means that the following top-level
directories will be purged of all gonk-specific code:

* accessible
* addon-sdk
* browser
* caps
* chrome
* devtools
* docshell
* dom (save for a few lines in dom/media, see below)
* embedding
* extensions
* hal (save for a single file)
* image
* intl
* ipc
* layout
* memory
* modules
* mozglue
* netwerk
* parser
* rdf
* security
* storage
* testing
* toolkit
* tools
* uriloader (not 100% sure, but it's 3 files anyway)
* xpcom (what's being done could be handled externally from gecko)
* xpfe

What would remain is the following; first the actual code:

* widget/gonk - roughly ~50K lines but would drop to ~40K once we drop
suppport for older Android versions as well as APIs that have been removed

* b2g

  ~20K lines which would also drop considerably due to the removal of
the APIs, completely self-contained

* dom/media

  ~4K lines, which would be cut down once camera & overlay support are
removed as well as the phone-specific, non-standard video and audio
formats. The rest of the code is mostly self-contained within
gonk-specific files

* gfx

  ~2K lines a significant amount of which are related to camera and
screen recording code that can be removed

* hal

  Only one file would be kept in hal/gonk of ~2K lines (which are likely
to be reduced once support for non-standard APIs is removed). A handful
of lines would remain in hal/Hal.cpp and hal/Hal.h but if we drop the
process priority manager (which I would do) those would also go. ~10
lines in hal/linux/LinuxPower.cpp

* media

  Less than 1K lines, some of which are shared with Fennec and some
which can be easily removed (e.g. they were used only on certain
devices/versions)

Then the configuration bits

* build - 10 lines shared with Fennec
* config -  One line, could be possibly removed
* js - 2 lines
* nsprpub - 7 lines
* python - ~50 lines
* xpcom

All in all we're talking about less than ~70K lines which would likely
drop to less than ~50K lines once we've removed all the non-standard
APIs. Of these most are self-contained save for gfx, media and dom/media
which are arguably the ones where there's more intermingling between
gonk-specific code and the rest though it's only a handful of lines.

> There are
> literally references to gonk throughout the tree. Every reference that
> isn't self-contained introduces cognitive dissonance when someone
> encounters it. They have to consider the existence of gonk when reading
> and changing the code. This makes changing code harder and undermines
> the ability for Firefox/Gecko to "evolve quickly." Even the very
> presence of unused, self-contained code (like gonk widgets) adds
> overhead because it can make common operations like refactoring more
> time consuming. And if someone breaks the code (because it isn't used)
> and a bug gets filed to track that, now you've introduced overhead for
> people to triage said bugs. These problems don't exist when the code
> doesn't exist. That's why we should aggressively delete unused and
> unsupported code.

While I can relate to that this also discounts the advantage which we
would have by retaining the code which is the ability to deploy gecko on
Android-based devices directly. That's something that proved to be
useful outside of the phone domain.

Also we're talking about a tier 3 platform which means that if a
refactoring breaks it, it will be up to the people that are involved
with it to fix it. IIRC bugs for tier 3 platforms are not triaged either
so that shouldn't be a problem.

Besides there's unsupported code that's been living in our codebase for
ages and nobody seemed to be bothered by it. Searching for references to
long-defunct platforms such as Maemo, MeeGo or OS/2 still yields results
in our codebase.

 Gabriele



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