Intent to implement and ship: CSS property touch-action:pinch-zoom

[Kartikaya Gupta via dev-platform]

We intend to enable the following feature in m-c soon, and ship it in Gecko 
85.

Summary:
Support for the "pinch-zoom" keyword value for the touch-action CSS 
property

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

Standard:
https://compat.spec.whatwg.org/#touch-action

Platform coverage:
All (desktop and Android)

Preference:
touch-action is already behind the layout.css.touch_action.enabled pref 
(enabled by default) and this new value will be covered by the same pref. 

DevTools bug:
none, I don't believe this requires any specific devtools work

Other browsers:
According to 
https://caniuse.com/mdn-css_properties_touch-action_pinch-zoom Chrome has 
supported this since v56 (~Jan 2017); IE/Edge have supported it since Oct 
2013 or inception; Safari has supported it since v13 (~Sep 2019). We're the 
only major browser that doesn't support it yet.

web-platform-tests:
Covered by web-platform/tests/pointerevents/compat/
Additionally tested by some Gecko-specific mochitests that exercise the 
Gecko compositor hit-testing codepath.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[futsysg]

Op zondag 29 maart 2020 08:24:06 UTC+2 schreef Emilio Cobos Álvarez:
> Hey, a quick web-observable change that may deserve a bit more 
> visibility / an intent.
> 
> I'd welcome some feedback, specially from the fingerprinting / privacy 
> angle (where I'm clearly not an expert).
> 
> Summary: A page redirecting / navigating to an unknown protocol will be 
> silently ignored (and logged to the DevTools console) instead of showing 
> an error page. This is not amazing, but it's needed because it causes a 
> bunch of compat issues (see the list of issues in the bug below).
> 
> There are a few subtle problems here. Part of the issue is that authors 
> don't have a cross-browser way of detecting whether a protocol will be 
> handled externally (that is, whether an app is installed to handle a 
> given protocol).
> 
> They technically can in Firefox (see example below). It's unclear 
> whether we want to expose more than that, or that at all.
> 
> Given Chrome just ignores the navigation if they can't handle it, some 
> authors (who don't seem to test on other browsers ;)) just spam the 
> redirect (using various methods like the location href setter / meta 
> refresh / whatevs). This works just fine in Chromium-based browsers, but 
> not in Firefox or Safari, which will just show an error, which causes a 
> very frustrating experience for users.
> 
> As far as I know, this behavior doesn't really expose more information 
> than we were exposing before. In a test-case like:
> 
>
>
> 
> we have different behavior also before this patch: the contentDocument 
> for the handled-protocol iframe will be accessible to content, and be 
> about:blank. The contentDocument for the unhandled protocol will be the 
> error page, which will not be accessible to content and thus be null.
> 
> Other browsers seem to do about:blank for both iframes, but you can also 
> detect this in all browsers via window.open instead (there may be other 
> ways around it too, haven't dug all that much). Chrome insta-closes the 
> handled protocol window (so you can check window.closed). Firefox / 
> Safari will leave about:blank in that window, and show an error document 
> for the second (which will throw a security error on access).
> 
> So I don't think this change introduces a new privacy hole. That being 
> said, this all seems a bit sad, and a somewhat-serious potential 
> fingerprinting factor. I was in fact a bit nervous about this change 
> before realizing we were already exposing this information in other 
> (even simpler to test) ways... But I'm clearly not an expert on this matter.
> 
> There are mitigations possible both for the ignored-navigation case 
> (maybe only ignore the navigation to an unknown protocol once per 
> document or something, and only for browsing contexts that can't be 
> accessed by any ancestor JS? not sure) and the iframe case (probably 
> just not show error pages in frames?). Please let me know if I you think 
> I should file this and follow-up on it.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305
> 
> Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
> allows for both the old and new behavior, as far as I (and Anne) can 
> tell. This uses urls after redirect and so on so beforeunload and such 
> will fire. This matches the behavior of Chromium browsers.
> 
> Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it 
> a bit more).
> 
> Devtools bug: N/A, ignored navigations get logged to the console.
> 
> Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
> This was causing compat issues, specially on Android, but also desktop 
> (see above).
> 
> web-platform-tests: Spec allows both behaviors, so I've added an 
> internal test for now. Furthermore it's not clear if we want to do this 
> for sub-windows, which my patch does, so I may need to tweak the test or 
> add an internal switch depending on the outcome of the discussion here.
> 
> Secure contexts: not restricted to secure contexts, this is a compat 
> hack, of sorts...
> 
> Is this feature enabled by default in sandboxed iframes? Not sure if the 
> question quite applies to this, but we don't special-case sandboxed 
> iframes here. This doesn't expose anything you couldn't do before, as 
> discussed above.
> 
> Thanks for reading all the way until here
> 
>   -- Emilio

the issue is more complex: as the browser is an application , the purpose is 
making an tcp connect that never completed a state, as this would give access 
to the webserver in a socket where the client (browser) can send any code , as 
the transmission runs on the protocol level, while http is an application 
protocol, 
the issue with crypto is that the tcp out get's an reply to the ack-syn-nack 
the port doesn't matter you can run https over tcp 80, it's only not by the w3c 
standard allowed to use the first 1024 tcp ports for running public services, 
so 
for those , the agreements and maintainer

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

On 3/30/20 8:02 PM, Bobby Holley wrote:

Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:

On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is registered. This entropy is currently
retrievable via various mechanisms. For webcompat reasons, we want to make
a change to one of those mechanisms, but the entropy will remain accessible
after this change.

What's less clear to me is how the proposed change impacts the entropy
exposure by the mechanism it targets. It seems to me that using about:blank
for both the handled and unhandled case would not expose this entropy, but
the post implies otherwise.

In other words: does this change put us on a path to eventually making this
entropy non-observable, or would we need to undo this change if/when we
pursue that?


Yeah, you're right. I was not clear about this when I wrote the original 
email, but this patch makes things slightly better. It makes the known / 
unknown-ness of the protocol not observable in the navigation case.


That being said there are still a bunch of ways to get that information.

I just filed bug 1626068 to potentially try to minimize this.

 -- Emilio


Thanks!




On Sun, Mar 29, 2020 at 12:29 AM Emilio Cobos Álvarez 
wrote:


On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:

Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...

We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to silently fail,
and now it is navigating to an error page...

I'll try to look at when behavior changed around here... Though the
sync-throwing clearly makes no sense as it doesn't account for redirects
or what not.


Apparently the pre-firefox63 behavior was to both navigate and throw...

So not all that much to dig in, that was just obviously wrong, but
didn't address the fingerprinting angle other than patching one of the
holes.


On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:

Hey, a quick web-observable change that may deserve a bit more
visibility / an intent.

I'd welcome some feedback, specially from the fingerprinting / privacy
angle (where I'm clearly not an expert).

Summary: A page redirecting / navigating to an unknown protocol will
be silently ignored (and logged to the DevTools console) instead of
showing an error page. This is not amazing, but it's needed because it
causes a bunch of compat issues (see the list of issues in the bug
below).

There are a few subtle problems here. Part of the issue is that
authors don't have a cross-browser way of detecting whether a protocol
will be handled externally (that is, whether an app is installed to
handle a given protocol).

They technically can in Firefox (see example below). It's unclear
whether we want to expose more than that, or that at all.

Given Chrome just ignores the navigation if they can't handle it, some
authors (who don't seem to test on other browsers ;)) just spam the
redirect (using various methods like the location href setter / meta
refresh / whatevs). This works just fine in Chromium-based browsers,
but not in Firefox or Safari, which will just show an error, which
causes a very frustrating experience for users.

As far as I know, this behavior doesn't really expose more information
than we were exposing before. In a test-case like:




we have different behavior also before this patch: the contentDocument
for the handled-protocol iframe will be accessible to content, and be
about:blank. The contentDocument for the unhandled protocol will be
the error page, which will not be accessible to content and thus be

null.


Other browsers seem to do about:blank for both iframes, but you can
also detect this in all browsers via window.open instead (there may be
other ways around it too, haven't dug all that much). Chrome
insta-closes the handled protocol window (so you can check
window.closed). Firefox / Safari will leave about:blank in that
window, and show an error document for the second (which will throw a
security error on access).

So I don't think this change introduces a new privacy hole. That being
said, this all seems a bit sad, and a somewhat-serious potential
fingerprinting factor. I was in fact a bit nervous about this change
before realizing we were already exposing this information in other
(even simpler to test) ways... But I'm clearly not an expert on this
matter.

There are mitigations possible both for the ignored-navigation case
(maybe only ignore the navigation to an unknown protocol once per
document or something, and only for browsing contexts that can't be
accessed by any ancestor JS? not sure) and the iframe case (probably
just not show error pages in frames?). Please let me know if I you
think I should file this and follow-up on it.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?i

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Bobby Holley]

Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:

On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is registered. This entropy is currently
retrievable via various mechanisms. For webcompat reasons, we want to make
a change to one of those mechanisms, but the entropy will remain accessible
after this change.

What's less clear to me is how the proposed change impacts the entropy
exposure by the mechanism it targets. It seems to me that using about:blank
for both the handled and unhandled case would not expose this entropy, but
the post implies otherwise.

In other words: does this change put us on a path to eventually making this
entropy non-observable, or would we need to undo this change if/when we
pursue that?

Thanks!




On Sun, Mar 29, 2020 at 12:29 AM Emilio Cobos Álvarez 
wrote:

> On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:
> > Doing a bit of digging,
> > https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
> > interesting context...
> >
> > We apparently used to sync-throw when assigning location.href to an
> > unknown protocol URI in the past, there we changed it to silently fail,
> > and now it is navigating to an error page...
> >
> > I'll try to look at when behavior changed around here... Though the
> > sync-throwing clearly makes no sense as it doesn't account for redirects
> > or what not.
>
> Apparently the pre-firefox63 behavior was to both navigate and throw...
>
> So not all that much to dig in, that was just obviously wrong, but
> didn't address the fingerprinting angle other than patching one of the
> holes.
>
> > On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
> >> Hey, a quick web-observable change that may deserve a bit more
> >> visibility / an intent.
> >>
> >> I'd welcome some feedback, specially from the fingerprinting / privacy
> >> angle (where I'm clearly not an expert).
> >>
> >> Summary: A page redirecting / navigating to an unknown protocol will
> >> be silently ignored (and logged to the DevTools console) instead of
> >> showing an error page. This is not amazing, but it's needed because it
> >> causes a bunch of compat issues (see the list of issues in the bug
> >> below).
> >>
> >> There are a few subtle problems here. Part of the issue is that
> >> authors don't have a cross-browser way of detecting whether a protocol
> >> will be handled externally (that is, whether an app is installed to
> >> handle a given protocol).
> >>
> >> They technically can in Firefox (see example below). It's unclear
> >> whether we want to expose more than that, or that at all.
> >>
> >> Given Chrome just ignores the navigation if they can't handle it, some
> >> authors (who don't seem to test on other browsers ;)) just spam the
> >> redirect (using various methods like the location href setter / meta
> >> refresh / whatevs). This works just fine in Chromium-based browsers,
> >> but not in Firefox or Safari, which will just show an error, which
> >> causes a very frustrating experience for users.
> >>
> >> As far as I know, this behavior doesn't really expose more information
> >> than we were exposing before. In a test-case like:
> >>
> >>
> >>
> >>
> >> we have different behavior also before this patch: the contentDocument
> >> for the handled-protocol iframe will be accessible to content, and be
> >> about:blank. The contentDocument for the unhandled protocol will be
> >> the error page, which will not be accessible to content and thus be
> null.
> >>
> >> Other browsers seem to do about:blank for both iframes, but you can
> >> also detect this in all browsers via window.open instead (there may be
> >> other ways around it too, haven't dug all that much). Chrome
> >> insta-closes the handled protocol window (so you can check
> >> window.closed). Firefox / Safari will leave about:blank in that
> >> window, and show an error document for the second (which will throw a
> >> security error on access).
> >>
> >> So I don't think this change introduces a new privacy hole. That being
> >> said, this all seems a bit sad, and a somewhat-serious potential
> >> fingerprinting factor. I was in fact a bit nervous about this change
> >> before realizing we were already exposing this information in other
> >> (even simpler to test) ways... But I'm clearly not an expert on this
> >> matter.
> >>
> >> There are mitigations possible both for the ignored-navigation case
> >> (maybe only ignore the navigation to an unknown protocol once per
> >> document or something, and only for browsing contexts that can't be
> >> accessed by any ancestor JS? not sure) and the iframe case (probably
> >> just not show error pages in frames?). Please let me know if I you
> >> think I should file this and follow-up on it.
> >>
> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305
> >>
> >> Standard: https://html.spec.whatwg.org/#proces

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:
Doing a bit of digging, 
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more 
interesting context...


We apparently used to sync-throw when assigning location.href to an 
unknown protocol URI in the past, there we changed it to silently fail, 
and now it is navigating to an error page...


I'll try to look at when behavior changed around here... Though the 
sync-throwing clearly makes no sense as it doesn't account for redirects 
or what not.


Apparently the pre-firefox63 behavior was to both navigate and throw...

So not all that much to dig in, that was just obviously wrong, but 
didn't address the fingerprinting angle other than patching one of the 
holes.



On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will 
be silently ignored (and logged to the DevTools console) instead of 
showing an error page. This is not amazing, but it's needed because it 
causes a bunch of compat issues (see the list of issues in the bug 
below).


There are a few subtle problems here. Part of the issue is that 
authors don't have a cross-browser way of detecting whether a protocol 
will be handled externally (that is, whether an app is installed to 
handle a given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, 
but not in Firefox or Safari, which will just show an error, which 
causes a very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


   
   

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be 
the error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can 
also detect this in all browsers via window.open instead (there may be 
other ways around it too, haven't dug all that much). Chrome 
insta-closes the handled protocol window (so you can check 
window.closed). Firefox / Safari will leave about:blank in that 
window, and show an error document for the second (which will throw a 
security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this 
matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you 
think I should file this and follow-up on it.


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

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated 
it a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do 
this for sub-windows, which my patch does, so I may need to tweak the 
test or add an internal switch depending on the outcome of the 
discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if 
the question quite applies to this, but we don't special-case 
sandboxed iframes here. This doesn't expose anything you couldn't do 
before, as discussed above.


Thanks for reading all the way until here

  -- Emilio

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

Doing a bit of digging, 
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more 
interesting context...


We apparently used to sync-throw when assigning location.href to an 
unknown protocol URI in the past, there we changed it to silently fail, 
and now it is navigating to an error page...


I'll try to look at when behavior changed around here... Though the 
sync-throwing clearly makes no sense as it doesn't account for redirects 
or what not.


 -- Emilio

On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will be 
silently ignored (and logged to the DevTools console) instead of showing 
an error page. This is not amazing, but it's needed because it causes a 
bunch of compat issues (see the list of issues in the bug below).


There are a few subtle problems here. Part of the issue is that authors 
don't have a cross-browser way of detecting whether a protocol will be 
handled externally (that is, whether an app is installed to handle a 
given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, but 
not in Firefox or Safari, which will just show an error, which causes a 
very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


   
   

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be the 
error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can also 
detect this in all browsers via window.open instead (there may be other 
ways around it too, haven't dug all that much). Chrome insta-closes the 
handled protocol window (so you can check window.closed). Firefox / 
Safari will leave about:blank in that window, and show an error document 
for the second (which will throw a security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this 
matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you think 
I should file this and follow-up on it.


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

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it 
a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do this 
for sub-windows, which my patch does, so I may need to tweak the test or 
add an internal switch depending on the outcome of the discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if the 
question quite applies to this, but we don't special-case sandboxed 
iframes here. This doesn't expose anything you couldn't do before, as 
discussed above.


Thanks for reading all the way until here

  -- Emilio
___
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

Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will be 
silently ignored (and logged to the DevTools console) instead of showing 
an error page. This is not amazing, but it's needed because it causes a 
bunch of compat issues (see the list of issues in the bug below).


There are a few subtle problems here. Part of the issue is that authors 
don't have a cross-browser way of detecting whether a protocol will be 
handled externally (that is, whether an app is installed to handle a 
given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, but 
not in Firefox or Safari, which will just show an error, which causes a 
very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


  
  

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be the 
error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can also 
detect this in all browsers via window.open instead (there may be other 
ways around it too, haven't dug all that much). Chrome insta-closes the 
handled protocol window (so you can check window.closed). Firefox / 
Safari will leave about:blank in that window, and show an error document 
for the second (which will throw a security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you think 
I should file this and follow-up on it.


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

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it 
a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do this 
for sub-windows, which my patch does, so I may need to tweak the test or 
add an internal switch depending on the outcome of the discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if the 
question quite applies to this, but we don't special-case sandboxed 
iframes here. This doesn't expose anything you couldn't do before, as 
discussed above.


Thanks for reading all the way until here

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

Intent to implement and ship: RTCRtpReceiver.getParameters()

[docfaraday]

Firefox currently has no support for RTCRtpReceiver.getParameters().

Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1618999

Standard: https://w3c.github.io/webrtc-pc/

Testing:
testing/web-platform/tests/webrtc/RTCRtpReceiver-getParameters.html

Cross-browser support: Chrome (and Edge) appear to have basic support for this 
API, although the simulcast web-platform-test does not currently pass.

Platform coverage: All

Target release: 78

Preferences behind which this will be implemented: None
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: RTCRtpSender.getParameters() and RTCRtpSender.setParameters()

[docfaraday]

   Firefox currently supports an old version of RTCRtpSender.getParameters() 
and RTCRtpSender.setParameters(), which has changed significantly in more 
recent versions of the webrtc-pc spec. The most important change is the 
introduction of a transaction model, wherein setParameters() can only be called 
with the results of the most recent getParameters() call, with the desired 
modifications.

   This change is not backward compatible with the present implementation, 
because the webrtc-pc spec has changed in a non-backward-compatible way. It is 
likely that existing code using RTCRtpSender.setParameters() will need to be 
updated to work with the new version of this API.

Bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1534687
https://bugzilla.mozilla.org/show_bug.cgi?id=1401592
https://bugzilla.mozilla.org/show_bug.cgi?id=1531458

Standard: https://w3c.github.io/webrtc-pc/

Testing:
testing/web-platform/tests/webrtc/RTCRtpParameters-*
testing/web-platform/tests/webrtc/RTCRtpSender-setParameters.html
testing/web-platform/tests/webrtc/protocol/video-codecs.https.html
dom/media/tests/mochitest/test_peerConnection_setParameters.html

Cross-browser support: Chrome (and Edge) supports the more recent version of 
this API. Safari appears to have partial support for this API, but does not 
pass the relevant web-platform-tests.

Platform coverage: All

Target release: 78

Preferences behind which this will be implemented: None
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: updated values for text-decoration properties

[Jonathan Kew]

There have been some recent changes to the CSS spec for the 
text-decoration-thickness, text-underline-offset, and 
text-underline-position: support for percentage values (based on the 
font-size) is added to the -thickness and -offset properties, as an 
alternative to using absolute lengths; and the from-font value is moved 
from text-underline-offset to -position.


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1607534
https://bugzilla.mozilla.org/show_bug.cgi?id=1607308

Standard:
https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property
https://drafts.csswg.org/css-text-decor-4/#text-underline-position-property
https://drafts.csswg.org/css-text-decor-4/#underline-offset

Testing: web-platform/tests/css/css-text-decor/

Cross-browser support:
Safari partially supports these properties (it does not yet support 
percentages or the from-font value), while Chrome supports -position 
(without from-font) but not -offset or -thickness. Apple people have 
been involved in the recent spec changes, so I think we can expect to 
see Safari, at least, update its implementation to align with the new 
spec fairly soon.


Platform coverage: All

Restricted to secure contexts:
No; this is an adjustment to existing CSS properties that are available 
everywhere.


Target Release: 74

Preferences behind which this will be implemented:
None. (But note that the CSS properties involved are each gated on 
individual prefs from their original implementations:

layout.css.text-decoration-thickness.enabled
layout.css.text-underline-offset.enabled
layout.css.text-underline-position.enabled
These are enabled by default already.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS overscroll-behavior-{block,inline}

[Sean Voisen]

Summary: The overscroll-behavior-{block,inline} CSS properties are
flow-relative versions of the already-supported overscroll-behavior-{x,y}
longhand properties.

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1453472

Standard:
https://drafts.csswg.org/css-overscroll/#overscroll-behavior-longhands-logical

Discussion: https://github.com/w3c/csswg-drafts/issues/2473

Platform coverage: All platforms

Estimated or target release: Firefox 73

Preference behind which this will be implemented: These are behind the same
preference that is already enabled for the existing overscroll properties,
layout.css.overscroll-behavior.enabled.

DevTools bug: N/A, devtools support is included in these patches.

Other browser support:
https://wpt.fyi/results/css/css-overscroll-behavior/overscroll-behavior-logical.html


web-platform-tests:
http://w3c-test.org/css/css-overscroll-behavior/overscroll-behavior-logical.html

Secure Contexts: Enabled for both secure and insecure contexts.

Sandboxed iframes: This feature will be enabled by default in sandboxed
iframes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

[Tom Ritter]

This landed in https://hg.mozilla.org/mozilla-central/rev/724d7b936078

To replicate the prior output, use MOZ_LOG="DocShellAndDOMWindowLeak:3"
Because it now includes the MOZ_LOG prefix, any custom scripts you had to
parse the output will need to be updated.

-tom


On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter  wrote:
>
>> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
>> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
>> It will automatically be enabled in browser-chrome tests where it is
>> needed. (It actually will no longer be possible to disable it when running
>> those tests also.)
>>
>> Once this lands, MOZ_QUIET will no longer do anything, and if you want
>> this
>> output you will need to explicitly set a new env var.  (Current idea is
>> MOZ_LOG_WINDOWS_DOCSHELLS but feel free to tell me what color for the
>> bikeshed in phabricator, I have no preference.)
>>
>> I'm sending this before I finish the requested changes in phabricator to
>> give folks an opportunity to raise objections; I hope to land it mid/late
>> next week.
>>
>> -tom
>> ___
>> 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 implement and ship: WebXR Device API in Firefox Nightly

[kgilbert]

On Tuesday, August 28, 2018 at 5:16:14 PM UTC-7, kgil...@mozilla.com wrote:
> Hi David,
> 
> These are all great points, thanks for reviewing this.
> 
> The intent is to not allow WebXR in any iframe (not just sandboxed ones), 
> until the discussions have settled.  I appreciate the feedback on the feature 
> policy approach and how the origin would be presented to the user.
> 
> Much of the recent activity in the community group is related to session 
> creation, ensuring that each UA can prompt the user in the most appropriate 
> way without affecting content.  The prompts may vary, for example, if using a 
> headset connected to a traditional PC versus an all-in-one VR computer such 
> as the "Oculus Go".  Some vendors may opt to present more granular 
> information about a WebXR presentation request (eg, notify user that site is 
> requesting specific geometry for world understanding and to present to their 
> full FOV) while others may opt to present a catch-all (eg, the site is 
> requesting access to all your sensors and camera feed).
> 
> I'll raise the concern about about delegation and what domain to associate 
> with in the community group.  This is a very good point.
> 
> The intent is to follow a fail-safe approach, that will not result in sites 
> working now that would break later.  If the specifics on iframe WebXR usage 
> are settled before implementation is complete, I hope to also enable iframe 
> WebXR usage accordingly.
> 
> On Tuesday, August 7, 2018 at 2:07:06 PM UTC-7, David Baron wrote:
> > On Monday 2018-07-30 17:03 -0700, Kip Gilbert wrote:
> > > Is this feature enabled by default in sandboxed iframes?
> > > WebXR will not be enabled by default in sandboxed iframes.  This will 
> > > likely be enabled later, by use of Feature Policy: 
> > > https://github.com/immersive-web/webxr/issues/86 
> > > <https://github.com/immersive-web/webxr/issues/86>
> > 
> > I'm curious why this is specific to sandboxed iframes, rather than,
> > say, any cross-origin iframes (and perhaps also same-origin
> > sandboxed ones).
> > 
> > That said, some of this concern comes from not being sure what it
> > looks like to a user if a page wants to use XR.  Is there some sort
> > of permission prompt or request that the user sees first?
> > 
> > If there is... what domain is it associated with?
> > 
> > One of the goals of feature policy is to allow permission requests
> > be *associated* only with the toplevel page.  This is useful since
> > permission requests coming from subframes aren't particularly
> > meaningful and are also confusing -- they don't correspond to the
> > URL bar, it's not clear what persisting them would mean, etc.
> > 
> > A page would be able to use feature policy to delegate their ability
> > to use/request capabilities to a cross-origin frame.  Without that
> > delegation a cross-origin subframe would not have access to the
> > capability; with the delegation requests from the cross-origin frame
> > would appear as though they come from the toplevel document (and if
> > remembered, would be remembered as such).
> > 
> > *If* something like that is the model here, then maybe a
> > cross-origin iframes restriction rather than a sandbox iframes
> > restriction makes more sense.
> > 
> > -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)

There has been much work in the W3C Immersive-Web Working Group on WebXR since 
this original intent-to-implement-and-ship thread was started.

The spec is now stable, without anticipated breaking changes.  Other vendors 
will also be imminently shipping WebXR.

WebXR will now be using feature-policy:

https://www.w3.org/TR/webxr/#feature-policy

Earlier today, Mozilla posted "Intent to prototype: Delegate and restrict 
permission in third party context":

https://groups.google.com/forum/#!topic/mozilla.dev.platform/BdFOMAuCGW8

WebXR will utilize this system to allow delegation.

The WebXR spec has been split into modules, similar to those used for CSS.  We 
intend to ship the "WebXR Core" and "WebXR Gamepads" modules initially.  Other 
modules in "incubation" are not in scope for this intent-to-implement-and-ship.

And updated target for WebXR is now FF73.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: Promise.any

[Jason Orendorff]

We intend to implement and ship Promise.any, a proposed way to `await`
several promises and continue as soon as any of them becomes
fulfilled. André Bargull [:anba] has contributed patches implementing
this feature. It will land in Nightly soon.

We'll ship it once we're confident the specification is stable
(Promise.any is at Stage 3 in the TC39 Process[1], but some minor
changes are still in flight).

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

Proposed standard: https://tc39.es/proposal-promise-any/

Proposal repository: https://github.com/tc39/proposal-promise-any/

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any

Platform coverage: All, Nightly only, no pref

DevTools bug: N/A

Other browsers: Not implementing yet, as far as I can tell. I expect V8
will start soon and JSC will implement it eventually.

Polyfills are already available for this proposal[2][3].

Testing: The patch[4] contains tests, including tests for aspects of
behavior that we do not expect test262 to test thoroughly: error stacks
and cross-realm behavior. Test262 will eventually provide independent
tests.

Use cases: Promise.any is similar to Promise.race. It's for cases in
async code when you would use Promise.race, but you're interested in the
first success, not the first failure. If you were implementing something
like Gecko's "Race Cache With Network" behavior[5][6], you might write:

```js
let response = await Promise.any([network_fetch, cache_fetch]);
```

[1]: https://tc39.es/process-document/
[2]: https://github.com/zloirock/core-js#promiseany
[3]: https://github.com/es-shims/Promise.any#promiseany-
[4]: https://phabricator.services.mozilla.com/D51659
[5]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/fvCmc6kR9Uk
[6]: about:networking#rcwn

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

Re: Intent to Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

[Eric Rahm]

This sounds great. Is there a reason we can't just use MOZ_LOG for the
docshell/domwindow logging?

-e


On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter  wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
> needed. (It actually will no longer be possible to disable it when running
> those tests also.)
>
> Once this lands, MOZ_QUIET will no longer do anything, and if you want this
> output you will need to explicitly set a new env var.  (Current idea is
> MOZ_LOG_WINDOWS_DOCSHELLS but feel free to tell me what color for the
> bikeshed in phabricator, I have no preference.)
>
> I'm sending this before I finish the requested changes in phabricator to
> give folks an opportunity to raise objections; I hope to land it mid/late
> next week.
>
> -tom
> ___
> 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 Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

[Dave Townsend]

Thank you for doing this.

On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter  wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
> needed. (It actually will no longer be possible to disable it when running
> those tests also.)
>
> Once this lands, MOZ_QUIET will no longer do anything, and if you want this
> output you will need to explicitly set a new env var.  (Current idea is
> MOZ_LOG_WINDOWS_DOCSHELLS but feel free to tell me what color for the
> bikeshed in phabricator, I have no preference.)
>
> I'm sending this before I finish the requested changes in phabricator to
> give folks an opportunity to raise objections; I hope to land it mid/late
> next week.
>
> -tom
> ___
> 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

Intent to Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

[Tom Ritter]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
It will automatically be enabled in browser-chrome tests where it is
needed. (It actually will no longer be possible to disable it when running
those tests also.)

Once this lands, MOZ_QUIET will no longer do anything, and if you want this
output you will need to explicitly set a new env var.  (Current idea is
MOZ_LOG_WINDOWS_DOCSHELLS but feel free to tell me what color for the
bikeshed in phabricator, I have no preference.)

I'm sending this before I finish the requested changes in phabricator to
give folks an opportunity to raise objections; I hope to land it mid/late
next week.

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

Re: Intent to implement and ship: Limit the length of Referer header to 4k

[Thomas Nguyen]

Thanks, that's a good point indeed. I prefer adding a console warning in
this case.

On Tue, Jul 2, 2019 at 9:23 PM Panos Astithas  wrote:

> On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen  wrote:
>
>> DevTools bug: No
>>
>
>  Wouldn't it be helpful to indicate such truncation in the console (as a
> warning) or network panel (with a request badge)? I can imagine developers
> being confused about why the referrer header is not what they expect it to
> be.
>
> Panos
>
>

-- 
Best regards,

=
Thomas Nguyen
IRC : tngu...@irc.mozilla.com
Slack: tnguyen
Email: tngu...@mozilla.com
=
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Limit the length of Referer header to 4k

[Panos Astithas]

On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen  wrote:

> DevTools bug: No
>

 Wouldn't it be helpful to indicate such truncation in the console (as a
warning) or network panel (with a request badge)? I can imagine developers
being confused about why the referrer header is not what they expect it to
be.

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

Intent to implement and ship: Limit the length of Referer header to 4k

[Thomas Nguyen]

Summary:

Servers often reject requests entailing an overly long `Referer` header.
Additionally, attackers can retain control over the header on `no-cors`
requests and force an error when fetching a subresource which allows them
to perform cache probing attacks by looking at the error event of the
request.

To compensate, we plan to strip down the Referrer URL to the origin if the
`Referer` header's value exceeds 4k. If the origin of Referrer still
exceeds 4k, then completely remove the Referrer Header.

More details:

https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#cache-and-error-events
,


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

Link to standard:

https://github.com/w3c/webappsec-referrer-policy/pull/122

https://github.com/whatwg/fetch/issues/903

Platform coverage: All platforms.

Estimated or target release: 70

Is this feature enabled by default in sandboxed iframes? Yes.

DevTools bug: No

Do other browser engines implement this? Chromium:

https://www.chromestatus.com/features/5648956820291584

Is this feature restricted to secure contexts? No.

Web-platform-tests:
https://github.com/web-platform-tests/wpt/blob/master/referrer-policy/generic/referrer-policy-test-case.sub.js

-- 
Best regards,

=
Thomas Nguyen
IRC : tngu...@irc.mozilla.com
Slack: tnguyen
Email: tngu...@mozilla.com
=
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[Sean Voisen]

On Fri, Jun 14, 2019 at 3:25 AM violet  wrote:

> Preference behind which this will be implemented:
> layout.css.overflow-logical.enabled
>
> Enabled by default.
>

Enabled by default sounds fine to me in this case.

Thanks for doing this,
Sean
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: webkitURL

[saschanaz7]

Summary: webkitURL will be implemented as a legacy compatibility alias of URL.

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

Link to standard: https://url.spec.whatwg.org/#url-class

Platform coverage: All

Estimated or target release: 69

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this? Answer with: shipped since Chrome 2 
and Safari 6.

web-platform-tests: https://w3c-test.org/url/idlharness.any.html

Is this feature restricted to secure contexts? No
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[fantasai]

On 3/27/19 5:19 AM, L. David Baron wrote:

On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:

FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions.  So, some
of the finer details in there might be wrong, but I think
most of it regarding counters is correct.


If you've been implementing based off of resolutions that aren't in
the spec, it's probably worth submitting PRs to the spec so that
other future implementors are aware of those resolutions and you
don't have to later go and undo the effects of those resolutions for
compatibility.


Since I just ran across this thread, current status of the spec is a lot better:
  https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html

~fantasai

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

Intent to implement and ship: AbstractRange and StaticRange

[Masayuki Nakano]

Summary: Implement StaticRange and makes it and Range inherits AbstractRange
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1444847
Link to Standards: https://dom.spec.whatwg.org/#abstractrange
   https://dom.spec.whatwg.org/#staticrange
Platform coverage: all
Estimated or target release: 69 (or later if we'd meet web-comoat issue)
Preference behind which this will be implemented: none
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
Do other browser engines implement this? a little bit complicated, see 
below.

web-platform-tests: Only interface existence is tested.
Is this feature restricted to secure contexts? No

StaticRange is simpler range than Range (nsRange internally). Different 
from Range, StaticRange does not modify its start boundary nor end 
boundary when the DOM tree is modified.  In other words, StaticRange 
keeps storing start and end boundaries when it's created.  This is 
currently implemented by Chrome, Safari and Edge.  This was declared 
with constructor but current it's explicitly removed.


AbstractRange is common interface of Range and StaticRange.  This also 
does not have constructor.  Chrome supports this interface.


Both of them cannot be created from WebAPI for now. StaticRange will be 
used as result of InputEvent.getTargetRanges().

https://w3c.github.io/input-events/#dom-inputevent-gettargetranges

So, we just exposes the interfaces for now, but I think that nobody uses 
this for feature detection.


--
Masayuki Nakano 
Working on DOM, Events, editor and IME handling at Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Exposure of Geometry Interfaces to Workers

[Boris Zbarsky]

On 6/17/19 11:02 AM, saschan...@gmail.com wrote:

Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable 
structured cloning for them.


Note that this also allows storing these objects in IndexedDB, via 
implementing the equivalent of 
https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects 
for them.


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

Intent to implement and ship: Exposure of Geometry Interfaces to Workers

[saschanaz7]

Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable 
structured cloning for them.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1420580 
Link to standard: https://drafts.fxtf.org/geometry/
Platform coverage: all
Estimated or target release: 69
Preference behind which this will be implemented: none
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
Do other browser engines implement this? Chrome exposes them and supports 
structured cloning.
web-platform-tests: 
https://github.com/web-platform-tests/wpt/tree/master/css/geometry 
Is this feature restricted to secure contexts? No
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[Boris Zbarsky]

On 6/14/19 6:23 AM, violet wrote:

Preference behind which this will be implemented: 
layout.css.overflow-logical.enabled


Thank you.

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

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[violet]

Preference behind which this will be implemented: 
layout.css.overflow-logical.enabled

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

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[violet]

> It's probably a good idea to have a pref controlling whether these get
parsed, so we can disable if needed if there's an issue, given that no
one has shipped these yet in a final release.

Ok, I'll add a flag for this.

> Are these just logical versions of the existing overflow-x and
overflow-y properties?

Yes, they're the logical versions of overflow-x, overflow-y.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[violet]

> Chrome has shipped these properties in latest Canary, commit:
> https://chromium.googlesource.com/chromium/src/+/985a82ce4c869aca8e33dc213293a37b2764d69c

To clarify, Chrome has just implemented a few days ago, it's not "shipped" yet. 
The status can be found here: 
https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/runtime_enabled_features.json5#372
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

[Boris Zbarsky]

On 6/13/19 4:15 AM, violet wrote:

Preference behind which this will be implemented: none.


It's probably a good idea to have a pref controlling whether these get 
parsed, so we can disable if needed if there's an issue, given that no 
one has shipped these yet in a final release.  Or are there technical 
reasons that make this difficult?


Are these just logical versions of the existing overflow-x and 
overflow-y properties?


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

Intent to implement and ship: overflow-block and overflow-inline CSS properties

[violet]

Summary: implement overflow-block and overflow-inline CSS properties

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

Link to standard: https://drafts.csswg.org/css-overflow-3/#logical

Platform coverage: all.

Estimated or target release: 69

Preference behind which this will be implemented: none.

Do other browser engines implement this?

Chrome has shipped these properties in latest Canary, commit:
https://chromium.googlesource.com/chromium/src/+/985a82ce4c869aca8e33dc213293a37b2764d69c

Safari has not implemented yet.

web-platform-tests: already exist. css/css-overflow/

Is this feature restricted to secure contexts? No. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: Resize Observer API

[Boris Chiou]

Hi,

*Summary*:

 We had landed this feature behind a preference last month, and we are
planning to ship this on Firefox 69. The ResizeObserver API is an interface
for observing changes to the element’s size (based on its content-box or
border-box, for now). Each time when the element's size changes, the
callback function would be triggered, and you can get the current
content-box size or border-box size information (or other boxes in the
future).

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1543839
*Link to standard*: https://drafts.csswg.org/resize-observer-1/
*Platform coverage*: On all platforms.
*Estimated or target release*: Firefox 69
*Preference:* layout.css.resizeobserver.enabled

*Do other browser engines implement this?*

   -
*  Google Chrome: Supported since Chrome 64
    *
   -
*  Safari: Will be available in Safari 13,
   (Webkit Bug 157743 has been
   fixed) *

*web-platform-tests*:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/resize-observer
(or https://github.com/web-platform-tests/wpt/tree/master/resize-observer)

*Is this feature restricted to secure contexts?* No

If you have any concerns or questions, please feel free to let me know.
Thanks.

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

Intent to implement and ship: break-spaces value of the white-space property

[Violet L]

Summary: implement and ship value "break-spaces" of "white-space" CSS property

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

Link to standard: 
https://drafts.csswg.org/css-text-3/#valdef-white-space-break-spaces

Platform coverage: all.

Estimated or target release: 69 

Preference behind which this will be implemented: none. 

Do other browser engines implement this?

Chrome has shipped this value in latest dev channel (76) 
https://bugs.chromium.org/p/chromium/issues/detail?id=767634

Safari Tech Preview 80
https://webkit.org/blog/8825/release-notes-for-safari-technology-preview-80/
https://trac.webkit.org/changeset/244036/webkit/

web-platform-tests: We have existing WPTs. In /css/css-text/white-space/

Is this feature restricted to secure contexts? No. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: blob.text(), blob.arrayBuffer(), blob.stream()

[Boris Zbarsky]

On 6/7/19 8:47 AM, Andrea Marchesini wrote:

Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().


Looks good to me.

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

Intent to implement and ship: blob.text(), blob.arrayBuffer(), blob.stream()

[Andrea Marchesini]

Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().

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

Link to standard: https://w3c.github.io/FileAPI
https://github.com/w3c/FileAPI/pull/117

Platform coverage: all.

Estimated or target release: 69

Preference behind which this will be implemented: none.

Do other browser engines implement this?
Chrome has already shipped these methods. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=945893
Safari hasn't started to work on them yet. See:
https://bugs.webkit.org/show_bug.cgi?id=196258

web-platform-tests: We have existing WPTs. See:
https://github.com/web-platform-tests/wpt/blob/master/FileAPI/blob

Is this feature restricted to secure contexts? No.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

[Emilio Cobos Álvarez]

Just as a PSA, I did a bunch of work a while ago to align better with 
other UAs, and the Gecko-specific values are gone as a result of that work.


The CSSWG resolved in our behavior regarding `auto` in:

  https://github.com/w3c/csswg-drafts/issues/3344

So I plan to land the changes in 69 now that the soft-freeze is over.

 -- Emilio

On 11/11/2018 18:57, Emilio Cobos Álvarez wrote:
Summary: Unprefix the -moz-user-select property, so that it works 
without the -moz- prefix.


We happen to be supporting the -webkit- prefixed version of the 
property, but other browsers support it also unprefixed, which causes a 
lot of confusion.


As part of this work I'm also unshipping the following values from 
content (or entirely, if they have no internal usage):


  * -moz-all: Was meant to behave as an alias of `all`, but in practice 
that's not true. Plus all external usage I found was followed by a 
-webkit-user-select: all which would override it.


  * -moz-text: It's an internal value which was introduced in bug 
1181130. It's only used from contenteditable.css and I haven't 
investigated removing it completely, but I'm restricting it to 
user-agent stylesheets. I found no relevant external usage.


  * tri-state, element, elements, toggle: We parse these but do nothing 
with them (lol, I know, right?). They're no longer in the spec so should 
be removed.


We also have a non-standard '-moz-none' alias to 'none' which I haven't 
investigated removing yet, but probably should in a followup to this bug.


Bug: 1492958 for the removal of non-standard values, 1492739 for the 
unprefixing.


Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select

Platform coverage: All

Estimated or target release: FF65

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this?

This is an interesting question. The current status is:

  * Blink supports user-select unprefixed and -webkit- prefixed, with 
the same values we'd support after this bug (except our non-standard 
-moz-none alias).


  * Edge supports the -ms- prefixed version of the property, and the 
-webkit- prefixed version. Edge is the only engine to support the 
'contain' value.


  * WebKit only supports the -webkit- prefixed version.

So all browsers support as of today the -webkit- prefixed version of the 
property, which is a fun state of affairs, with a slightly different set 
of values.


I think we should try to unprefix sooner than later so this doesn't end 
up being something similar to '-webkit-apperance'. Given Chrome supports 
the same thing as us unprefixed, I think it's reasonable to do this.


web-platform-tests: Test coverage for all the values is pre-existing. 
There's unfortunately little coverage in WPT, but a lot in our selection 
and contenteditable tests.


Is this feature restricted to secure contexts? No, as this is merely 
unprefixing an existing property.


Thoughts?

  -- Emilio
___
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 Implement and Ship: Permissions API

[kale . williams]

On Friday, August 21, 2015 at 11:04:00 PM UTC-4, Birunthan Mohanathas wrote:
> Hi,
> 
> navigator.permissions.query has been Nightly-only for a few weeks. We
> are going to let it ride the trains. Other parts of the spec (such as
> Permissions.request) will be implemented when the spec is complete.
> 
> Summary: The Permissions API allows a web application to be aware of
> the status of a given permission, to know whether it is granted,
> denied or if the user will be asked whether the permission should be
> granted.
> 
> Use cases: See 
> https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview?pli=1#heading=h.yeaa13evs6re
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1105827
> 
> Spec: https://w3c.github.io/permissions/
> 
> Platform coverage: All platforms
> 
> Target release: Firefox 43
> 
> Other vendor implementations: Supported by Chrome (43)
> 
> Cheers,
>  Turn this off
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSSStyleSheet.rules, CSSStyleSheet.removeRule, CSSStyleSheet.addRule

[Emilio Cobos Álvarez]

Summary: Implement and spec some non-standard CSSOM APIs to converge 
with every other browser, since they're unlikely to ever remove their 
implementations and the lack of them causes compat issues for us, see 
the bug, the CSSWG issue [1] and everything cross-linked from there.


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

Link to standard: https://github.com/w3c/csswg-drafts/pull/3900

Platform coverage: All

Estimated or target release: 68

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this? Yes, all of them, since 
basically forever (see https://github.com/whatwg/compat/issues/98).


Only know difference is that Blink and my implementation returns a live 
object for CSSStyleSheet.rules, while WebKit returns a static list of 
rules. I've filed a bug on WebKit to consider simplifying their code and 
making this just an alias to converge: https://webkit.org/b/197725.


web-platform-tests: Added as part of the implementation.

Is this feature restricted to secure contexts? No, it's a legacy API, 
mostly aliases of already-non-restricted APIs.


As always, let me know if you think there's any concerns with proceeding.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3814
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: Support "noreferrer" feature for window.open()

[Ehsan Akhgari]

*Summary*: This feature adds a token to the window.open() feature argument
to allow callers to specify that the window should be opened without a
referrer (and an opener).
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1527287
*Link to standard*: https://github.com/whatwg/html/pull/4331
*Platform coverage*: where will this be available? All platforms.
*Estimated or target release*: in which version do you want to/plan to
release this? Firefox 68.
*Preference behind which this will be implemented*:
dom.window.open.noreferrer.enabled.
*Is this feature enabled by default in sandboxed iframes?* Yes, it is.
*DevTools bug*: No devtools specific support needed.
*Do other browser engines implement this?*

Blink: Implemented on trunk:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/K8_-u7mK688/rK7FrIOLBQAJ

WebKit: Implemented in the latest Safari Technology Preview:
https://webkit.org/blog/8825/release-notes-for-safari-technology-preview-80/

*web-platform-tests*: https://github.com/web-platform-tests/wpt/pull/15352

*Is this feature restricted to secure contexts?* No, since window.open()
itself is exposed to non-secure contexts as well.
Please note that similar to our implementation of the noopener feature
token for window.open(), our noreferrer implementation will diverge from
the spec in that we will remove the parsed tokens from the feature string
before passing it down to lower layers, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1419960.  This is now being
tracked to be merged into the spec in
https://github.com/whatwg/html/pull/3297.  The impact of this (currently
Firefox specific) behaviour is that if you pass a feature argument
containing only "noopener" (or "noreferrer") to window.open() you will get
a usable window with the default UI elements only with its opener (or
referrer) stripped out as opposed to a barebones window with all of the UI
elements (e.g. various toolbars) missing as well.

Please let me know if you have any questions or concerns.

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

Intent to Implement and Ship: , reflected by HTMLLinkElement.disabled

[Emilio Cobos Álvarez]

Summary: Make the disabled attribute on link elements do something
useful, and the disabled IDL attribute reflect this attribute instead of
forwarding to the style sheet object (if present). This is mostly compat
work, but should also do less work in pages that use it already. See
below for the long story.

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

Link to standard: https://github.com/whatwg/html/pull/4519

There are two parts of this proposal. One is "implementing the disabled
attribute". That's what that HTML spec PR is about. The other is about
changing the behavior of HTMLLinkElement.disabled, which we do
implement, to reflect the content attribute. This used to be spec'd like
what Gecko does, but was removed from the spec. New thing matches WebKit
/ Blink. See the "Do other browser engines implement this?" for all
details you may want to know (and probably more) about this situation.

Platform coverage: All

Estimated or target release: 68

Preference behind which this will be implemented:
dom.link.disabled_attribute.enabled

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: I don't think it's needed, but please file if you think
otherwise.

Do other browser engines implement this?

All other engines implement the disabled attribute in one way or
another. See below for the details of what WebKit and Blink do. Edge
looks like they implemented the `disabled` attribute as a "default value
for the stylesheet disabled flag" kind of thing. That has the downside
of still downloading the stylesheet in a case where WebKit and Blink
don't right now, and thus I don't think WebKit or Blink would be
interested in switching to such a model.

Regarding HTMLLinkElement.disabled, also all engines implement it, with
two different behaviors right now:

 * Gecko (before my patch) and Edge implement the old spec for this,
where it forwards to the stylesheet's disabled flag.
 * Blink / WebKit implement it as reflecting the disabled attribute (I'm
not aware of any spec reference, historical or not, for this behavior,
but I'd be interested in knowing about it).

Now the long story, which is mostly in [1]. The TL;DR: is written in
[2], and that contains the proposed behavior that my change implements.
Feel free to skip to the "web-platform-tests" section below if you're
not interested on the details.

Blink and WebKit implement the `disabled` attribute on stylesheets, and
it's the only way to enable alternate stylesheets there. There's no spec
for that of course, and the behavior of this attribute in those engines
is quite bizarre (see [1] for reference).

Separately, there's the HTMLLinkElement.disabled setter and getters,
which were removed from the spec, but that everyone still implements
(and I'm pretty sure it'd not be compatible to remove it).

Spec-wise, the spec says that alternate stylesheets are supposed to be
implemented using the disabled flag on the stylesheet [3]. Edge and
Gecko do that, and make HTMLLinkElement.disabled forward to the stylesheet.

In WebKit / Blink, this is not the case. An alternate stylesheet is not
disabled (as in `link.sheet` is non-null, `link.sheet.disabled` returns
false, but still magically does not apply to the page). The only way to
enable such an stylesheet in Blink and WebKit is removing the `disabled`
attribute on the link.

This means that the only way to have a cross-browser alternate
stylesheet is:

  

And the cross-browser way to enable is using `link.disabled`:

 * In Gecko and Edge, that setter will forward to the stylesheet, object
(it's the same as saying `if (link.sheet) link.sheet.disabled = false;`.
And given they implement alternate sheets according to the standard,
then it'd enable the already loaded and parsed stylesheet.

 * In Blink and WebKit, this will remove the disabled attribute, which
will load the stylesheet, and set a magic "explicitly enabled" bit that
will make the stylesheet apply when it loads.

Separately, some websites are starting to use:

  

And it's a common cause of confusion when people find that it doesn't
work on Firefox. The disabled attribute on its own does nothing in Gecko
and thus we apply the stylesheet when other browsers don't, and thus the
website breaks.

This is all quite sad and bizarre, and other that this move I don't see
many other paths forwards to achieve interop in all this mess. Blink and
WebKit could probably fix their alternate stylesheet implementation to
properly use the disabled flag, but given their use counters [4][5]
they'll probably not remove the disabled attribute regardless. Also,
they have other incentives to keep the disabled attribute, like the fact
that  for them it's a performance boost (they don't have to download and
parse potentially large stylesheets).

So my proposed model aligns with WebKit and Blink as much as possible
without implementing obvious bugs. The disabled attribute also causes
the stylesheet to not be present / loaded at all. This makes sense, and

Re: Intent to implement and ship: add `preventScroll` option to HTMLElement's, SVGElement's and XULElement's `focus` method

[mbrodesser]

On Monday, April 15, 2019 at 9:21:57 AM UTC+2, Makoto Kato wrote:
> Hi, Mirko.  (I mistake email address. sorry)
> 
> Does this work on GeckoView/Android too?  When showing software keyboard,
> web page may be scrolled without focus manager.

For the record: GeckoView will need to be adapted separately. There's 
https://bugzilla.mozilla.org/show_bug.cgi?id=1544660 to achieve this.

> 
> -- Makoto
> 
> On Thu, Apr 11, 2019 at 11:35 PM Mirko Brodesser 
> wrote:
> 
> > *Summary*: this allows web-developers to focus an element without scrolling
> > to it.
> >
> > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
> >
> > *Link to standard*:
> > https://html.spec.whatwg.org/#dom-focusoptions-preventscroll
> >
> > *Platform coverage*: all platforms.
> >
> > *Estimated or target release*: Firefox 68.
> >
> > *Preference behind which this will be implemented*: not applicable.
> >
> > *Is this feature enabled by default in sandboxed iframes?* No and there's
> > no new sandbox flag to enable it.
> >
> > *DevTools bug*: none.
> >
> > *Do other browser engines implement this?* Shipped in Chrome (since version
> > 64).
> >
> > *web-platform-tests*:
> >
> > http://w3c-test.org/html/interaction/focus/processing-model/preventScroll.html
> >
> > *Is this feature restricted to secure contexts?* No.
> >
> > *How stable is the spec: *it seems stable, apart from the special case of
> > re-focusing an element: https://github.com/whatwg/html/issues/4512.
> >
> > *Example:* data:text/html, input { margin-top: 40cm } 
> >   document.getElementById("i1").focus({
> > preventScroll: true }); 
> >
> > The feature is planned to be shipped with Firefox 68. Chrome has already
> > shipped it.
> >
> > *Bug to turn on by default*:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
> >
> > If there are questions or suggestions, please let me know.
> > ___
> > 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 implement and ship: add `preventScroll` option to HTMLElement's, SVGElement's and XULElement's `focus` method

[Makoto Kato]

Hi, Mirko.  (I mistake email address. sorry)

Does this work on GeckoView/Android too?  When showing software keyboard,
web page may be scrolled without focus manager.

-- Makoto

On Thu, Apr 11, 2019 at 11:35 PM Mirko Brodesser 
wrote:

> *Summary*: this allows web-developers to focus an element without scrolling
> to it.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
>
> *Link to standard*:
> https://html.spec.whatwg.org/#dom-focusoptions-preventscroll
>
> *Platform coverage*: all platforms.
>
> *Estimated or target release*: Firefox 68.
>
> *Preference behind which this will be implemented*: not applicable.
>
> *Is this feature enabled by default in sandboxed iframes?* No and there's
> no new sandbox flag to enable it.
>
> *DevTools bug*: none.
>
> *Do other browser engines implement this?* Shipped in Chrome (since version
> 64).
>
> *web-platform-tests*:
>
> http://w3c-test.org/html/interaction/focus/processing-model/preventScroll.html
>
> *Is this feature restricted to secure contexts?* No.
>
> *How stable is the spec: *it seems stable, apart from the special case of
> re-focusing an element: https://github.com/whatwg/html/issues/4512.
>
> *Example:* data:text/html, input { margin-top: 40cm } 
>   document.getElementById("i1").focus({
> preventScroll: true }); 
>
> The feature is planned to be shipped with Firefox 68. Chrome has already
> shipped it.
>
> *Bug to turn on by default*:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
>
> If there are questions or suggestions, please let me know.
> ___
> 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 implement and ship: add `preventScroll` option to HTMLElement's, SVGElement's and XULElement's `focus` method

[sime . vidas]

The multiplage version of the spec (for folks with slower machines): 

https://html.spec.whatwg.org/multipage/interaction.html#dom-focusoptions-preventscroll
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: add `preventScroll` option to HTMLElement's, SVGElement's and XULElement's `focus` method

[Mirko Brodesser]

*Summary*: this allows web-developers to focus an element without scrolling
to it.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1374045

*Link to standard*:
https://html.spec.whatwg.org/#dom-focusoptions-preventscroll

*Platform coverage*: all platforms.

*Estimated or target release*: Firefox 68.

*Preference behind which this will be implemented*: not applicable.

*Is this feature enabled by default in sandboxed iframes?* No and there's
no new sandbox flag to enable it.

*DevTools bug*: none.

*Do other browser engines implement this?* Shipped in Chrome (since version
64).

*web-platform-tests*:
http://w3c-test.org/html/interaction/focus/processing-model/preventScroll.html

*Is this feature restricted to secure contexts?* No.

*How stable is the spec: *it seems stable, apart from the special case of
re-focusing an element: https://github.com/whatwg/html/issues/4512.

*Example:* data:text/html, input { margin-top: 40cm } 
  document.getElementById("i1").focus({
preventScroll: true }); 

The feature is planned to be shipped with Firefox 68. Chrome has already
shipped it.

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

If there are questions or suggestions, please let me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Gijs Kruitbosch]

Are there also plans to revisit our longstanding 
foreground/background/link/visited-link colouring prefs (as well as 
their companion use_system_colors pref) in light of this set of changes? 
They've never really worked very well, nobody has really taken on fixing 
their UX, and it would be nice if we could switch to something that was 
better supported.


~ Gijs

On 15/02/2019 20:38, Mats Palmgren wrote:

Summary:
The 'prefers-color-scheme' media feature is way for pages to detect
if the user prefers a light or dark color theme.  The values are
'light', 'dark', and 'no-preference'.  If the "resist fingerprinting"
feature is active we always match 'light'.  If the media type is
'print' we always match 'light'.  Otherwise, we try to determine
a value from the user's current "desktop theme".  This should work
well on recent versions of OSX and Windows.  On Linux, we don't
know how to determine a value from the system so we match
'no-preference' there - help wanted:
https://bugzilla.mozilla.org/show_bug.cgi?id=1525775

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

Link to standard:
https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

Platform coverage: All platforms

Estimated or target release: Firefox 67

Preference behind which this will be implemented:
The feature is always enabled, but there is an existing hidden
preference to set a value (integer), ui.systemUsesDarkTheme:
0 = light
1 = dark
2 = no-preference

Is this feature enabled by default in sandboxed iframes?
Yes, but if widget look-and-feel features are disabled in
sandboxed iframes then we'll match 'no-preference'.

DevTools bug: none

Do other browser engines implement this?
Safari has implemented this feature and it's available in their
Nightly build, but it's not yet shipped AFAICT.
https://paulmillr.com/posts/using-dark-mode-in-css/ is a post about
implementation of this feature in Safari;
https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/ 
documents its addition.


It appears Chrome is actively working on it:
https://bugs.chromium.org/p/chromium/issues/detail?id=889087

web-platform-tests:
https://w3c-test.org/css/mediaqueries/prefers-color-scheme.html

Is this feature restricted to secure contexts? No

Credit also goes to Jonathan Kingston who wrote the initial
implementation of this feature.


/Mats


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

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

On Wed, Mar 20, 2019 at 8:45 AM Hiroyuki Ikezoe  wrote:

> The Android backend for prefers-color-scheme didn't get on Firefox 67,
> it's just landed on mozilla-central, will be shipped in Firefox 68.
>

The backend was uplifted into Firefox 67 beta yesterday.  So
prefers-color-scheme will be available on all platforms in Firefox 67.

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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
> FYI, the CSS Lists spec isn't very well maintained, sadly,
> so it's not up-to-date with recent resolutions.  So, some
> of the finer details in there might be wrong, but I think
> most of it regarding counters is correct.

If you've been implementing based off of resolutions that aren't in
the spec, it's probably worth submitting PRs to the spec so that
other future implementors are aware of those resolutions and you
don't have to later go and undo the effects of those resolutions for
compatibility.

-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)


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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

On 3/27/19 12:30 AM, Domenic Denicola wrote:

(On-list this time)


However, the actual semantics for how list items work are exclusively
defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML
elements/attributes simply maps to the relevant CSS properties, using
a built-in 'list-item' counter.



Where does [css-lists] and [css-pseudo] define this?



From CSS Lists, Introduction:
https://drafts.csswg.org/css-lists-3/#intro
"It also defines _counters_, which are special numerical objects
often used to generate the default contents of markers."
where _counters_ links to:
https://drafts.csswg.org/css-lists-3/#counter

Pretty much all of CSS Lists is about how these generic
counters work.  The built-in 'list-item' is such a counter.
The only thing special about it is that it's automatically
incremented for any element that has 'display:list-item'.
https://drafts.csswg.org/css-lists-3/#declaring-a-list-item
Other than that, it works exactly like a counter an author
can introduce themselves.

FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions.  So, some
of the finer details in there might be wrong, but I think
most of it regarding counters is correct.


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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

(On-list this time)

> However, the actual semantics for how list items work are exclusively defined 
> by CSS ([css-lists], [css-pseudo]).
> The above mentioned HTML elements/attributes simply maps to the relevant CSS 
> properties, using a built-in 'list-item' counter.


Where does [css-lists] and [css-pseudo] define this?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

On 3/25/19 6:21 AM, Domenic Denicola wrote:
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item
> seems to contradict that hard-fought consensus. It seems like a
> regression to implement list item numbering according to that spec,
> instead of according to HTML.

As others have clarified, there are zero regressions from these changes
(that we know of) and **a lot** of bugs fixed.  The compatibility with
other UAs and web content is now greatly improved.

You seem to think that HTML is the authoritative specification for
how list items work.  That's only partly true.
HTML specifies the part where certain elements opens a list item
scope (ol/ul/menu), have a default 'display:list-item' value (li)
and that  sets the value of the counter, etc.

However, the actual semantics for how list items work are
exclusively defined by CSS ([css-lists], [css-pseudo]).
The above mentioned HTML elements/attributes simply maps to
the relevant CSS properties, using a built-in 'list-item' counter.
Most importantly: this counter behaves **exactly** the same as any
other CSS counter would for a given set of style values.
We're simply not going to add a parallel "HTML counter" implementation
that is incompatible with CSS counters just to implement these HTML
elements (in fact, we've just removed the special counting we had).

Mapping HTML lists to CSS has **major** benefits for authors and
implementors alike.  I'd be happy to elaborate on that if you wish.


> This omits all the details at [...], e.g. reversed="", the collection
> of owned list items, value="" attribute parsing, etc.

 is mapped to the 'counter-set' property.

 is the one thing that isn't yet defined fully in a CSS spec.
We have implemented it using an internal (not exposed to web content)
inherited CSS property, and then map the attribute to that.

So, what our new implementation proves is that all of HTML's funky list
items can be fully and exclusively implemented using CSS concepts.
Well, we hope so anyway.  We'll know after it hits the release channel :-)


> An important thing to test here is the result of getComputedStyle on
> list items as a result of this change. HTML specifies that ordinal
> values are displayed on list items without any counter CSS properties
> involved

Emilio filed https://github.com/w3c/csswg-drafts/issues/3769 about this.
I disagree that getComputedStyle should lie about the actual value
of any of the counter-* properties.  I see no benefit to anyone
in doing that and I also don't think it's needed for web-compatibility.


Regards,
Mats

[css-lists]
https://drafts.csswg.org/css-lists/

[css-pseudo]
https://drafts.csswg.org/css-pseudo/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[jackalmage]

Note that the spec does not yet reflect the decisions made at the last F2F, or 
the subsequent decisions from Issues.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote:
> It's great to hear that this isn't a regression in the way I expected. I 
> think I was thrown off by the phrasing of the OP, which implied to me a 
> switch from following the HTML spec to following the CSS lists spec. As I 
> noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing 
> reversed="" from affecting the counter values. But it sounds like you're 
> ignoring that part of the CSS spec, and instead incrementing (setting?) the 
> list-item counter according to the HTML spec's rules.

I don't think there's an actual contradiction.  The spec describes
the default behavior of list items, but then specifies that other
things happen through the values of CSS properties that are in the
UA stylesheet.  This is the normal way that things evolve when CSS
adds a CSS explanation for an existing feature and part of that CSS
explanation lives in the UA stylesheet.

This has been under discussion in the CSS working group for... over
a decade now, so I wouldn't say that there hasn't been any
cross-browser discussion of it.

That said, the specs could certainly coordinate better.

-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)


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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

It's great to hear that this isn't a regression in the way I expected. I think 
I was thrown off by the phrasing of the OP, which implied to me a switch from 
following the HTML spec to following the CSS lists spec. As I noted, the CSS 
lists spec contradicts the HTML spec, e.g. disallowing reversed="" from 
affecting the counter values. But it sounds like you're ignoring that part of 
the CSS spec, and instead incrementing (setting?) the list-item counter 
according to the HTML spec's rules.

I remain a bit concerned that the behavior you're implementing here is not 
reflected in any spec at all. This would not matter if this were just internal 
implementation refactoring. However, it's observable to the web via 
getComputedStyle().

Note that the complete list of allowed-per-spec default style changes for li 
elements is given by 
https://html.spec.whatwg.org/multipage/rendering.html#lists , and per 
https://github.com/web-platform-tests/wpt/issues/5625 the CSSWG declared the 
intent to test these requirements via web platform tests.

Introducing new observable behavior with no spec backing, or even opening an 
issue on the relevant specs, seems bad. Reading between the lines, it seems to 
be Mozilla's position that HTML should change to add some CSS rule to the user 
agent stylesheet which modifies counter-set, but not counter-increment. If so 
it'd be much appreciated if folks would open an issue on whatwg/html for public 
standards discussion and work toward cross-browser consensus.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser 
> mostly-interoperable behavior for list-item-like behaviors, in 
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is 
> the spec at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and 
> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
>  .
> 
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems 
> to contradict that hard-fought consensus. It states simply that
> 
> > Additionally, list items automatically increment the special list-item 
> > counter. Unless the counter-increment property manually specifies a 
> > different increment for the list-item counter, it must be incremented by 1 
> > on every list item, at the same time that counters are normally incremented.
> 
> This omits all the details at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
> e.g. reversed="", the collection of owned list items, value="" attribute 
> parsing, etc.
> 
> It seems like a regression to implement list item numbering according to that 
> spec, instead of according to HTML.

I wouldn't expect any of these features or tests to regress as a
result of this.  (That said, I think it may be worth considering
behavior changes to edge cases, if such changes are needed,
particularly where browsers aren't currently interoperable, in order
to move towards the idea of list numbering being implemented with
CSS counters underneath.)

I'd note that the sample style sheet for HTML in CSS Lists does
attempt to describe what is needed for HTML:
https://drafts.csswg.org/css-lists/#ua-stylesheet
although it admits that the CSS counter model on its own can't
describe reversed.

The web-platform-test test expectation changes in
https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 are (except
for a single test) in the direction of improvement.

-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)


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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Tom Ritter]

On Mon, Mar 25, 2019 at 10:05 PM  wrote:
> > As far as separating the value; it kind of depends on how you
> > implement it; but let's say you were going to use a static uint64_t or
> > something like that.  Instead of heaving a static uint64_t, create a
> > Dictionary and look up the uint64_t using
> > the OriginAttrbutes of the top level page.
> >
>
>
> Regarding to `touchid, IIUC, it is a data member of a Gamepad, that means the 
> attribute wouldn't be accessed across other pages. For examples, a gamepad 
> whose `touchid` is 6 and `timestamp` is 5000 in a gamepad tab, when visiting 
> to an another Gamepad tab, we will spawn a new gamepad object for this tab 
> and its `touchid` and `timestamp` are 0. Therefore, I could not finding the 
> possible usage case of OriginAttrbutes.

Oh, excellent, then the desired behavior is already built in.

> > Also, as Ehsan mentioned, we should change the spec so that touchId is
> > keyed by the top level domain.
> >
> > > In our implementation, we will wait until users' first intention like 
> > > button press, axis movement. Then, Firefox will fire a 
> > > `gamepadconnected`[1]. Chrome also does the same restriction although the 
> > > spec doesn't describe this is a must.
> > >
> > > Regarding to GamepadPose, we only implement it for VR controllers, we 
> > > only can start to poll input events once users confirm they wanna enter 
> > > the VR mode. Then, keep waiting for the first event like button press, 
> > > axis movement, or pose change. Lastly, we will fire a `gamepadconnected`. 
> > > Also, once they switch the VR tab to the background, we will close this 
> > > VR session and don't listen to VR input events any more.
> >
> > Okay, good, not making this data available until the user activity
> > engages with the gamepad/VR controller (mostly) assuages my concerns
> > on this component. My remaining concern is around the sensitivity of
> > axis movement. If I have my controller on my desk, and I am
> > typing/bumping it - I am curious if that would cause the controller to
> > suddenly activate.  I don't think I have a gamepad to test with
> > though.
> >
> > -tom
>
>
> For the sensitivity of axis movement, I aware Firefox needs do adjustments 
> for this part. The axis of gamepad in Firefox always gives its first intent 
> once its value is not 0. That means if some Gamepad axes value are not 0 even 
> they are idle, the gamepad will be activated immediately. I will fix this 
> issue shortly, I think 0.5 [0~1] threshold is a good value. (Chrome did the 
> same threadhold from my tests.)

Excellent.

On Mon, Mar 25, 2019 at 10:10 PM  wrote:
> > There's a research question that suggests: gamepad accelerometers are
> > pretty good, can they be used to recover what someone is typing based on
> > those vibrations?  Setting a minimum activation threshold to start using
> > the controller might be wise.  A button press is guaranteed to activate it,
> > so we can be a little less sensitive for that.
>
> This is a good thought although not every gamepad has vibrate function. We 
> can do this enhancement for the devices own this functionality.

I grabbed an XBox One controller (quite new, with good joysticks) and
set it on my desk to run some tests. It activates when I move a
joystick and informs the page. My normal typing does not activate it;
however if I sit down at my desk and bump the desk or put my elbows on
it with some (but not a painful amount) of force that also activates
it.

I suppose my ideal opinion here is that we only activate on button
press rather than joystick but at the least increasing the threshold
for the joystick is important.

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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Emilio Cobos Álvarez]

On 25/03/2019 06:21, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser 
> mostly-interoperable behavior for list-item-like behaviors, in 
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is 
> the spec at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and 
> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
>  .
> 
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems 
> to contradict that hard-fought consensus. It states simply that
> 
>> Additionally, list items automatically increment the special list-item 
>> counter. Unless the counter-increment property manually specifies a 
>> different increment for the list-item counter, it must be incremented by 1 
>> on every list item, at the same time that counters are normally incremented.
> 
> This omits all the details at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
> e.g. reversed="", the collection of owned list items, value="" attribute 
> parsing, etc.
> 
> It seems like a regression to implement list item numbering according to that 
> spec, instead of according to HTML.

FWIW, the check-in fixing this[1] fixed multiple WPT tests related to
this, and regressed none, see the .ini file changes.

>> web-platform-tests: 
> 
> An important thing to test here is the result of getComputedStyle on list 
> items as a result of this change. HTML specifies that ordinal values are 
> displayed on list items without any counter CSS properties involved, and from 
> what I can tell, https://drafts.csswg.org/css-lists/ does not change that. 
> (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is 
> informative, not normative.) So, including tests that getComputedStyle 
> continues to return no results for the counter-related properties or 
> pseudo-elements seems important to maintaining interop on this front.

I agree that testing this seems useful, but I disagree on it being
ignored in computed style serialization of all counter-* properties,
that feels rather magical.

I agree that the counter-increment should be ignored in computed style
serialization (I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1539171 to fix that).

Note that  attribute parsing hasn't changed, and it's just
a mapped attribute mapping to counter-set. I don't think this conflicts
with the HTML spec, and I think that we should keep 
serializing counter-set in getComputedStyle. I don't think there are
interop concerns for counter-set since counter-set is not implemented in
other engines, but attribute mapping is straight-forward and works
similarly everywhere.

 -- Emilio

[1]: https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4

> ___
> 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 implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Friday, March 22, 2019 at 9:56:20 AM UTC-7, Martin Thomson wrote:
> On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter  wrote:
> 
> > Okay, good, not making this data available until the user activity
> > engages with the gamepad/VR controller (mostly) assuages my concerns
> > on this component. My remaining concern is around the sensitivity of
> > axis movement. If I have my controller on my desk, and I am
> > typing/bumping it - I am curious if that would cause the controller to
> > suddenly activate.  I don't think I have a gamepad to test with
> > though.
> >
> 
> There's a research question that suggests: gamepad accelerometers are
> pretty good, can they be used to recover what someone is typing based on
> those vibrations?  Setting a minimum activation threshold to start using
> the controller might be wise.  A button press is guaranteed to activate it,
> so we can be a little less sensitive for that.

This is a good thought although not every gamepad has vibrate function. We can 
do this enhancement for the devices own this functionality.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Wednesday, March 20, 2019 at 7:10:54 PM UTC-7, Tom Ritter wrote:
> > > > Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> > > > touching the touchpad.  When a finger touches the touchpad, touchId of 
> > > > this event would be 1.  As that finger moves around the touchpad, new 
> > > > touch events are added with updated coordinates, however, the touchId 
> > > > is still 1 to denote that the finger has not been lifted from the 
> > > > touchpad.  If the finger is released and touches again, the touchId 
> > > > would then be 2.
> > > >
> > > > Example 2: In the case of multi touch, the first finger that touches 
> > > > the touchpad would have a touchId of 1.  The next finger that touches 
> > > > the touchpad before the first finger is released would have a touchId 
> > > > of 2.  If the first touch finger is released and touches again, that 
> > > > touchId would be 3.  This way, the application can distinguish between 
> > > > different touches that have or haven’t been removed from the touchpad.
> > >
> > >
> > > In this situation, it seems like the actual value of the field doesn't
> > > matter, only that it is increasing relative to the last value. So it
> > > should be possible to have separate values based on the origin.
> > >
> > > Not doing so creates a cross-origin tracking and fingerprinting vector.
> > >
> >
> > Thanks for your feedback!
> >
> > First of all. I am not quite sure I understand the cross-origin tracking 
> > mean, the `touchId` will increase when there is a new touch on the 
> > touchpad. It is exactly increasing relative to the last value, I would like 
> > to know why it would be an issue. We also have some APIs like timestamp 
> > that are also increased relative to the last value. If you suggest to 
> > separate the value, what is the possible approach?
> 
> Any state that is shared and exposed to unrelated origins becomes a
> potential vector for either directly tracking or otherwise correlating
> a user.  For example:
> 
> a) A heavy gamer may rack up a touchid in the millions during a
> browser session. When visiting sites a.com and b.com, they see that
> one person in particular has a gigantic touchid. They have a good idea
> it is the same visitor to both sites.
> 
> b) A user leaves a game on a.com and starts a game on b.com. By
> comparing timestamps and touchid, the sites are quite certain it is
> the same user who left with touchid 400 and appeared with touchid 401.
> 
> As far as separating the value; it kind of depends on how you
> implement it; but let's say you were going to use a static uint64_t or
> something like that.  Instead of heaving a static uint64_t, create a
> Dictionary and look up the uint64_t using
> the OriginAttrbutes of the top level page.
> 


Regarding to `touchid, IIUC, it is a data member of a Gamepad, that means the 
attribute wouldn't be accessed across other pages. For examples, a gamepad 
whose `touchid` is 6 and `timestamp` is 5000 in a gamepad tab, when visiting to 
an another Gamepad tab, we will spawn a new gamepad object for this tab and its 
`touchid` and `timestamp` are 0. Therefore, I could not finding the possible 
usage case of OriginAttrbutes.

 

> Also, as Ehsan mentioned, we should change the spec so that touchId is
> keyed by the top level domain.
> 
> > In our implementation, we will wait until users' first intention like 
> > button press, axis movement. Then, Firefox will fire a 
> > `gamepadconnected`[1]. Chrome also does the same restriction although the 
> > spec doesn't describe this is a must.
> >
> > Regarding to GamepadPose, we only implement it for VR controllers, we only 
> > can start to poll input events once users confirm they wanna enter the VR 
> > mode. Then, keep waiting for the first event like button press, axis 
> > movement, or pose change. Lastly, we will fire a `gamepadconnected`. Also, 
> > once they switch the VR tab to the background, we will close this VR 
> > session and don't listen to VR input events any more.
> 
> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my controller on my desk, and I am
> typing/bumping it - I am curious if that would cause the controller to
> suddenly activate.  I don't think I have a gamepad to test with
> though.
> 
> -tom


For the sensitivity of axis movement, I aware Firefox needs do adjustments for 
this part. The axis of gamepad in Firefox always gives its first intent once 
its value is not 0. That means if some Gamepad axes value are not 0 even they 
are idle, the gamepad will be activated immediately. I will fix this issue 
shortly, I think 0.5 [0~1] threshold is a good value. (Chrome did the same 
threadhold from my tests.)


Cheers,
Daosheng Mu.

___
dev-platform mailing list
dev-platform@lists.moz

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote:


> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element

correction, 
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-li-element
 is where most of the tests landed. The pull request was 
https://github.com/web-platform-tests/wpt/pull/4169 .
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

Some time ago we spent some effort documenting a cross-browser 
mostly-interoperable behavior for list-item-like behaviors, in 
https://github.com/whatwg/html/pull/2002 and linked threads. The result is the 
spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner 
and the tests at 
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
 .

The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to 
contradict that hard-fought consensus. It states simply that

> Additionally, list items automatically increment the special list-item 
> counter. Unless the counter-increment property manually specifies a different 
> increment for the list-item counter, it must be incremented by 1 on every 
> list item, at the same time that counters are normally incremented.

This omits all the details at 
https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
e.g. reversed="", the collection of owned list items, value="" attribute 
parsing, etc.

It seems like a regression to implement list item numbering according to that 
spec, instead of according to HTML.

> web-platform-tests: 

An important thing to test here is the result of getComputedStyle on list items 
as a result of this change. HTML specifies that ordinal values are displayed on 
list items without any counter CSS properties involved, and from what I can 
tell, https://drafts.csswg.org/css-lists/ does not change that. (The appendix 
at https://drafts.csswg.org/css-lists/#ua-stylesheet is informative, not 
normative.) So, including tests that getComputedStyle continues to return no 
results for the counter-related properties or pseudo-elements seems important 
to maintaining interop on this front.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS ::marker pseudo-element

[Mats Palmgren]

Summary:
The ::marker pseudo-element represents the automatically generated
marker box of a list item.  It allows authors to style the marker
and generate content for it through its 'content' property (like
::before/::after).

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=205202
Animation support is pending:
https://bugzilla.mozilla.org/show_bug.cgi?id=1538618

Link to standard:
https://drafts.csswg.org/css-pseudo-4/#marker-pseudo
https://drafts.csswg.org/css-lists/#markers
https://github.com/w3c/csswg-drafts/issues/3499

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none (I've checked that a ::marker shows up as
a pseudo in the panel with ::before/::after and it appears
to work fine)

Do other browser engines implement this?
Safari implements limited support for ::marker (it doesn't support
the 'content' property, and it has no support for the built-in
'list-item' counter, both which are major pieces of this general
feature).  Chrome supports none of it AFAICT.
https://wpt.fyi/results/css/css-pseudo

web-platform-tests:
There are some tests in css/css-pseudo/ and I've added
a bunch more.

Is this feature restricted to secure contexts? No

Many thanks to Emilio who patiently reviewed all of these list
item related changes.


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

Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

Summary:
The built-in 'list-item' counter is used to implement HTML /
(and other elements with display:list-item) using CSS.

I'm also removing our old (frame-based) code for list item counters,
which had a number of decades-old bugs (bug 4522 et al), was rather
slow (bug 3246) and crashy (bug 1515124).

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

Link to standard:
https://drafts.csswg.org/css-lists/#declaring-a-list-item

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none

Do other browser engines implement this?
No, as far as I can tell.

web-platform-tests:
I added a couple of WPTs in css/css-lists/ and there are some
in css/CSS2/lists which we now pass.  Also, given that we now
use this built-in counter for all display:list-item elements
we should have basic coverage from existing tests for those.

Is this feature restricted to secure contexts? No


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

Intent to implement and ship: CSS counter-set property

[Mats Palmgren]

Summary:
The counter-set CSS property assigns an absolute value to a CSS counter.
(It behaves the same as counter-increment but assigns instead of
increments.)

It will be used internally to map  to set the value of
the built-in 'list-item' counter (see separate announcement following
this).

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

Link to standard:
https://drafts.csswg.org/css-lists/#propdef-counter-set

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none

Do other browser engines implement this?
No, as far as I know.

web-platform-tests:
I added some under css/css-lists/.  (It will also be tested
indirectly through .)

Is this feature restricted to secure contexts? No


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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Martin Thomson]

On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter  wrote:

> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my controller on my desk, and I am
> typing/bumping it - I am curious if that would cause the controller to
> suddenly activate.  I don't think I have a gamepad to test with
> though.
>

There's a research question that suggests: gamepad accelerometers are
pretty good, can they be used to recover what someone is typing based on
those vibrations?  Setting a minimum activation threshold to start using
the controller might be wise.  A button press is guaranteed to activate it,
so we can be a little less sensitive for that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Tom Ritter]

> > > Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> > > touching the touchpad.  When a finger touches the touchpad, touchId of 
> > > this event would be 1.  As that finger moves around the touchpad, new 
> > > touch events are added with updated coordinates, however, the touchId is 
> > > still 1 to denote that the finger has not been lifted from the touchpad.  
> > > If the finger is released and touches again, the touchId would then be 2.
> > >
> > > Example 2: In the case of multi touch, the first finger that touches the 
> > > touchpad would have a touchId of 1.  The next finger that touches the 
> > > touchpad before the first finger is released would have a touchId of 2.  
> > > If the first touch finger is released and touches again, that touchId 
> > > would be 3.  This way, the application can distinguish between different 
> > > touches that have or haven’t been removed from the touchpad.
> >
> >
> > In this situation, it seems like the actual value of the field doesn't
> > matter, only that it is increasing relative to the last value. So it
> > should be possible to have separate values based on the origin.
> >
> > Not doing so creates a cross-origin tracking and fingerprinting vector.
> >
>
> Thanks for your feedback!
>
> First of all. I am not quite sure I understand the cross-origin tracking 
> mean, the `touchId` will increase when there is a new touch on the touchpad. 
> It is exactly increasing relative to the last value, I would like to know why 
> it would be an issue. We also have some APIs like timestamp that are also 
> increased relative to the last value. If you suggest to separate the value, 
> what is the possible approach?

Any state that is shared and exposed to unrelated origins becomes a
potential vector for either directly tracking or otherwise correlating
a user.  For example:

a) A heavy gamer may rack up a touchid in the millions during a
browser session. When visiting sites a.com and b.com, they see that
one person in particular has a gigantic touchid. They have a good idea
it is the same visitor to both sites.

b) A user leaves a game on a.com and starts a game on b.com. By
comparing timestamps and touchid, the sites are quite certain it is
the same user who left with touchid 400 and appeared with touchid 401.

As far as separating the value; it kind of depends on how you
implement it; but let's say you were going to use a static uint64_t or
something like that.  Instead of heaving a static uint64_t, create a
Dictionary and look up the uint64_t using
the OriginAttrbutes of the top level page.

Also, as Ehsan mentioned, we should change the spec so that touchId is
keyed by the top level domain.

> In our implementation, we will wait until users' first intention like button 
> press, axis movement. Then, Firefox will fire a `gamepadconnected`[1]. Chrome 
> also does the same restriction although the spec doesn't describe this is a 
> must.
>
> Regarding to GamepadPose, we only implement it for VR controllers, we only 
> can start to poll input events once users confirm they wanna enter the VR 
> mode. Then, keep waiting for the first event like button press, axis 
> movement, or pose change. Lastly, we will fire a `gamepadconnected`. Also, 
> once they switch the VR tab to the background, we will close this VR session 
> and don't listen to VR input events any more.

Okay, good, not making this data available until the user activity
engages with the gamepad/VR controller (mostly) assuages my concerns
on this component. My remaining concern is around the sensitivity of
axis movement. If I have my controller on my desk, and I am
typing/bumping it - I am curious if that would cause the controller to
suddenly activate.  I don't think I have a gamepad to test with
though.

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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Friday, March 15, 2019 at 8:35:41 AM UTC-7, Tom Ritter wrote:
> Thanks for more details on the use case.
> 
> On Wed, Mar 6, 2019 at 1:35 AM  wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading this correctly [1], the fingerprinting risks are
> > > pretty extreme here.  In the touch spec, we have a monotonically 
> > > increasing
> > > counter that doesn't appear to be origin-bound in any way.  What is the
> > > purpose of this identifier?  In the light spec, we have full RGB control
> > > over the light.  Does the light change back to a default state when the
> > > origin is no longer the primary input focus?
> > >
> > > Implementing specs of a private GitHub account is fine for the purposes of
> > > getting feedback, but I think that we want a clearer signal that this is 
> > > an
> > > accepted approach before we ship something like this.  When you consider
> > > the potential for security and privacy implications, this is particularly
> > > important.
> > >
> > >
> >
> > Hi Martin,
> >
> > Sorry for reply late.
> > We will restrict theses APIs to secure contexts to help it be more secure. 
> > Regarding to the touchId, the reason we wanna make it monotonically 
> > increasing is order to recognize if fingers have been released after the 
> > last touch. Let me give you two examples.
> >
> > Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> > touching the touchpad.  When a finger touches the touchpad, touchId of this 
> > event would be 1.  As that finger moves around the touchpad, new touch 
> > events are added with updated coordinates, however, the touchId is still 1 
> > to denote that the finger has not been lifted from the touchpad.  If the 
> > finger is released and touches again, the touchId would then be 2.
> >
> > Example 2: In the case of multi touch, the first finger that touches the 
> > touchpad would have a touchId of 1.  The next finger that touches the 
> > touchpad before the first finger is released would have a touchId of 2.  If 
> > the first touch finger is released and touches again, that touchId would be 
> > 3.  This way, the application can distinguish between different touches 
> > that have or haven’t been removed from the touchpad.
> 
> 
> In this situation, it seems like the actual value of the field doesn't
> matter, only that it is increasing relative to the last value. So it
> should be possible to have separate values based on the origin.
> 
> Not doing so creates a cross-origin tracking and fingerprinting vector.
> 

Thanks for your feedback!

First of all. I am not quite sure I understand the cross-origin tracking mean, 
the `touchId` will increase when there is a new touch on the touchpad. It is 
exactly increasing relative to the last value, I would like to know why it 
would be an issue. We also have some APIs like timestamp that are also 
increased relative to the last value. If you suggest to separate the value, 
what is the possible approach?

> 
> > In terms of lightColor,  we would give the default color to [0, 0, 0] if 
> > there is no one set it yet or when it is just plugged in. Then, the 
> > application is allowed to set the controller's lightbar color whenever they 
> > want. I have reached the author and ask him add this description into his 
> > proposal.
> 
> It appears that one can set but cannot read the lightColor, so that's good.
> 
> GamepadPose gives me a lot of concern as well. If I have a gamepad
> resting on my desk, I don't want every website to get a persistent
> identifier about me because of the pose it's resting in.  I think/hope
> that there's something in the main gamepad spec where you can't
> enumerate gamepads until the user has interacted with them, but I
> don't recall for sure.
> 
> I am very opposed to shipping this spec without addressing these concerns.
> 
> -tom

In our implementation, we will wait until users' first intention like button 
press, axis movement. Then, Firefox will fire a `gamepadconnected`[1]. Chrome 
also does the same restriction although the spec doesn't describe this is a 
must.

Regarding to GamepadPose, we only implement it for VR controllers, we only can 
start to poll input events once users confirm they wanna enter the VR mode. 
Then, keep waiting for the first event like button press, axis movement, or 
pose change. Lastly, we will fire a `gamepadconnected`. Also, once they switch 
the VR tab to the background, we will close this VR session and don't listen to 
VR input events any more.


[1] 
https://dxr.mozilla.org/mozilla-central/rev/25398e555020fef80c7b2a06a0d4c667e861cd6f/dom/gamepad/GamepadManager.cpp#425


- Daosheng Mu

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

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

It's https://bugzilla.mozilla.org/show_bug.cgi?id=1532850, it was at a
deeper level of blockers of bug 1494034, now I added bug 1532850 in the
dependency list of bug 1494034.

Thanks,
hiro

On Wed, Mar 20, 2019 at 9:42 AM Eric Shepherd (Sheppy) <
esheph...@mozilla.com> wrote:

> Presumably that’s noted appropriately in some manner in Bugzilla?
>
> On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
> wrote:
>
> The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
>
> just landed on mozilla-central, will be shipped in Firefox 68.
>
>
> Eric Shepherd
> Senior Technical Writer
> MDN Web Docs 
> Blog: https://www.bitstampede.com/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Eric Shepherd (Sheppy)]

Presumably that’s noted appropriately in some manner in Bugzilla?

On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
wrote:

The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.


Eric Shepherd
Senior Technical Writer
MDN Web Docs 
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Hiroyuki Ikezoe]

The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.

Thanks,
hiro

On Sat, Feb 16, 2019 at 5:38 AM Mats Palmgren  wrote:

> Summary:
> The 'prefers-color-scheme' media feature is way for pages to detect
> if the user prefers a light or dark color theme.  The values are
> 'light', 'dark', and 'no-preference'.  If the "resist fingerprinting"
> feature is active we always match 'light'.  If the media type is
> 'print' we always match 'light'.  Otherwise, we try to determine
> a value from the user's current "desktop theme".  This should work
> well on recent versions of OSX and Windows.  On Linux, we don't
> know how to determine a value from the system so we match
> 'no-preference' there - help wanted:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1525775
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1494034
>
> Link to standard:
> https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 67
>
> Preference behind which this will be implemented:
> The feature is always enabled, but there is an existing hidden
> preference to set a value (integer), ui.systemUsesDarkTheme:
> 0 = light
> 1 = dark
> 2 = no-preference
>
> Is this feature enabled by default in sandboxed iframes?
> Yes, but if widget look-and-feel features are disabled in
> sandboxed iframes then we'll match 'no-preference'.
>
> DevTools bug: none
>
> Do other browser engines implement this?
> Safari has implemented this feature and it's available in their
> Nightly build, but it's not yet shipped AFAICT.
> https://paulmillr.com/posts/using-dark-mode-in-css/ is a post about
> implementation of this feature in Safari;
>
> https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/
> documents its addition.
>
> It appears Chrome is actively working on it:
> https://bugs.chromium.org/p/chromium/issues/detail?id=889087
>
> web-platform-tests:
> https://w3c-test.org/css/mediaqueries/prefers-color-scheme.html
>
> Is this feature restricted to secure contexts? No
>
> Credit also goes to Jonathan Kingston who wrote the initial
> implementation of this feature.
>
>
> /Mats
> ___
> 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 implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Ehsan Akhgari]

On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter  wrote:

> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM  wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading this correctly [1], the fingerprinting risks
> are
> > > pretty extreme here.  In the touch spec, we have a monotonically
> increasing
> > > counter that doesn't appear to be origin-bound in any way.  What is the
> > > purpose of this identifier?  In the light spec, we have full RGB
> control
> > > over the light.  Does the light change back to a default state when the
> > > origin is no longer the primary input focus?
> > >
> > > Implementing specs of a private GitHub account is fine for the
> purposes of
> > > getting feedback, but I think that we want a clearer signal that this
> is an
> > > accepted approach before we ship something like this.  When you
> consider
> > > the potential for security and privacy implications, this is
> particularly
> > > important.
> > >
> > >
> >
> > Hi Martin,
> >
> > Sorry for reply late.
> > We will restrict theses APIs to secure contexts to help it be more
> secure. Regarding to the touchId, the reason we wanna make it monotonically
> increasing is order to recognize if fingers have been released after the
> last touch. Let me give you two examples.
> >
> > Example 1: Let’s say touchId is currently set to 0 and no fingers are
> touching the touchpad.  When a finger touches the touchpad, touchId of this
> event would be 1.  As that finger moves around the touchpad, new touch
> events are added with updated coordinates, however, the touchId is still 1
> to denote that the finger has not been lifted from the touchpad.  If the
> finger is released and touches again, the touchId would then be 2.
> >
> > Example 2: In the case of multi touch, the first finger that touches the
> touchpad would have a touchId of 1.  The next finger that touches the
> touchpad before the first finger is released would have a touchId of 2.  If
> the first touch finger is released and touches again, that touchId would be
> 3.  This way, the application can distinguish between different touches
> that have or haven’t been removed from the touchpad.
>
>
> In this situation, it seems like the actual value of the field doesn't
> matter, only that it is increasing relative to the last value. So it
> should be possible to have separate values based on the origin.
>

I assume you mean the origin of the top-level page here.

As far as I can tell from the current spec, we can implement this
restriction based on the current spec but since we are the first engine to
ship this it seems prudent to change the spec as well in order to ensure
all future implementations would implement this in a privacy-preserving
manner.


> Not doing so creates a cross-origin tracking and fingerprinting vector.
>
>
> > In terms of lightColor,  we would give the default color to [0, 0, 0] if
> there is no one set it yet or when it is just plugged in. Then, the
> application is allowed to set the controller's lightbar color whenever they
> want. I have reached the author and ask him add this description into his
> proposal.
>
> It appears that one can set but cannot read the lightColor, so that's good.
>
> GamepadPose gives me a lot of concern as well. If I have a gamepad
> resting on my desk, I don't want every website to get a persistent
> identifier about me because of the pose it's resting in.  I think/hope
> that there's something in the main gamepad spec where you can't
> enumerate gamepads until the user has interacted with them, but I
> don't recall for sure.
>

There is: https://w3c.github.io/gamepad/#dom-navigator-getgamepads.  But
note that with resist fingerprinting mode we always return an empty array
from navigator.getGamepads().


> I am very opposed to shipping this spec without addressing these concerns.
>
> -tom
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Tom Ritter]

Thanks for more details on the use case.

On Wed, Mar 6, 2019 at 1:35 AM  wrote:
>
> On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > To add to Dan's comments here...
> >
> > Assuming that I'm reading this correctly [1], the fingerprinting risks are
> > pretty extreme here.  In the touch spec, we have a monotonically increasing
> > counter that doesn't appear to be origin-bound in any way.  What is the
> > purpose of this identifier?  In the light spec, we have full RGB control
> > over the light.  Does the light change back to a default state when the
> > origin is no longer the primary input focus?
> >
> > Implementing specs of a private GitHub account is fine for the purposes of
> > getting feedback, but I think that we want a clearer signal that this is an
> > accepted approach before we ship something like this.  When you consider
> > the potential for security and privacy implications, this is particularly
> > important.
> >
> >
>
> Hi Martin,
>
> Sorry for reply late.
> We will restrict theses APIs to secure contexts to help it be more secure. 
> Regarding to the touchId, the reason we wanna make it monotonically 
> increasing is order to recognize if fingers have been released after the last 
> touch. Let me give you two examples.
>
> Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> touching the touchpad.  When a finger touches the touchpad, touchId of this 
> event would be 1.  As that finger moves around the touchpad, new touch events 
> are added with updated coordinates, however, the touchId is still 1 to denote 
> that the finger has not been lifted from the touchpad.  If the finger is 
> released and touches again, the touchId would then be 2.
>
> Example 2: In the case of multi touch, the first finger that touches the 
> touchpad would have a touchId of 1.  The next finger that touches the 
> touchpad before the first finger is released would have a touchId of 2.  If 
> the first touch finger is released and touches again, that touchId would be 
> 3.  This way, the application can distinguish between different touches that 
> have or haven’t been removed from the touchpad.


In this situation, it seems like the actual value of the field doesn't
matter, only that it is increasing relative to the last value. So it
should be possible to have separate values based on the origin.

Not doing so creates a cross-origin tracking and fingerprinting vector.


> In terms of lightColor,  we would give the default color to [0, 0, 0] if 
> there is no one set it yet or when it is just plugged in. Then, the 
> application is allowed to set the controller's lightbar color whenever they 
> want. I have reached the author and ask him add this description into his 
> proposal.

It appears that one can set but cannot read the lightColor, so that's good.

GamepadPose gives me a lot of concern as well. If I have a gamepad
resting on my desk, I don't want every website to get a persistent
identifier about me because of the pose it's resting in.  I think/hope
that there's something in the main gamepad spec where you can't
enumerate gamepads until the user has interacted with them, but I
don't recall for sure.

I am very opposed to shipping this spec without addressing these concerns.

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

Re: Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[Hiroyuki Ikezoe]

Hello, fantasai!

On Sun, Mar 10, 2019 at 6:14 AM fantasai 
wrote:

> 1. Handling overlarge snap areas per
> https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
> This is important to make content accessible on smaller-than-expected
> screens.
>

I think I've finished this properly, but..

2. Handling scroll-padding correctly even when snapping is turned off,
> since it should affect all paging operations and scroll-into-view
> operations. https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding
>
> 3. Likewise, supporting scroll-margin's effects even when snapping is off:
> it still be adjusting the element's scroll-into-view area
> https://www.w3.org/TR/css-scroll-snap-1/#scroll-margin
>

I was totally misunderstanding these two. Filed bug 1534070 for that.

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

Re: Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[fantasai]

All of this sounds great to me, and I'm pretty excited that Mozilla will
be updating to the latest spec. Most of the changes were in response to
roc's feedback on the spec, and make it a much more robust system for the
variable environment of the Web.

There's a couple things I want to make sure you watch out for and get
right before shipping:

1. Handling overlarge snap areas per 
https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
   This is important to make content accessible on smaller-than-expected 
screens.

2. Handling scroll-padding correctly even when snapping is turned off,
   since it should affect all paging operations and scroll-into-view
   operations. https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding

3. Likewise, supporting scroll-margin's effects even when snapping is off:
   it still be adjusting the element's scroll-into-view area
   https://www.w3.org/TR/css-scroll-snap-1/#scroll-margin

Also, feel free to complain at me if anything in the spec is unclear. :)
https://github.com/w3c/csswg-drafts/issues
IRC: fantasai
Bugzilla: fantasai.b...@inkedblade.net

~fantasai


On 3/8/19 4:51 PM, Hiroyuki Ikezoe wrote:

Summary:
   The scroll snap specification has been significantly changed since we
  implemented.  scroll-snap-coordinate, scroll-snap-destination and
  scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
  scroll-snap-margin and scroll-snap-padding were added in the spec.  Also,
  scroll-snap-type was changed to a longhand property and its syntax was
  changed in the spec.
   Due to the scroll-snap-type change, this migration will happen
irreversibly
  in terms of the scroll-snap-type property.  Once the change happens in bug
  1312163 [1], you can no longer use the old longhands,
scroll-snap-type-{x,y},
  and no longer use the old shorthand syntax like `scroll-snap-type:
mandatory`.
  That means that, for example, sites specifying only scroll-snap-type-x will
  be broken.  To mitigate it, I am going to land a bunch of relevant stuff
at the
  same time so that we can switch to the new scroll snap at once.

Bug:
  A meta bug is
   https://bugzilla.mozilla.org/show_bug.cgi?id=1231777

Link to standard:
  https://drafts.csswg.org/css-scroll-snap-1/

Platform coverage: all

Estimated or target release: Firefox 68

Preference behind which this will be implemented:
  layout.css.scroll-snap-v1.enabled

Is this feature enabled by default in sandboxed iframes?
  Yes

DevTools bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1133666

Do other browser engines implement this?
  Chrome and Safari already shipped

web-platform-tests:
  http://w3c-test.org/css/css-scroll-snap/

Additional notes:
  scroll-snap-stop which was introduced in the new spec is not going to be
  implemented now since it's marked at-risk in the spec

Thanks,
hiro

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312163



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

Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[Hiroyuki Ikezoe]

Summary:
  The scroll snap specification has been significantly changed since we
 implemented.  scroll-snap-coordinate, scroll-snap-destination and
 scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
 scroll-snap-margin and scroll-snap-padding were added in the spec.  Also,
 scroll-snap-type was changed to a longhand property and its syntax was
 changed in the spec.
  Due to the scroll-snap-type change, this migration will happen
irreversibly
 in terms of the scroll-snap-type property.  Once the change happens in bug
 1312163 [1], you can no longer use the old longhands,
scroll-snap-type-{x,y},
 and no longer use the old shorthand syntax like `scroll-snap-type:
mandatory`.
 That means that, for example, sites specifying only scroll-snap-type-x will
 be broken.  To mitigate it, I am going to land a bunch of relevant stuff
at the
 same time so that we can switch to the new scroll snap at once.

Bug:
 A meta bug is
  https://bugzilla.mozilla.org/show_bug.cgi?id=1231777

Link to standard:
 https://drafts.csswg.org/css-scroll-snap-1/

Platform coverage: all

Estimated or target release: Firefox 68

Preference behind which this will be implemented:
 layout.css.scroll-snap-v1.enabled

Is this feature enabled by default in sandboxed iframes?
 Yes

DevTools bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1133666

Do other browser engines implement this?
 Chrome and Safari already shipped

web-platform-tests:
 http://w3c-test.org/css/css-scroll-snap/

Additional notes:
 scroll-snap-stop which was introduced in the new spec is not going to be
 implemented now since it's marked at-risk in the spec

Thanks,
hiro

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> To add to Dan's comments here...
> 
> Assuming that I'm reading this correctly [1], the fingerprinting risks are
> pretty extreme here.  In the touch spec, we have a monotonically increasing
> counter that doesn't appear to be origin-bound in any way.  What is the
> purpose of this identifier?  In the light spec, we have full RGB control
> over the light.  Does the light change back to a default state when the
> origin is no longer the primary input focus?
> 
> Implementing specs of a private GitHub account is fine for the purposes of
> getting feedback, but I think that we want a clearer signal that this is an
> accepted approach before we ship something like this.  When you consider
> the potential for security and privacy implications, this is particularly
> important.
> 
> 

Hi Martin,

Sorry for reply late. 
We will restrict theses APIs to secure contexts to help it be more secure. 
Regarding to the touchId, the reason we wanna make it monotonically increasing 
is order to recognize if fingers have been released after the last touch. Let 
me give you two examples.
 
Example 1: Let’s say touchId is currently set to 0 and no fingers are touching 
the touchpad.  When a finger touches the touchpad, touchId of this event would 
be 1.  As that finger moves around the touchpad, new touch events are added 
with updated coordinates, however, the touchId is still 1 to denote that the 
finger has not been lifted from the touchpad.  If the finger is released and 
touches again, the touchId would then be 2.

Example 2: In the case of multi touch, the first finger that touches the 
touchpad would have a touchId of 1.  The next finger that touches the touchpad 
before the first finger is released would have a touchId of 2.  If the first 
touch finger is released and touches again, that touchId would be 3.  This way, 
the application can distinguish between different touches that have or haven’t 
been removed from the touchpad.

In terms of lightColor,  we would give the default color to [0, 0, 0] if there 
is no one set it yet or when it is just plugged in. Then, the application is 
allowed to set the controller's lightbar color whenever they want. I have 
reached the author and ask him add this description into his proposal.
 

Cheers,
Daosheng Mu


> 
> On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu  wrote:
> 
> > Hi Daniel,
> >
> > We didn't have a chance to discuss privacy issues in Gamepad Extension or
> > Gamepad API. We were trying to get responses for the Privacy review [1] but
> > without any updates yet.
> >
> > Cheers,
> >
> > [1]
> > https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
> >
> > --
> > Daosheng Mu
> > Software Engineer | Mozilla
> > d...@mozilla.com
> >
> >
> > On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz  wrote:
> >
> > > Neither of the words "security" or "privacy" appear in this spec (most w3
> > > web specs have at least a token attempt at a "Privacy and Security
> > > Considerations" section). At a surface glance this appears to add
> > > additional fingerprinting exposure. Have you talked to the privacy team
> > > about ways to minimize this?
> > >
> > > -Dan Veditz
> > >
> > > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:
> > >
> > >> Summary:
> > >> In order to support controllers which have multi touch and light bar
> > >> features like Sony DualShock 4. The `*multi touch*` and `*light
> > >> indicator*`
> > >> APIs for gamepad extensions are the things we must have. In
> > >> `*GamepadTouch*`
> > >> API, it would make us know touch surface's dimension and its unique id.
> > We
> > >> also will have a way to know where is the place we are touching
> > according
> > >> to its position and the unique id. Regarding to
> > `*GamepadLightIndicator*`,
> > >> it could tell users the color of controller's light bar. The color is a
> > >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
> > >> colors to indicate the on-off light indicator is ON.
> > >>
> > >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
> > >>
> > >> Link to standard:
> > >> W3C Multi touch spec proposal:
> > >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
> > >> W3C Light indicator spec proposal:
> > >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
> > >>
> > >> Platform coverage: Windows, Mac OS, Linux
> > >>
> > >> Estimated or target release: Firefox 68
> > >>
> > >> Preference behind which this will be implemented:
> > >> "dom.gamepad.extensions.multitouch" and
> > >> "dom.gamepad.extensions.lightindicator"
> > >>
> > >> Do other browser engines implement this? Nope
> > >>
> > >> web-platform-tests: none exist (and I don't plan to write WPTs but we do
> > >> have gamepad mochitest, I will add new tests to cover these two new
> > APIs.)
> > >>
> > >> Is this feature restricted to secure contexts? Nope
> > >>
> > >> How stable is the spec? This is

Intent to Implement and Ship: CSS revert keyword.

[Emilio Cobos Álvarez]

Summary: The CSS `revert` wide-keyword allows authors to ignore all CSS
rules in a given cascade origin[1], while applying rules from other
cascade origins. Trivial example would be:


div {
  display: inline;
}

// somewhere further down...
div {
  display: revert; /* Goes back to display: block */
}


Authors already have the `unset`, `initial` and `inherit` wide-keywords.
Unfortunately, none of them would turn the  to its "default" style
(display: block), since that rule is in a user-agent stylesheet that
would be overridden by the declaration. `revert` allows authors to do that.

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

Spec: https://drafts.csswg.org/css-cascade/#default

Platforms: all

Estimated or target release: 67

Preference behind which this will be implemented: None, the
css-wide-keyword parsing code is hot, and I don't think there's a way
for this to backfire. But happy to add one if wanted I guess.

Is this feature enabled by default in sandboxed iframes?: Yes

DevTools bug: Devtools autocompletion would work the same way it works
for other wide keywords, so I don't think any special devtools
integration is needed.

Do other browser engines implement this?
Safari has shipped this for quite a while (9.1 on desktop, 9.3 on
mobile, according to MDN[2]). No other engine implements this, however.
Relevant crbug for Blink is [3].

web-platform-tests: There's a very basic WPT test for revert's
functionality. It's not that complex of a (user-facing, at least)
functionality to begin with. It's a bit hard to test much further than
that because you depend on which particular declarations are on the UA
stylesheet (I used the internal property_database.js to test it using a
mochitest).

Any bugfixes or such that I need to do will be added to WPT if possible.

Is this feature restricted to secure contexts? No, like other CSS syntax
features.


 -- Emilio

[1]: https://drafts.csswg.org/css-cascade/#cascade-origins
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/revert
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=579788
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Ted Mielczarek]

On Wed, Feb 27, 2019, at 6:43 AM, James Graham wrote:
> The current thinking is that hardware interaction APIs which rely on 
> mocks to test should specify the API for testing as part of the 
> specification (e.g. [1]). So it seems like the same approach could be 
> used here.
> 
> [1] https://webbluetoothcg.github.io/web-bluetooth/tests

This is neat! I don't think I had seen any prior art for this when we were 
doing the original Gamepad API work. It seems like it would be straightforward 
to take the existing Gamepad test interface[1] we use for Mochitests and 
include it in the Gamepad spec in a form that could be used for 
web-platform-tests.

-Ted

1. 
https://searchfox.org/mozilla-central/rev/2a6f3dde00801374d3b2a704232de54a132af389/dom/webidl/GamepadServiceTest.webidl
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[James Graham]

On 26/02/2019 22:49, d...@mozilla.com wrote:

On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:

On 25/02/2019 19:44, Daosheng Mu wrote:


web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these two new APIs.)


Why do you plan to not write web-platform-tests? I imagine there may be
technical challenges, but we should ensure that those are well
understood before falling back on browser-specific tests.

In the absence of web-platform-tests what's the strategy to ensure that
implementations of this feature are interoperable and we don't end up
fighting compat fires in the future?



Gamepad tests require a real gamepad to run them, so wpt/gamepad are all manual 
tests in Firefox [1]. Our solution is making a GamepadTestService to help us do 
this puppet tests, the GamepadTestService will be launched once we run our 
gamepad mochitest and perform as a real gamepad under our automated testing. 
Besides, there is no tests for Gamepad extension so far. Therefore, if there is 
no big change, I would continue following the same scenario as before.


The current thinking is that hardware interaction APIs which rely on 
mocks to test should specify the API for testing as part of the 
specification (e.g. [1]). So it seems like the same approach could be 
used here.


[1] https://webbluetoothcg.github.io/web-bluetooth/tests
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:
> On 25/02/2019 19:44, Daosheng Mu wrote:
> 
> > web-platform-tests: none exist (and I don't plan to write WPTs but we do
> > have gamepad mochitest, I will add new tests to cover these two new APIs.)
> 
> Why do you plan to not write web-platform-tests? I imagine there may be 
> technical challenges, but we should ensure that those are well 
> understood before falling back on browser-specific tests.
> 
> In the absence of web-platform-tests what's the strategy to ensure that 
> implementations of this feature are interoperable and we don't end up 
> fighting compat fires in the future?


Gamepad tests require a real gamepad to run them, so wpt/gamepad are all manual 
tests in Firefox [1]. Our solution is making a GamepadTestService to help us do 
this puppet tests, the GamepadTestService will be launched once we run our 
gamepad mochitest and perform as a real gamepad under our automated testing. 
Besides, there is no tests for Gamepad extension so far. Therefore, if there is 
no big change, I would continue following the same scenario as before.


[1] https://github.com/web-platform-tests/wpt/tree/master/gamepad
[2] 
https://searchfox.org/mozilla-central/source/dom/tests/mochitest/gamepad/mock_gamepad.js

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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Daosheng Mu]

--
Daosheng Mu
Software Engineer | Mozilla
d...@mozilla.com


On Tue, Feb 26, 2019 at 1:14 AM Julien Cristau  wrote:

> On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu  wrote:
>
>> Is this feature restricted to secure contexts? Nope
>>
>
> Why not?
>
> I agree. I will make it be restricted to secure contexts especially for
this kind of hardware API. Actually, I also think all Gamepad API should
only allowed to be access in secure contexts.


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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[James Graham]

On 25/02/2019 19:44, Daosheng Mu wrote:


web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these two new APIs.)


