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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Emilio Cobos Álvarez]

On 1/14/19 7:23 PM, Boris Zbarsky wrote:
> On 1/14/19 12:58 PM, Mats Palmgren wrote:
>> 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?

They're on Blink under an experimental flag:


https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/css_properties.json5?l=4872&rcl=b166577f0820ba3f3aefe3c0fbe330c8e2f86dc9

Indeed the tests were added by Oriol while implementing them IIRC.

So I assume the answer is "yes, they plan to eventually ship it".

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


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?


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

[Emilio Cobos Álvarez]

On 1/2/19 5:18 PM, James Graham wrote:

On 23/12/2018 10:59, Emilio Cobos Álvarez wrote:

web-platform-tests: Minimal parsing tests are being added to:

   https://wpt.fyi/results/css/mediaqueries/test_media_queries.html

Unfortunately WPT has no way to test print preview or pagination right 
now so the rest of reftests are Gecko-only.


Mind filing an issue on the wpt repo about the inability to test these 
features? It seems like something we could at least investigate, 
although I don't think there's currently any cross-browser API 
(including via e.g. WebDriver) for getting paginated layout.


I think this is covered already by:

  https://github.com/web-platform-tests/wpt/issues/7760

We have reftest-paged for this and also a programatic (yet not ideal) 
way to test print preview:



https://searchfox.org/mozilla-central/rev/0ee0b63732d35d16ba22d5a1120622e2e8d58c29/layout/base/tests/chrome/printpreview_helper.xul#26

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

[James Graham]

On 23/12/2018 10:59, Emilio Cobos Álvarez wrote:

web-platform-tests: Minimal parsing tests are being added to:

   https://wpt.fyi/results/css/mediaqueries/test_media_queries.html

Unfortunately WPT has no way to test print preview or pagination right 
now so the rest of reftests are Gecko-only.


Mind filing an issue on the wpt repo about the inability to test these 
features? It seems like something we could at least investigate, 
although I don't think there's currently any cross-browser API 
(including via e.g. WebDriver) for getting paginated layout.

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

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

[Emilio Cobos Álvarez]

On 12/21/18 7:23 PM, Eric Shepherd (Sheppy) wrote:

I just now saw this; as both a developer and as a writer on the MDN docs
team, I can tell you this will really be fantastic to have, and I can’t
wait! Not having control over breaks makes a lot of layout fail, especially
when trying to use multiple columns or grids to do layout.


FWIW Firefox allows you to control breaks as well (even before my 
change) via the page-break-* properties (which we honored too for 
non-paginated contexts).


But yeah, this should make the whole setup much clearer, and allow 
people to write interoperable CSS too :)


 -- Emilio


On December 7, 2018 at 9:12:39 AM, Emilio Cobos Álvarez (emi...@crisal.io)
wrote:

Summary: Implement these properties to control breaks in the page, make
page-break-{before,after} legacy shorthands of those.


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


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

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

[Eric Shepherd (Sheppy)]

I just now saw this; as both a developer and as a writer on the MDN docs
team, I can tell you this will really be fantastic to have, and I can’t
wait! Not having control over breaks makes a lot of layout fail, especially
when trying to use multiple columns or grids to do layout.

On December 7, 2018 at 9:12:39 AM, Emilio Cobos Álvarez (emi...@crisal.io)
wrote:

Summary: Implement these properties to control breaks in the page, make
page-break-{before,after} legacy shorthands of those.


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: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Martin Thomson]

On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen  wrote:
> I changed the limit to 4 MB.

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

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Henri Sivonen]

On Tue, Dec 11, 2018 at 10:08 AM Henri Sivonen  wrote:
> How about I change it to 5 MB on the assumption that that's still very
> large relative to pre-UTF-8-era HTML and text file sizes?

I changed the limit to 4 MB.

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Henri Sivonen]

On Tue, Dec 11, 2018 at 2:24 AM Martin Thomson  wrote:
> This seems reasonable, but 50M is a pretty large number.  Given the
> odds of UTF-8 detection failing, I would have thought that this could
> be much lower.

Consider the case of a document of ASCII text with a copyright sign in
the footer. I'd rather not make anyone puzzle over why the behavior of
the footer depends on how much text comes before the footer.

50 MB is intentionally extremely large relative to "normal" HTML and
text files so that the limit is reached approximately "never" unless
you open *huge* log files.

The HTML spec is about 11 MB these days, so that's existence proof
that a non-log-file HTML document can exceed 10 MB. Of course, the
limit doesn't need to be larger than present-day UTF-8 files but
larger than "normal"-sized *legacy* non-UTF-8 files.

It is quite possible that 50 MB is *too* large considering 32-bit
systems and what *other* allocations are proportional to the buffer
size, and I'm open to changing the limit to something smaller than 50
MB as long as it's still larger than "normal" non-UTF-8 HTML and text
files.

How about I change it to 5 MB on the assumption that that's still very
large relative to pre-UTF-8-era HTML and text file sizes?

> What is the number in Chrome?

It depends. It's unclear to me what exactly it depends on. Based on
https://github.com/whatwg/encoding/issues/68#issuecomment-272993181 ,
I expect it to depend on some combination of file system, OS kernel
and Chromium IO library internals.

On Ubuntu 18.04 with ext4 on an SSD, the number is 64 KB. On Windows
10 1803 with NTFS on an SSD, it's something smaller.

I think making the limit depend on the internals of file IO buffering
instead of a constant in the HTML parser is a really bad idea. Also 64
KB or something less than 64 KB seem way too small for the purpose of
making it so that the user approximately never needs to puzzle over
why things are different based on the length of the ASCII prefix of a
file with non-ASCII later in the file.

> I assume that other local sources like chrome: are expected to be
> annotated properly.

>From source inspection, it seems that chrome: URLs already get
hard-coded to UTF-8 on the channel level:
https://searchfox.org/mozilla-central/source/chrome/nsChromeProtocolHandler.cpp#187

As part of developing the patch, I saw only resource: URLs showing up
as file: URLs to the HTML parser, so only resource: URLs got a special
check that fast-tracks them to UTF-8 instead of buffering for
detection like normal file: URLs.

> On Mon, Dec 10, 2018 at 11:28 PM Henri Sivonen  wrote:
> >
> > (Note: This isn't really a Web-exposed feature, but this is a Web
> > developer-exposed feature.)
> >
> > # Summary
> >
> > Autodetect UTF-8 when loading HTML or plain text from file: URLs (only!).
> >
> > Some Web developers like to develop locally from file: URLs (as
> > opposed to local HTTP server) and then deploy using a Web server that
> > declares charset=UTF-8. To get the same convenience as when developing
> > with Chrome, they want the files loaded from file: URLs be treated as
> > UTF-8 even though the HTTP header isn't there.
> >
> > Non-developer users save files from the Web verbatim without the HTTP
> > headers and open the files from file: URLs. These days, those files
> > are most often in UTF-8 and lack the BOM, and sometimes they lack
> > , and plain text files can't even use  > charset=utf-8>. These users, too, would like a Chrome-like convenience
> > when opening these files from file: URLs in Firefox.
> >
> > # Details
> >
> > If a HTML or plain text file loaded from a file: URL does not contain
> > a UTF-8 error in the first 50 MB, assume it is UTF-8. (It is extremely
> > improbable for text intended to be in a non-UTF-8 encoding to look
> > like valid UTF-8 on the byte level.) Otherwise, behave like at
> > present: assume the fallback legacy encoding, whose default depends on
> > the Firefox UI locale.
> >
> > The 50 MB limit exists to avoid buffering everything when loading a
> > log file whose size is on the order of a gigabyte. 50 MB is an
> > arbitrary size that is significantly larger than "normal" HTML or text
> > files, so that "normal"-sized files are examined with 100% confidence
> > (i.e. the whole file is examined) but can be assumed to fit in RAM
> > even on computers that only have a couple of gigabytes of RAM.
> >
> > The limit, despite being arbitrary, is checked exactly to avoid
> > visible behavior changes depending on how Necko chooses buffer
> > boundaries.
> >
> > The limit is a number of bytes instead of a timeout in order to avoid
> > reintroducing timing dependencies (carefully removed in Firefox 4) to
> > HTML parsing--even for file: URLs.
> >
> > Unless a  declaring the encoding (or a BOM) is found within the
> > first 1024 bytes, up to 50 MB of input is buffered before starting
> > tokenizing. That is, the feature assumes that local files don't need
> > incremental HTML parsing, that lo

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Martin Thomson]