Why do you plan to not write web-platform-tests? I imagine there may be 
technical challenges, but we should ensure that those are well 
understood before falling back on browser-specific tests.


In the absence of web-platform-tests what's the strategy to ensure that 
implementations of this feature are interoperable and we don't end up 
fighting compat fires in the future?

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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Julien Cristau]

On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu  wrote:

> Is this feature restricted to secure contexts? Nope
>

Why not?

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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Martin Thomson]

To add to Dan's comments here...

Assuming that I'm reading this correctly [1], the fingerprinting risks are
pretty extreme here.  In the touch spec, we have a monotonically increasing
counter that doesn't appear to be origin-bound in any way.  What is the
purpose of this identifier?  In the light spec, we have full RGB control
over the light.  Does the light change back to a default state when the
origin is no longer the primary input focus?

Implementing specs of a private GitHub account is fine for the purposes of
getting feedback, but I think that we want a clearer signal that this is an
accepted approach before we ship something like this.  When you consider
the potential for security and privacy implications, this is particularly
important.



On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu  wrote:

> Hi Daniel,
>
> We didn't have a chance to discuss privacy issues in Gamepad Extension or
> Gamepad API. We were trying to get responses for the Privacy review [1] but
> without any updates yet.
>
> Cheers,
>
> [1]
> https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
>
> --
> Daosheng Mu
> Software Engineer | Mozilla
> d...@mozilla.com
>
>
> On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz  wrote:
>
> > Neither of the words "security" or "privacy" appear in this spec (most w3
> > web specs have at least a token attempt at a "Privacy and Security
> > Considerations" section). At a surface glance this appears to add
> > additional fingerprinting exposure. Have you talked to the privacy team
> > about ways to minimize this?
> >
> > -Dan Veditz
> >
> > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:
> >
> >> Summary:
> >> In order to support controllers which have multi touch and light bar
> >> features like Sony DualShock 4. The `*multi touch*` and `*light
> >> indicator*`
> >> APIs for gamepad extensions are the things we must have. In
> >> `*GamepadTouch*`
> >> API, it would make us know touch surface's dimension and its unique id.
> We
> >> also will have a way to know where is the place we are touching
> according
> >> to its position and the unique id. Regarding to
> `*GamepadLightIndicator*`,
> >> it could tell users the color of controller's light bar. The color is a
> >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
> >> colors to indicate the on-off light indicator is ON.
> >>
> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
> >>
> >> Link to standard:
> >> W3C Multi touch spec proposal:
> >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
> >> W3C Light indicator spec proposal:
> >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
> >>
> >> Platform coverage: Windows, Mac OS, Linux
> >>
> >> Estimated or target release: Firefox 68
> >>
> >> Preference behind which this will be implemented:
> >> "dom.gamepad.extensions.multitouch" and
> >> "dom.gamepad.extensions.lightindicator"
> >>
> >> Do other browser engines implement this? Nope
> >>
> >> web-platform-tests: none exist (and I don't plan to write WPTs but we do
> >> have gamepad mochitest, I will add new tests to cover these two new
> APIs.)
> >>
> >> Is this feature restricted to secure contexts? Nope
> >>
> >> How stable is the spec? This is a proposal from a vendor, I suppose it
> >> would be some minor adjustments coming when other developers start to
> >> implement it. I would suggest to make it pref'd off by default until
> this
> >> proposal be merged to w3c's branch.
> >>
> >>
> >> --
> >> Daosheng Mu
> >> Software Engineer | Mozilla
> >> d...@mozilla.com
> >> ___
> >> 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: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Daosheng Mu]

Hi Daniel,

We didn't have a chance to discuss privacy issues in Gamepad Extension or
Gamepad API. We were trying to get responses for the Privacy review [1] but
without any updates yet.

Cheers,

[1] https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html

--
Daosheng Mu
Software Engineer | Mozilla
d...@mozilla.com


On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz  wrote:

> Neither of the words "security" or "privacy" appear in this spec (most w3
> web specs have at least a token attempt at a "Privacy and Security
> Considerations" section). At a surface glance this appears to add
> additional fingerprinting exposure. Have you talked to the privacy team
> about ways to minimize this?
>
> -Dan Veditz
>
> On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:
>
>> Summary:
>> In order to support controllers which have multi touch and light bar
>> features like Sony DualShock 4. The `*multi touch*` and `*light
>> indicator*`
>> APIs for gamepad extensions are the things we must have. In
>> `*GamepadTouch*`
>> API, it would make us know touch surface's dimension and its unique id. We
>> also will have a way to know where is the place we are touching according
>> to its position and the unique id. Regarding to `*GamepadLightIndicator*`,
>> it could tell users the color of controller's light bar. The color is a
>> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
>> colors to indicate the on-off light indicator is ON.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
>>
>> Link to standard:
>> W3C Multi touch spec proposal:
>> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
>> W3C Light indicator spec proposal:
>> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
>>
>> Platform coverage: Windows, Mac OS, Linux
>>
>> Estimated or target release: Firefox 68
>>
>> Preference behind which this will be implemented:
>> "dom.gamepad.extensions.multitouch" and
>> "dom.gamepad.extensions.lightindicator"
>>
>> Do other browser engines implement this? Nope
>>
>> web-platform-tests: none exist (and I don't plan to write WPTs but we do
>> have gamepad mochitest, I will add new tests to cover these two new APIs.)
>>
>> Is this feature restricted to secure contexts? Nope
>>
>> How stable is the spec? This is a proposal from a vendor, I suppose it
>> would be some minor adjustments coming when other developers start to
>> implement it. I would suggest to make it pref'd off by default until this
>> proposal be merged to w3c's branch.
>>
>>
>> --
>> Daosheng Mu
>> Software Engineer | Mozilla
>> d...@mozilla.com
>> ___
>> 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 implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Daniel Veditz]