This seems reasonable, but 50M is a pretty large number.  Given the
odds of UTF-8 detection failing, I would have thought that this could
be much lower.  What is the number in Chrome?

I assume that other local sources like chrome: are expected to be
annotated properly.
On Mon, Dec 10, 2018 at 11:28 PM Henri Sivonen  wrote:
>
> (Note: This isn't really a Web-exposed feature, but this is a Web
> developer-exposed feature.)
>
> # Summary
>
> Autodetect UTF-8 when loading HTML or plain text from file: URLs (only!).
>
> Some Web developers like to develop locally from file: URLs (as
> opposed to local HTTP server) and then deploy using a Web server that
> declares charset=UTF-8. To get the same convenience as when developing
> with Chrome, they want the files loaded from file: URLs be treated as
> UTF-8 even though the HTTP header isn't there.
>
> Non-developer users save files from the Web verbatim without the HTTP
> headers and open the files from file: URLs. These days, those files
> are most often in UTF-8 and lack the BOM, and sometimes they lack
> , and plain text files can't even use  charset=utf-8>. These users, too, would like a Chrome-like convenience
> when opening these files from file: URLs in Firefox.
>
> # Details
>
> If a HTML or plain text file loaded from a file: URL does not contain
> a UTF-8 error in the first 50 MB, assume it is UTF-8. (It is extremely
> improbable for text intended to be in a non-UTF-8 encoding to look
> like valid UTF-8 on the byte level.) Otherwise, behave like at
> present: assume the fallback legacy encoding, whose default depends on
> the Firefox UI locale.
>
> The 50 MB limit exists to avoid buffering everything when loading a
> log file whose size is on the order of a gigabyte. 50 MB is an
> arbitrary size that is significantly larger than "normal" HTML or text
> files, so that "normal"-sized files are examined with 100% confidence
> (i.e. the whole file is examined) but can be assumed to fit in RAM
> even on computers that only have a couple of gigabytes of RAM.
>
> The limit, despite being arbitrary, is checked exactly to avoid
> visible behavior changes depending on how Necko chooses buffer
> boundaries.
>
> The limit is a number of bytes instead of a timeout in order to avoid
> reintroducing timing dependencies (carefully removed in Firefox 4) to
> HTML parsing--even for file: URLs.
>
> Unless a  declaring the encoding (or a BOM) is found within the
> first 1024 bytes, up to 50 MB of input is buffered before starting
> tokenizing. That is, the feature assumes that local files don't need
> incremental HTML parsing, that local file streams don't stall as part
> of their intended operation, and that the content of local files is
> available in its entirety (approximately) immediately.
>
> There are counter examples like Unix FIFOs (can be infinite and can
> stall for an arbitrary amount of time) or file server shares mounted
> as if they were local disks (data available somewhat less
> immediately). It is assumed that it's OK to require people who have
> built workflows around Unix FIFOs to use  and that it's
> OK to potentially start rendering a little later when file: URLs
> actually cause network access.
>
> UTF-8 autodetection is given lower precedence that all other signals
> that are presently considered for file: URLs. In particular, if a
> file:-URL HTML document frames another file: URL HTML document (i.e.
> they count as same-origin), the child inherits the encoding from the
> parent instead of UTF-8 autodetection getting applied in the child
> frame.
>
> # Why file: URLs only
>
> The reason why the feature does not apply to http: or https: resources
> is that in those cases, it really isn't OK to assume that all bytes
> arrive so quickly as to not benefit from incremental rendering and it
> isn't OK to assume that the stream doesn't intentionally stall.
>
> Applying detection to http: or https: resources would mean at least on
> of the following compromises:
>
> * Making the detection unreliable by making it depend on non-ASCII
> appearing in the first 1024 bytes (the number of bytes currently
> buffered for scanning ). If the  was always near the
> start of the file and the natural language used a non-Latin script to
> make non-ASCII in the  a certainty, this solution would be
> reliable. However, this solution would be particularly bad for
> Latin-script languages with infrequent non-ASCII, such as Finnish or
> German, which can legitimately have all-ASCII titles despite the
> language as a whole including non-ASCII. That is, if a developer
> tested a site with a title that has some non-ASCII, things would
> appear to work, but then the site would break when an all-ASCII title
> occurs.
>
> * Making results depend on timing. (Having a detection timeout would
> make the results depend on network performance relative to wall-clock
> time.)
>
> * Making the detection unreliable by examining only the first buffer
> passed by the networking subsystem to th

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