Neither of the words "security" or "privacy" appear in this spec (most w3
web specs have at least a token attempt at a "Privacy and Security
Considerations" section). At a surface glance this appears to add
additional fingerprinting exposure. Have you talked to the privacy team
about ways to minimize this?

-Dan Veditz

On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:

> Summary:
> In order to support controllers which have multi touch and light bar
> features like Sony DualShock 4. The `*multi touch*` and `*light indicator*`
> APIs for gamepad extensions are the things we must have. In
> `*GamepadTouch*`
> API, it would make us know touch surface's dimension and its unique id. We
> also will have a way to know where is the place we are touching according
> to its position and the unique id. Regarding to `*GamepadLightIndicator*`,
> it could tell users the color of controller's light bar. The color is a
> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
> colors to indicate the on-off light indicator is ON.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
>
> Link to standard:
> W3C Multi touch spec proposal:
> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
> W3C Light indicator spec proposal:
> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
>
> Platform coverage: Windows, Mac OS, Linux
>
> Estimated or target release: Firefox 68
>
> Preference behind which this will be implemented:
> "dom.gamepad.extensions.multitouch" and
> "dom.gamepad.extensions.lightindicator"
>
> Do other browser engines implement this? Nope
>
> web-platform-tests: none exist (and I don't plan to write WPTs but we do
> have gamepad mochitest, I will add new tests to cover these two new APIs.)
>
> Is this feature restricted to secure contexts? Nope
>
> How stable is the spec? This is a proposal from a vendor, I suppose it
> would be some minor adjustments coming when other developers start to
> implement it. I would suggest to make it pref'd off by default until this
> proposal be merged to w3c's branch.
>
>
> --
> Daosheng Mu
> Software Engineer | Mozilla
> d...@mozilla.com
> ___
> 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

Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Daosheng Mu]