[Ehsan Akhgari]

On Thu, Nov 29, 2018 at 6:27 AM Emilio Cobos Álvarez 
wrote:

> Sorry for the lag replying to this.
>
> On 11/13/18 4:35 PM, James Graham wrote:
> > On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:
> >
> >> 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.
> >
> > Can we upstream some of these tests to wpt? I don't know if there
> > are/were technical barriers that would prevent us doing that, but if
> > user gestures are required, the new testdriver APIs might fill the gap,
> > and if there is some other piece of missing functionality I would be
> > interested to know what that is.
> Part of the difficulty is that we want these tests to show the caret,
> which is something normal reftests don't. Right now all these reftests
> are here:
>
>
>
> https://searchfox.org/mozilla-central/source/layout/base/tests/test_reftests_with_caret.html
>
> I'm not quite sure why they couldn't be normal reftests with the
> ui.caretBlinkTime pref set to -1. Maybe David, Ehsan or Mats know.
>

The reason for that is that these tests typically require input of some
sort (mouse, keyboard, for example), and as far as I know at least the
reftest framework didn't support synthesizing events, at least at the
time.  So we ended up creating this small mini-reftest framework in
mochitest so that we can use the EventUtils facilities.  (Also as far as I
remember setting prefs per reftest wasn't possible at the time either.)

Cheers,
-- 
Ehsan
___
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]

Sorry for the lag replying to this.

On 11/13/18 4:35 PM, James Graham wrote:

On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:

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.


Can we upstream some of these tests to wpt? I don't know if there 
are/were technical barriers that would prevent us doing that, but if 
user gestures are required, the new testdriver APIs might fill the gap, 
and if there is some other piece of missing functionality I would be 
interested to know what that is.
Part of the difficulty is that we want these tests to show the caret, 
which is something normal reftests don't. Right now all these reftests 
are here:



https://searchfox.org/mozilla-central/source/layout/base/tests/test_reftests_with_caret.html

I'm not quite sure why they couldn't be normal reftests with the 
ui.caretBlinkTime pref set to -1. Maybe David, Ehsan or Mats know.


But even with that, a lot of those require faking user input (like 
arrows and such), whose effect depends on platform conventions. We're 
using EventUtils for that right now, and skipping some tests in some 
platforms.


I know the events thing is technically possible in WPT, is there any 
example I could cargo-cult from?


I think in theory writing new caret tests with testharness.js and the 
event stuff would be useful, and it may be possible to submit some of 
the ones that don't depend on platform conventions.


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

Re: Intent to implement and ship: overflow-wrap: anywhere

[idontlikespying]