Summary:
In order to support controllers which have multi touch and light bar
features like Sony DualShock 4. The `*multi touch*` and `*light indicator*`
APIs for gamepad extensions are the things we must have. In `*GamepadTouch*`
API, it would make us know touch surface's dimension and its unique id. We
also will have a way to know where is the place we are touching according
to its position and the unique id. Regarding to `*GamepadLightIndicator*`,
it could tell users the color of controller's light bar. The color is a
8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
colors to indicate the on-off light indicator is ON.

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

Link to standard:
W3C Multi touch spec proposal:
https://github.com/knyg/gamepad/blob/multitouch/extensions.html
W3C Light indicator spec proposal:
https://github.com/knyg/gamepad/blob/lightindicator/extensions.html

Platform coverage: Windows, Mac OS, Linux

Estimated or target release: Firefox 68

Preference behind which this will be implemented:
"dom.gamepad.extensions.multitouch" and
"dom.gamepad.extensions.lightindicator"

Do other browser engines implement this? Nope

web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these two new APIs.)

Is this feature restricted to secure contexts? Nope

How stable is the spec? This is a proposal from a vendor, I suppose it
would be some minor adjustments coming when other developers start to
implement it. I would suggest to make it pref'd off by default until this
proposal be merged to w3c's branch.


--
Daosheng Mu
Software Engineer | Mozilla
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Mats Palmgren]

Summary:
The 'prefers-color-scheme' media feature is way for pages to detect
if the user prefers a light or dark color theme.  The values are
'light', 'dark', and 'no-preference'.  If the "resist fingerprinting"
feature is active we always match 'light'.  If the media type is
'print' we always match 'light'.  Otherwise, we try to determine
a value from the user's current "desktop theme".  This should work
well on recent versions of OSX and Windows.  On Linux, we don't
know how to determine a value from the system so we match
'no-preference' there - help wanted:
https://bugzilla.mozilla.org/show_bug.cgi?id=1525775

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

Link to standard:
https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

Platform coverage: All platforms

Estimated or target release: Firefox 67

Preference behind which this will be implemented:
The feature is always enabled, but there is an existing hidden
preference to set a value (integer), ui.systemUsesDarkTheme:
0 = light
1 = dark
2 = no-preference

Is this feature enabled by default in sandboxed iframes?
Yes, but if widget look-and-feel features are disabled in
sandboxed iframes then we'll match 'no-preference'.

DevTools bug: none

Do other browser engines implement this?
Safari has implemented this feature and it's available in their
Nightly build, but it's not yet shipped AFAICT.
https://paulmillr.com/posts/using-dark-mode-in-css/ is a post about
implementation of this feature in Safari;
https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/ 
documents its addition.