Finally something what solving problem of missing "word-break: break-word" 
(https://jsfiddle.net/ofgd83um/80/)
When it will be shipped to stable?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: overflow-wrap: anywhere

[idontlikespying]

Finally something can slove problem of missing "word-break: break-word" 
https://jsfiddle.net/ofgd83um/80/
___
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.

[James Graham]

On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:

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.


Can we upstream some of these tests to wpt? I don't know if there 
are/were technical barriers that would prevent us doing that, but if 
user gestures are required, the new testdriver APIs might fill the gap, 
and if there is some other piece of missing functionality I would be 
interested to know what that is.

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

On 11/12/18 2:36 AM, flor...@rivoal.net wrote:

On Monday, November 12, 2018 at 2:57:14 AM UTC+9, 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


I support doing this. This has existed forever, and is used quite a bit, so 
keeping that prefixed isn't helping anyone.

I would like to note however that the basic way the property works (inherited 
vs not, initial value of auto, different between 'auto' and 'text') is 
different in the spec and in your implementation. The difference is 
intentional, and necessary to support the `contain` value and to have a model 
that explains what happens on editable elements.

As long as you don't support the contain value, the difference in behavior 
should be minimal and barely noticeable in most cases, so this may not be a 
blocker, but if you're working on this property anyway, it seems to me that 
this would be a good time to switch to the spec's behavior while you're at it.


Hmm, you're totally right, that's a very good point and I think we 
should not unprefix it without fixing that.


I'll land the patches removing the obsolete values, and file a bug to 
make that change before unprefixing.


Thanks Florian!

 -- Emilio


—Florian
___
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: Unprefix -moz-user-select, unship mozilla-specific values.

[florian]

On Monday, November 12, 2018 at 2:57:14 AM UTC+9, 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

I support doing this. This has existed forever, and is used quite a bit, so 
keeping that prefixed isn't helping anyone.

I would like to note however that the basic way the property works (inherited 
vs not, initial value of auto, different between 'auto' and 'text') is 
different in the spec and in your implementation. The difference is 
intentional, and necessary to support the `contain` value and to have a model 
that explains what happens on editable elements.

As long as you don't support the contain value, the difference in behavior 
should be minimal and barely noticeable in most cases, so this may not be a 
blocker, but if you're working on this property anyway, it seems to me that 
this would be a good time to switch to the spec's behavior while you're at it.

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

Re: Intent to implement and ship: overflow-wrap: anywhere

[florian]

I think it's great, please go ahead. I just gave a talk about the various 
properties/values related to line breaking, and had multiple people tell me 
they were so sad that overflow-wrap:anywhere wasn't implemented yet. So I 
totally support implementing/shipping this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: img decode API support

[Andrew Osmond]

Ah, my bad. Yes, if scripts are available, this is available. It doesn't
allow you to do anything new, aside from forcing a decode to start (which
you could do by adding the image to the DOM tree, assuming it is visible)
and knowing when the decode has completed. The usual content restrictions
will continue to apply.

On Wed, Nov 7, 2018 at 11:23 AM, Boris Zbarsky  wrote:

> On 11/7/18 11:15 AM, Andrew Osmond wrote:
>
>> This is simply a
>> new method for JS on image elements, so it should be unavailable.
>>
>
> Script can run in sandboxed iframes, depending on sandboxing flags.
>
> It sounds like this feature is enabled by default in sandboxed iframes, as
> long as script is enabled, right?
>
> -Boris
> ___
> 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: img decode API support

[Boris Zbarsky]

On 11/7/18 11:15 AM, Andrew Osmond wrote:

This is simply a
new method for JS on image elements, so it should be unavailable.


Script can run in sandboxed iframes, depending on sandboxing flags.

It sounds like this feature is enabled by default in sandboxed iframes, 
as long as script is enabled, right?


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

Re: Intent to implement and ship: CSS environment variables.

[Ehsan Akhgari]

On Fri, Nov 2, 2018 at 5:26 PM Emilio Cobos Álvarez 
wrote:

> This is mostly to prevent compat headache in mobile, hopefully prevent
> other vendors from shipping new un-spec'd env variables, and encourage
> people to use the fallback value if new environment variables are added
> in the future.
>
> Thoughts?
>

I think the rationale for shipping this, given our past experience with how
developers have used WebKit/Chrome specific features on mobile is
reasonable.

Thanks for thinking ahead of the compat issues.

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

Re: Intent to implement and ship: New cookie jar policy to block storage access from tracking resources

[Ehsan Akhgari]

Just a quick update: This new policy has now been made the new default in
Nightly in https://bugzilla.mozilla.org/show_bug.cgi?id=1492563.

On Fri, Sep 21, 2018 at 3:15 PM Steven Englehardt 
wrote:

> Technical documentation for this is now available on MDN:
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy
>
> On Wed, Sep 19, 2018 at 10:24 PM Ehsan Akhgari 
> wrote:
>
>> Hi everyone,
>>
>> This is a (belated) intent to implement, as well as an intent to ship, a
>> new cookie jar policy to block storage access to tracking resources.  This
>> work has been under development for several months now and has been
>> tracked
>> in https://bugzilla.mozilla.org/show_bug.cgi?id=cookierestrictions.
>>
>> As of Firefox 65, I intend to turn on our new cookie jar policy to block
>> storage access from tracking resources by default on all desktop platforms
>> (assuming our testing goes well).  This feature has been developed behind
>> the network.cookie.cookieBehavior preference (when set to 4). No other UA
>> is shipping this feature, although Safari 12 ships a somewhat similar
>> feature (
>> https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/).
>>
>> Bug to turn on by default:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1492549
>>
>> Please note that this feature uses the Disconnect list in order to
>> identify
>> tracking resources, so it is not going to have any effect if you have
>> Tracking Protection turned on, or if you have installed a privacy
>> extension
>> and/or an ad blocker (examples include Privacy Badger, uBlock Origin and
>> Ghostery).  If you are a Nightly tester using such a feature, it would be
>> hugely helpful to us in the next few months if you would kindly consider
>> disabling such features and just use the default configuration of Nightly,
>> as this is what we are intending to ship to all our users soon. If you
>> encounter any web page breakage as a result of testing this feature,
>> please
>> consider filing a bug and making it block
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1480137.
>>
>> Since this isn’t a typical web feature, the standard “intent to implement”
>> template isn’t really helpful for it, but here is some of the information
>> surfaced from that template that apply to this feature:
>>
>> Platform coverage: the Gecko part is cross-platform, but the UI for the
>> feature has been developed on desktop for now, so we’re planning to enable
>> it on desktop at the moment.
>>
>> Estimated or target release: Firefox 65.  Please note that this feature is
>> currently undergoing a Shield Study on Beta 63, and the estimated target
>> release is assuming the successful outcome of that study and the continued
>> ongoing testing of the feature.
>>
>> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1462372
>>
>> Is this feature restricted to secure contexts? No, it doesn’t distinguish
>> secure vs. non-secure contexts.  This isn’t a new web-facing API, rather
>> it
>> is intended to be a new privacy protection for our users. As such, we
>> intend to impose the new restrictions for tracking resources on both
>> secure
>> and non-secure contexts.  It should be noted that some non-secure tracking
>> vectors, e.g. HTTP cookies, can also be used for pervasive tracking by
>> passively monitoring the user’s connection, and while cracking down on
>> passive tracking isn’t a direct goal of this feature, it is a good
>> justification for not limiting these restrictions to secure contexts.
>>
>> Last but not least, in preparation for this intent to ship, we’ll be
>> gradually exposing more users to the feature.  The first part of this has
>> already been done in the form of the Shield Study mentioned above. As the
>> second part of this process, I intend to turn this feature on by default
>> on
>> all desktop platforms for Nightly only in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1492563.
>>
>> Thanks,
>>
>> Ehsan
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>

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

Re: Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

[Emilio Cobos Álvarez]

On 10/17/18 3:04 PM, Tom Ritter wrote:
I believe that we fiddle these for Resist Fingerprinting; can you ensure 
the new values are similarly fiddled?


Yeah, they reuse literally the same code path, so they also have the 
same fiddling for RFP.


 -- Emilio


-tom

On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez > wrote:


(Trying to be more disciplined about pinging dev-platform@ about
web-exposed changes, a few other emails will come up in a bit)

Summary:
I plan to add the screenLeft and screenTop properties to the window, as
aliases of screenX and screenY respectively, mostly for compat with
other engines.

See https://github.com/w3c/csswg-drafts/issues/1091 for all the context.

Basically all other engines support it except Gecko.

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

It's not in the spec yet, but there's a spec PR adding it waiting on
tests to be merged:

https://github.com/w3c/csswg-drafts/pull/2669

Platform coverage: All

Estimated or target release: 64

Preference behind which this will be implemented: none

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

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

I've verified that my implementation passes them of course, with the
fix
to them I've suggested in the review.

Is this feature restricted to secure contexts? No, this is a legacy
interop issue and as such I don't think there's any point in
restricting
it to secure contexts since the aliased properties are exposed
everywhere.

   -- 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: window.screenLeft and window.screenTop aliases

[Tom Ritter]

I believe that we fiddle these for Resist Fingerprinting; can you ensure
the new values are similarly fiddled?

-tom

On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez 
wrote:

> (Trying to be more disciplined about pinging dev-platform@ about
> web-exposed changes, a few other emails will come up in a bit)
>
> Summary:
> I plan to add the screenLeft and screenTop properties to the window, as
> aliases of screenX and screenY respectively, mostly for compat with
> other engines.
>
> See https://github.com/w3c/csswg-drafts/issues/1091 for all the context.
>
> Basically all other engines support it except Gecko.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498860
>
> It's not in the spec yet, but there's a spec PR adding it waiting on
> tests to be merged:
>
>https://github.com/w3c/csswg-drafts/pull/2669
>
> Platform coverage: All
>
> Estimated or target release: 64
>
> Preference behind which this will be implemented: none
>
> Is this feature enabled by default in sandboxed iframes? Yes
>
> DevTools bug: N/A
>
> web-platform-tests: https://github.com/web-platform-tests/wpt/pull/13543
>
> I've verified that my implementation passes them of course, with the fix
> to them I've suggested in the review.
>
> Is this feature restricted to secure contexts? No, this is a legacy
> interop issue and as such I don't think there's any point in restricting
> it to secure contexts since the aliased properties are exposed everywhere.
>
>   -- 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: HTMLMarqueeElement

[Brian Grinstead]

The next step for removing XBL in marquee will be to put the content inside of 
a UA Widget Shadow Root and then (ideally) drop the JS-implemented animation in 
favor of CSS animation. I expect that should be enough to fix 
https://bugzilla.mozilla.org/show_bug.cgi?id=306344.

Brian

> On Oct 14, 2018, at 5:29 PM, Karl Dubost  wrote:
> 
> 
> 
> Le 13 oct. 2018 à 02:56, Brian Grinstead  a écrit :
>> Summary: […] I intend to implement and ship HTMLMarqueeElement.
> 
> Very cool. And a support on that, from a webcompat standpoint of view, 
> because it seems a lot of Indian websites rely on it. The current 
> implementation has "performance" issues compared to other browsers where the 
> animation is a lot smoother.
> 
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1425874
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=306344
> 
> 
> -- 
> Karl Dubost, mozilla 💡 Webcompat
> http://www.la-grange.net/karl/moz
> 
> 
> 
> 
> 

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

Re: Intent to implement and ship: HTMLMarqueeElement

[Eric Shepherd (Sheppy)]

Happy to see this coming. I'm (honestly) sort of a fan of , in a
twisted sort of way. A fun reminder of the whimsy of the early days of the
web, and amusing to use in certain types of examples.

On Sun, Oct 14, 2018 at 8:30 PM Karl Dubost  wrote:

>
>
> Le 13 oct. 2018 à 02:56, Brian Grinstead  a écrit
> :
> > Summary: […] I intend to implement and ship HTMLMarqueeElement.
>
> Very cool. And a support on that, from a webcompat standpoint of view,
> because it seems a lot of Indian websites rely on it. The current
> implementation has "performance" issues compared to other browsers where
> the animation is a lot smoother.
>
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1425874
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=306344
>
>
> --
> Karl Dubost, mozilla 💡 Webcompat
> http://www.la-grange.net/karl/moz
>
>
>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLMarqueeElement

[Karl Dubost]

Le 13 oct. 2018 à 02:56, Brian Grinstead  a écrit :
> Summary: […] I intend to implement and ship HTMLMarqueeElement.

Very cool. And a support on that, from a webcompat standpoint of view, because 
it seems a lot of Indian websites rely on it. The current implementation has 
"performance" issues compared to other browsers where the animation is a lot 
smoother.

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

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


-- 
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz





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

Re: Intent to implement and ship: text-transform: full-size-kana

[florian]

On Saturday, October 13, 2018 at 9:21:35 PM UTC+9, Xidorn Quan wrote:
> Summary: A new value of text-transform to convert small Kanas to their 
> full-size counterparts to increase legibility in the expense of accuracy, 
> usually when font size is small, e.g. in ruby.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498148
> 
> Link to standard: 
> https://drafts.csswg.org/css-text-3/#valdef-text-transform-full-size-kana


Looks good to me.

Supporting this will be help authors create documents where they no longer have 
to choose between using semantically correct markup (small kana) and making 
ruby look like what they want (full-size-kana).

> web-platform-tests: A new wpt is being added in the implementing bug.

More tests are good, but I've already submitted a PR for this. I suggest 
reviewing it while you're at it.

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

> This feature is currently marked "At Risk" in the spec, but it is a small 
> feature, and causes mostly just cosmetic changes, so it is unlikely to cause 
> any webcompat issue for shipping or unshipping if needed.

Pay no attention to "at risk", this is merely about allowing us to push this 
feature from one level of the spec to the next if we try to transition level 3 
out of CR before this is implemented in all engines. This doesn't mean we're 
not confident in the design of the feature.

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

Re: Intent to implement and ship: HTMLMarqueeElement

[Boris Zbarsky]

On 10/12/18 1:56 PM, Brian Grinstead wrote:

Summary: Motion is a key component of modern web design, and  is the 
premier...


Fire.  The premier fire so we can have fire and motion [1].

Or maybe it's just a dumpster fire?  ;)

The proposed change looks great to me.

-Boris

[1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebP image support

[Jean-Yves Avenard]

On 11/10/2018 6:03 PM, Tom Ritter wrote:

Are we bringing in a new third party library for this? (Seems like yes?)

Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz?
Are we fuzzing it?

How does upstream behave? Do they cut releases or do they just have
continual development and downstreams grab random versions of it? How do we
plan to track security issues upstream? How do we plan to update it
(mechanically and how often)?

-tom



We have been discussing implementation details such that webp would be 
using the media decoder framework to demux and decode the images. As 
such, webp support would automatically gain sandbox control (going 
through the same out of process decoding codepath like we will do with AV1).


Doing it that way would also greatly help adding support for images like 
AVIF or even using videos (mp4, webm) inside an  object.


Though there seems to be an urgency in shipping it now, meaning that the 
implementation details I describe above won't likely be in the first 
release.


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

Re: Intent to implement and ship: WebP image support

[Anne van Kesteren]

On Thu, Oct 11, 2018 at 5:43 PM Andrew Osmond  wrote:
> Is this feature restricted to secure contexts?: No, it isn't. This is not a
> new API, instead it is just accepting more types of content via existing
> channels.

This isn't the rationale you're looking for. New formats would
generally be expected to be restricted. New formats already shipped by
other browsers and likely in use on insecure contexts however probably
deserve an exception.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebP image support

[Jeff Muizelaar]

Yes, that's part of it. Further, now that Edge has shipped it we can
cause there to be a majority of vendors supporting it. Having WebP
supported by all of the browsers changes the weight we put on the
different advantages and disadvantages. For example, Firefox
supporting WebP will allow now allow web authors to have lossy
compressed images with transparency (by using WebP with Chrome, Edge,
Firefox and JPEG2000 with Safari)

-Jeff

On Thu, Oct 11, 2018 at 11:48 AM, Boris Zbarsky  wrote:
> On 10/11/18 11:43 AM, Andrew Osmond wrote:
>>
>> We are facing a growing number of webcompat reports against our
>> Gecko-derived
>> Android offerings, where web developers assume Android and/or mobile
>> implies support for WebP.
>
>
> In the past, I believe we objected to adding WebP for various reasons. Do we
> feel that those reasons are now outweighed by the compat problems?
>
> -Boris
>
> ___
> 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