It appears Chrome is actively working on it:
https://bugs.chromium.org/p/chromium/issues/detail?id=889087

web-platform-tests:
https://w3c-test.org/css/mediaqueries/prefers-color-scheme.html

Is this feature restricted to secure contexts? No

Credit also goes to Jonathan Kingston who wrote the initial
implementation of this feature.


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

Intent to implement and ship: InputEvent.data and InputEvent.dataTransfer

[Masayuki Nakano]

We need to implement InputEvent.data and InputEvent.dataTransfer because 
they are important information for web apps especially for "beforeinput" 
event listeners. So, we need to implement these attributes before 
implementing "beforeinput" event.  The bug is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=998941

Those attributes tell what content is inserted ("input") or will be 
inserted ("beforeinput") to web apps.


The former is declared by UI Events:
https://w3c.github.io/uievents/#dom-inputevent-data

The latter is declared by Input Events:
https://rawgit.com/w3c/input-events/v1/index.html#dom-inputevent-datatransfer
https://w3c.github.io/input-events/#dom-inputevent-datatransfer

And their values are defined by Input Events:
https://rawgit.com/w3c/input-events/v1/index.html#overview
https://w3c.github.io/input-events/#overview

Those are implemented by both Chrome and Safari, but their 
implementation are not enough though (e.g., "input" event is not set 
those values properly in a lot of cases). But I'm going to add check of 
those attributes into WPT as far as possible at landing the patches and 
I'll file bugs for them.


Currently, I plan to enable them by default in all channels like 
InputEvent.inputType.  If we would get web-compat issues, e.g., they are 
used to detect "beforeinput" event support, then, I'd disable them in a 
follow up bug.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: The border-{start, end}-{start,end}-radius CSS properties

[Xidorn Quan]

On Fri, Jan 18, 2019, at 7:46 AM, Mats Palmgren wrote:
> Summary:
> The border-{start,end}-{start,end}-radius CSS properties are flow-relative
> versions of their corresponding physical property, border-top-left-radius etc
> 
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1520684
> 
> Link to standard:
> https://drafts.csswg.org/css-logical-1/#border-radius-properties

It seems the spec isn't currently clear about the mapping of the two logical 
words. Based on w3c/csswg-drafts#3034[1] and the link inside, it seems the 
first means block axis and the second means inline axis. Spec should probably 
make it clear. It might be better if we can have it clarified before we ship it.

Personally I never feel very happy about the naming, but I cannot come up with 
a better idea, so...

[1] https://github.com/w3c/csswg-drafts/issues/3034


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

Re: Intent to Implement and Ship: The border-{start, end}-{start, end}-radius CSS properties

[obrufau]

> Do other browser engines implement this?
> I don't know, there was no WPT for these.

I didn't implement them in Blink because they were added into the spec after I 
sent the intent to implement. So I should send a new one for them.

Also, the mapping is not clear in the spec 
(https://github.com/w3c/csswg-drafts/issues/3034), though there is a csswg 
resolution, so it should be safe.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: The border-{start,end}-{start,end}-radius CSS properties

[Mats Palmgren]

Summary:
The border-{start,end}-{start,end}-radius CSS properties are flow-relative
versions of their corresponding physical property, border-top-left-radius etc

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

Link to standard:
https://drafts.csswg.org/css-logical-1/#border-radius-properties

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in these patches

Do other browser engines implement this?
I don't know, there was no WPT for these.

web-platform-tests:
I added one: css/css-logical/logical-box-border-radius.html

Is this feature restricted to secure contexts? No


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

Intent to Implement and Ship: CSS border-{block,inline}-{color,style,width} and border-{block,inline} shorthands

[Mats Palmgren]

Summary:
The border-{block,inline}-{color,style,width} CSS properties are shorthand 
for their respective -start/-end properties.
The border-{block,inline} are shorthand for their respective -start/-end 
shorthands, though you can only specify one value (which is used on both 
the -start/-end sides).


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1520236
https://bugzilla.mozilla.org/show_bug.cgi?id=1520396

Link to standard:
https://drafts.csswg.org/css-logical/#propdef-border-inline-color (etc)
https://drafts.csswg.org/css-logical/#propdef-border-inline

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in these patches

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-border-shorthands.html

web-platform-tests:
http://w3c-test.org/css/css-logical/logical-box-border-shorthands.html

Is this feature restricted to secure contexts? No


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

Intent to Implement and Ship: CSS inset/inset-block/inset-inline shorthands

[Mats Palmgren]

Summary:
The inset-block CSS property is a shorthand for the inset-block-start/end 
properties (ditto -inline).
The 'inset' CSS property is a shorthand for the top, right, bottom, and 
left properties.


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

Link to standard:
https://drafts.csswg.org/css-logical/#propdef-inset-inline
https://drafts.csswg.org/css-logical/#propdef-inset

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in the patch

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-inset.html

web-platform-tests:
http://w3c-test.org/css/css-logical/logical-box-inset.html

Is this feature restricted to secure contexts? No


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

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

[Boris Zbarsky]

On 1/14/19 9:09 PM, fantasai wrote:

I have no idea why I did that. Fixed.


Thank you!


Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
   https://www.w3.org/TR/css-logical-1/#intro


Perfect, thank you for the pointer.

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

Re: Intent to implement and ship: forced case-sensitive attribute selector matching

[fantasai]

On 12/11/18 6:34 AM, Boris Zbarsky wrote:
>
> Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny 
change and there's not much controversy about which letter to use for the flag, I would think.


As the editor of the spec, I second this assessment. There are parts
of Selectors 4 that are a little shaky, but this is so closely analogous
to an existing feature that it doesn't seem like one of them.

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

Re: Intent to implement and ship: Overflow media queries

[fantasai]

On 12/23/18 2:59 AM, Emilio Cobos Álvarez wrote:
Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using 
a media expression instead of the print media type allows for more flexibility, see the bug 
description.


Implementation wise, we already expose the same kind of information via @media print right now, 
given we don't have any kind of built-in EBook mode or something like that.


A volunteer sent patches for this, and I see no reason not to take them, unless somebody objects 
here. Thanks a lot quasicomputational@! :)


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

Link to standard:
   https://drafts.csswg.org/mediaqueries-4/#mf-overflow-inline
   https://drafts.csswg.org/mediaqueries-4/#mf-overflow-block

Platform coverage: all

Estimated or target release: 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes: Yes

DevTools bug: N/A, existing devtools features should cover this.

Do other browser engines implement this? No, we'd be the first ones implementing this part of the 
spec, but I think it's uncontroversial. The spec author was the one that filed the bug requesting 
implementation, so spec-wise the feature should be stable as well.


General CSSWG policy is that any spec in CR has the consensus of the CSSWG
to be implemented and shipped.
  “Once a specification reaches the Candidate Recommendation stage,
  implementers should release an unprefixed implementation of any
  CR-level feature they can demonstrate to be correctly implemented
  according to spec, and should avoid exposing a prefixed variant
  of that feature.” -- https://www.w3.org/TR/CSS/#testing

Media Queries Level 4 is in CR, so anything there is good to go.

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

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

[fantasai]

On 1/14/19 10:23 AM, Boris Zbarsky wrote:

On 1/14/19 12:58 PM, Mats Palmgren wrote:

Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline


Two quick questions on the spec:

1) 'padding-block-start' is defined as:

   Value:  <‘padding-top’>

while 'padding-block' is defined as:

   Value:  <‘padding-left’>{1,2}

It probably doesn't matter too much because padding-top and padding-left have the same value space, 
but it's a bit weird and makes one go sleuthing to ensure that they do.  Do you know whether this is 
purposeful or just a typo?


I have no idea why I did that. Fixed.


2) We are just implementing the padding shorthands for now, not the margin ones?

Do other browser engines implement this? No, 
https://wpt.fyi/results/css/css-logical/logical-box-padding.html


Do they plan to?  That is, is the spec reflecting some sort of general 
consensus?


Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
  https://www.w3.org/TR/css-logical-1/#intro

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

Intent to Implement and Ship: CSS margin-block and margin-inline shorthands

[Mats Palmgren]

Summary: The margin-block CSS property is a shorthand for the 
margin-block-start/end properties (ditto -inline)


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

Link to standard: https://drafts.csswg.org/css-logical/#propdef-margin-inline

Platform coverage: All platforms

Estimated or target release: Firefox 66

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A, devtools support is included in the patch

Do other browser engines implement this?
https://wpt.fyi/results/css/css-logical/logical-box-margin.html
Blink appears to have implemented them behind a flag:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/css_properties.json5?rcl=b166577f0820ba3f3aefe3c0fbe330c8e2f86dc9&l=4820-4831

web-platform-tests: 
http://w3c-test.org/css/css-logical/logical-box-margin.html


Is this feature restricted to secure contexts? No


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

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

[Mats Palmgren]

On 1/14/19 7:23 PM, Boris Zbarsky wrote:

Do you know whether this is purposeful or just a typo?


Dunno.  It seems like a typo to me.

2) We are just implementing the padding shorthands for now, not the margin 
ones?


Yes, but I should probably just add margin-block/inline while I'm at it...
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1519944


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