Re: PSA: Remote Canvas 2D is being enabled on Nightly

[Aaron Klotz]

\o/ Way to go!

On Wed, Nov 20, 2019 at 1:27 PM  wrote:

> Hi all,
>
> I have just landed the patch to enable moving accelerated Canvas 2D to the
> GPU process on Windows.
>
> This is only enabled on Nightly at the moment and is part of our work to
> move GPU access and win32k system calls out of the content process.
>
> Please file any problems you find as bugs blocking:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1548487
>
> Thanks,
> Bob
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: CSS Shadow Parts.

[Emilio Cobos Álvarez]

As of soon (whenever the patches are reviewed) I intend to turn CSS 
Shadow Parts on by default on all platforms.


It has been developed behind the layout.css.shadow-parts.enabled preference.

Blink has shipped it for a while and Safari implements it in the latest 
TP and is enabled by default on trunk, afaict.


We had an incomplete implementation (without part forwarding) for a 
while enabled, to support our front-end code, which has been using it 
quite heavily, so I'm pretty sure it's solid.


I implemented the missing bits in bug 1559076 and related.

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


Standard: https://drafts.csswg.org/css-shadow-parts/

Platform coverage: All

DevTools bug: N/A, Devtools works fine with this feature already, parts 
show up correctly in the inspector and their rules work fine.


web-platform-tests: We'll be passing all tests in 
https://wpt.fyi/results/css/css-shadow-parts


Secure contexts: Other browsers are shipping this in non-secure 
contexts, but even with that I'd be somewhat skeptic of the value of 
restricting this CSS feature to secure contexts.


Is this feature enabled by default in sandboxed iframes? Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

[Boris Chiou]

Hi Xidorn,

I just filed one for individual transform properties: Bug 1598115
. Thanks for this
reminder.

On Wed, Nov 20, 2019 at 12:27 PM Xidorn Quan  wrote:

> On Fri, Nov 15, 2019, at 10:01 AM, Boris Chiou wrote:
> > *DevTools*: We don't support DevTools for individual transforms now.
>
> I think the current policy is that if it's worth devtools support, there
> should be a bug filed?
>
> Also it seems to me this is something indeed devtools should be able to
> help more than just value inspection, e.g., devtools can probably show a
> combined transformation from all these properties as well as the old
> transform property.
>
> - Xidorn
> ___
> 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: PSA: Remote Canvas 2D is being enabled on Nightly

[Bobby Holley]

Very excited to see this happening - consolidating D3D access into the GPU
process is important on a number of fronts (security, but also memory).

Thanks Bob and everyone else involved for pushing this forward.

On Wed, Nov 20, 2019 at 12:27 PM  wrote:

> Hi all,
>
> I have just landed the patch to enable moving accelerated Canvas 2D to the
> GPU process on Windows.
>
> This is only enabled on Nightly at the moment and is part of our work to
> move GPU access and win32k system calls out of the content process.
>
> Please file any problems you find as bugs blocking:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1548487
>
> Thanks,
> Bob
> ___
> 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

PSA: Remote Canvas 2D is being enabled on Nightly

[bowen]

Hi all,

I have just landed the patch to enable moving accelerated Canvas 2D to the GPU 
process on Windows.

This is only enabled on Nightly at the moment and is part of our work to move 
GPU access and win32k system calls out of the content process.

Please file any problems you find as bugs blocking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1548487

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

Re: intent to unship: HPKP (dynamic key pinning)

[Dana Keeler]

One of the main reasons we hesitated so long to remove HPKP was in part 
because it provided an answer to the concern that static pins privilege 
some sites and not others (which in general is not conducive to a 
healthy, diverse web). Now that we're disabling HPKP, perhaps we need to 
have a discussion about the role of the static pins list and what sorts 
of domains we put on it.


For background, in addition to a number of our own services and domains, 
we have successfully pinned Google, Facebook, Twitter, Dropbox, and Tor 
services and domains. We could decide to say that only domains that are 
critical to the operation of the product may be on the static list. In 
that case, these other sites would be removed. We could go the other way 
and define a process by which any site could apply to be added. In that 
case, I would argue that candidate domains must be included in as many 
user agents as possible that support static pins, to avoid creating 
another compatibility risk unique to Firefox. That said, it has been two 
and a half years since any non-Mozilla sites have requested to be 
included, so perhaps this won't be a concern in practice.


Long story short, to answer your question: there are currently 
non-Mozilla sites on the static list, and we're not necessarily opposed 
to expanding it, but we would need to do so with care so as to avoid 
compatibility issues.


On 11/18/19 8:03 AM, Tom Ritter wrote:
Will non-mozilla websites be eligible to be added into our preload list, 
or is it restricted to our own properties?


On Sun, Nov 17, 2019, 8:17 PM Dana Keeler > wrote:


The breadth of the web public key infrastructure (PKI) is both an asset
and a risk. Websites have a wide range of certificate authorities (CAs)
to choose from to obtain certificates for their domains. As a
consequence, attackers also have a wide range of potential targets to
try to exploit to get a mis-issued certificate. The HTTP Public Key
Pinning (HPKP) [0] header was intended to allow individual sites to
restrict the web PKI to a subset as it applies to their domains, thus
decreasing their exposure to compromised CAs.
Unfortunately, HPKP has seen little adoption, largely because it has
proved to be too dangerous to use. There are a number of scenarios that
can render websites inoperable, even if they themselves don't use the
header. Chrome removed support for it in version 72 in January of this
year [1]. According to our compatibility information, Opera, Android
webview, and Samsung Internet are the only other implementations that
support the header [2]. At this point, it represents too much of a risk
to continue to enable in Firefox.
A related mechanism, DNS Certification Authority Authorization (CAA)
[3], also allows websites to restrict which CAs can issue certificates
for their domains. This has seen much larger adoption and does not
suffer from the drawbacks of HPKP.
Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable
HPKP via a preference. New HPKP headers will not be processed, and
previously-cached HPKP information will not be consulted.
The static list of key pinning information that ships with Firefox is
still enabled, and these pins will still be enforced.

[0] https://tools.ietf.org/html/rfc7469
[1] https://www.chromestatus.com/feature/5903385005916160
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
[3] https://tools.ietf.org/html/rfc6844
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
[5] Coincidentally, version 72
___
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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y2atdpjj.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Protections UI
* NEW - https://bugzil.la/1595760 - Tracking protection - delay when 
changing protection type with multiple preferences tabs open


Firefox: Site Identity
* NEW - https://bugzil.la/1595469 - [Win] Info panel not displayed on 
double clicking button + address bar


Firefox: Toolbars and Customization
* RESOLVED FIXED - https://bugzil.la/1595772 - Overflow Menu not 
correctly aligned in Customize menu when using Compact Density


Core: CSS Parsing and Computation
* NEW - https://bugzil.la/1595463 - Bing map gets broken while zooming

Core: Graphics: WebRender
* NEW - https://bugzil.la/1595735 - [Ubuntu][WebRender] Text from items 
in Customize mode is moved when dragging and dropping items


DevTools: Netmonitor
* NEW - https://bugzil.la/1596076 - Netmonitor Blocking - space can be 
edited into a blocking pattern at the end of a link
* NEW - https://bugzil.la/1596089 - Blocking a request from the context 
menu should enable the URL/pattern if it's already in the list
* NEW - https://bugzil.la/1596091 - Implement the ability to drag and 
drop requests in order to block them


Toolkit: Application Update
* NEW - https://bugzil.la/1596778 - [Windows] Firefox fails to update to 
the latest available beta version


Toolkit: Video/Audio Controls
* NEW - https://bugzil.la/1596116 - Picture in Picture not correctly 
displayed or not displayed all when clicking the PiP button before the 
video starts


Web Compatibility: Desktop
* NEW - https://bugzil.la/1595503 - Redundant scrollbar on Instagram 
pages narrower than 720px ("mobile" design)


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/quqsx8w.


Regards,
Mihai Boldan


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

Re: intent to unship: HPKP (dynamic key pinning)

[alex . gaynor]

Hi Dana,

One thing I don't see mentioned here is certificate transparency, which, while 
not a 1:1 replacement, nevertheless strongly contributes to the same goal of 
control over issuance.

Is there a plan to implement SCT verification in Firefox, similar to what 
Chrome and Apple have shipped? In either event, it sounds like the plan to 
remove HPKP is not contingent on the answer on CT, correct?

Alex

On Sunday, November 17, 2019 at 9:16:56 PM UTC-5, Dana Keeler wrote:
> The breadth of the web public key infrastructure (PKI) is both an asset 
> and a risk. Websites have a wide range of certificate authorities (CAs) 
> to choose from to obtain certificates for their domains. As a 
> consequence, attackers also have a wide range of potential targets to 
> try to exploit to get a mis-issued certificate. The HTTP Public Key 
> Pinning (HPKP) [0] header was intended to allow individual sites to 
> restrict the web PKI to a subset as it applies to their domains, thus 
> decreasing their exposure to compromised CAs.
> Unfortunately, HPKP has seen little adoption, largely because it has 
> proved to be too dangerous to use. There are a number of scenarios that 
> can render websites inoperable, even if they themselves don't use the 
> header. Chrome removed support for it in version 72 in January of this 
> year [1]. According to our compatibility information, Opera, Android 
> webview, and Samsung Internet are the only other implementations that 
> support the header [2]. At this point, it represents too much of a risk 
> to continue to enable in Firefox.
> A related mechanism, DNS Certification Authority Authorization (CAA) 
> [3], also allows websites to restrict which CAs can issue certificates 
> for their domains. This has seen much larger adoption and does not 
> suffer from the drawbacks of HPKP.
> Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable 
> HPKP via a preference. New HPKP headers will not be processed, and 
> previously-cached HPKP information will not be consulted.
> The static list of key pinning information that ships with Firefox is 
> still enabled, and these pins will still be enforced.
> 
> [0] https://tools.ietf.org/html/rfc7469
> [1] https://www.chromestatus.com/feature/5903385005916160
> [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
> [3] https://tools.ietf.org/html/rfc6844
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
> [5] Coincidentally, version 72

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

Re: Intent to Ship: motion path module level 1

[Dirk Schulze via dev-platform]

Hi Boris,

On 18. Nov 2019, at 23:31, Boris Chiou 
mailto:bch...@mozilla.com>> wrote:

Hi Dirk,

Thanks for providing the link to the issue in Webkit. I reply to the questions 
below:

> Blink doesn't support offset-anchor either it seems. Are you keeping it 
> behind a feature flag as well?
No, I am not planning to add a feature flag for it. It seems Blink has almost 
finished this feature. Eric Willigers told me Blink has a bug on 
`offset-anchor` (on an edge case, e.g. 0% 0%), so they haven't shipped it. 
However I didn't see any new spec issues on it, so I think shipping it should 
be fine. I'm ok to add an extra feature pref if you have concerns about 
shipping it.

> The spec currently is a working draft and not a candidate recommendation 
> (CR). Is that going to get considered? Or did the CSS WG agree to ship?
There are still some other spec issues, at least for ray() function, so the 
spec may not be ready for CR. However, since Blink has shipped it (partially), 
and `offset-path:none|path()`, `offset-distance`, and `offset-rotate` are 
stable, so it should be ok to ship them without asking for permission.

> For the spec it might make sense to split into 2 levels: ... If 2 
> implementations support the 3 longhand properties consistently it brings the 
> spec of level 1 to CR faster.
Agree. it's a great suggestion. Should I file a spec issue for this, or you 
would like to update the spec as 2 levels?

Yes, that would be great! Thanks.

Dirk


Regards,
Boris


On Sun, Nov 17, 2019 at 9:43 PM Dirk Schulze 
mailto:dschu...@adobe.com>> wrote:
Hi Boris,

Blink doesn't support offset-anchor either it seems. Are you keeping it behind 
a feature flag as well?

The WebKit bug is here: https://bugs.webkit.org/show_bug.cgi?id=203847
At least initially I do not plan to implement offset-anchor either.

The spec currently is a working draft and not a candidate recommendation (CR). 
Is that going to get considered? Or did the CSS WG agree to ship?

For the spec it might make sense to split into 2 levels: Level 1 could be the 3 
longhand properties offset-path (with the limitations you mentioned), 
offset-distance and offset-rotate and the shorthand offset. Level 2 would 
include the 2 remaining properties and the ray() and basic shape functions. If 
2 implementations support the 3 longhand properties consistently it brings the 
spec of level 1 to CR faster.

Greetings,
Dirk


From: dev-platform 
mailto:dev-platform-boun...@lists.mozilla.org>>
 on behalf of Boris Chiou mailto:bch...@mozilla.com>>
Sent: Thursday, November 14, 2019 11:44 PM
To: dev-platform
Subject: Intent to Ship: motion path module level 1

Hi, All

As of Firefox 72, I intend to turn the preference of motion-path,
layout.css.motion-path.enabled, on by default on all platforms. Blink has
shipped it already but Webkit doesn't support it yet. There are some
properties defined in the spec, and I would like to ship part of them, to
match the behaviors in Blink:

1. offset-path: none | path()

2. offset-distance

3. offset-rotate

4. offset-anchor

Note: We have implemented ray() for offset-path
, but there are
still some critical spec issues not resolved, so I will add a new
preference to disable it on beta and release channels.


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

*Spec*: https://www.w3.org/TR/motion-1/ (or
https://drafts.fxtf.org/motion-1/)

*DevTools*: We don't support DevTools for this motion-path now.

*WPT*:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/motion

Thanks
___
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 unship: HPKP (dynamic key pinning)

[Tom Ritter]

Will non-mozilla websites be eligible to be added into our preload list, or
is it restricted to our own properties?

On Sun, Nov 17, 2019, 8:17 PM Dana Keeler  wrote:

> The breadth of the web public key infrastructure (PKI) is both an asset
> and a risk. Websites have a wide range of certificate authorities (CAs)
> to choose from to obtain certificates for their domains. As a
> consequence, attackers also have a wide range of potential targets to
> try to exploit to get a mis-issued certificate. The HTTP Public Key
> Pinning (HPKP) [0] header was intended to allow individual sites to
> restrict the web PKI to a subset as it applies to their domains, thus
> decreasing their exposure to compromised CAs.
> Unfortunately, HPKP has seen little adoption, largely because it has
> proved to be too dangerous to use. There are a number of scenarios that
> can render websites inoperable, even if they themselves don't use the
> header. Chrome removed support for it in version 72 in January of this
> year [1]. According to our compatibility information, Opera, Android
> webview, and Samsung Internet are the only other implementations that
> support the header [2]. At this point, it represents too much of a risk
> to continue to enable in Firefox.
> A related mechanism, DNS Certification Authority Authorization (CAA)
> [3], also allows websites to restrict which CAs can issue certificates
> for their domains. This has seen much larger adoption and does not
> suffer from the drawbacks of HPKP.
> Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable
> HPKP via a preference. New HPKP headers will not be processed, and
> previously-cached HPKP information will not be consulted.
> The static list of key pinning information that ships with Firefox is
> still enabled, and these pins will still be enforced.
>
> [0] https://tools.ietf.org/html/rfc7469
> [1] https://www.chromestatus.com/feature/5903385005916160
> [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
> [3] https://tools.ietf.org/html/rfc6844
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
> [5] Coincidentally, version 72
> ___
> 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 Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

[Boris Chiou]

Hi Dirk,

I filed a spec issue [1] to get the feedback from the CSS WG. Before we get
the result in this week's call (or later), we won't ship this. Thanks for
your reminder.

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

On Sun, Nov 17, 2019 at 9:47 PM Dirk Schulze  wrote:

> Hi Boris,
>
> Did the CSS WG agree to ship the 3 transform functions? CSS Transforms
> level 2 is a working draft at the moment. It does describe 3D transforms
> and corresponding CSS properties as well but they shipped prefixed at a
> time where there weren't feature flags. For the 3 properties you propose
> shipping the situation is different.
>
> Greetings,
> Dirk
>
> 
> From: dev-platform  on behalf of
> Boris Chiou 
> Sent: Friday, November 15, 2019 12:01 AM
> To: dev-platform
> Subject: Intent to Ship: [css-transforms-2] Individual Transform
> Properties (i.e. translate, rotate, scale)
>
> Hi, All
>
> As of Firefox 72, I intend to turn the preference of individual transform
> properties, layout.css.individual-transform.enabled
> <
> https://searchfox.org/mozilla-central/rev/cac340f10816707e91c46db6d285f80259420f07/modules/libpref/init/StaticPrefList.yaml#4932
> >,
> on by default on all platforms. Blink has implemented it behind the
> experiment flag but Webkit doesn't support it yet. There are three
> properties defined in individual transform properties: translate, rotate,
> scale. Their rendering results should be equal to translate(), rotate(),
> and scale() functions on transform property.
>
> *Bug to turn on by default*:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1424900
>
> *Spec*: https://drafts.csswg.org/css-transforms-2/#individual-transforms
>
> *DevTools*: We don't support DevTools for individual transforms now.
>
> *WPT*:
>
> 1.
>
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/individual-transform
> 2.
>
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/animation
> 3.
>
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/parsing
>
> Thanks
> ___
> 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 Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

[Dirk Schulze via dev-platform]

Hi Boris,

Did the CSS WG agree to ship the 3 transform functions? CSS Transforms level 2 
is a working draft at the moment. It does describe 3D transforms and 
corresponding CSS properties as well but they shipped prefixed at a time where 
there weren't feature flags. For the 3 properties you propose shipping the 
situation is different.

Greetings,
Dirk


From: dev-platform  on behalf of Boris 
Chiou 
Sent: Friday, November 15, 2019 12:01 AM
To: dev-platform
Subject: Intent to Ship: [css-transforms-2] Individual Transform Properties 
(i.e. translate, rotate, scale)

Hi, All

As of Firefox 72, I intend to turn the preference of individual transform
properties, layout.css.individual-transform.enabled
,
on by default on all platforms. Blink has implemented it behind the
experiment flag but Webkit doesn't support it yet. There are three
properties defined in individual transform properties: translate, rotate,
scale. Their rendering results should be equal to translate(), rotate(),
and scale() functions on transform property.

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

*Spec*: https://drafts.csswg.org/css-transforms-2/#individual-transforms

*DevTools*: We don't support DevTools for individual transforms now.

*WPT*:

1.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/individual-transform
2.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/animation
3.
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-transforms/parsing

Thanks
___
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 Ship: motion path module level 1

[Dirk Schulze via dev-platform]

Hi Boris,

Blink doesn't support offset-anchor either it seems. Are you keeping it behind 
a feature flag as well?

The WebKit bug is here: https://bugs.webkit.org/show_bug.cgi?id=203847
At least initially I do not plan to implement offset-anchor either.

The spec currently is a working draft and not a candidate recommendation (CR). 
Is that going to get considered? Or did the CSS WG agree to ship?

For the spec it might make sense to split into 2 levels: Level 1 could be the 3 
longhand properties offset-path (with the limitations you mentioned), 
offset-distance and offset-rotate and the shorthand offset. Level 2 would 
include the 2 remaining properties and the ray() and basic shape functions. If 
2 implementations support the 3 longhand properties consistently it brings the 
spec of level 1 to CR faster.

Greetings,
Dirk


From: dev-platform  on behalf of Boris 
Chiou 
Sent: Thursday, November 14, 2019 11:44 PM
To: dev-platform
Subject: Intent to Ship: motion path module level 1

Hi, All

As of Firefox 72, I intend to turn the preference of motion-path,
layout.css.motion-path.enabled, on by default on all platforms. Blink has
shipped it already but Webkit doesn't support it yet. There are some
properties defined in the spec, and I would like to ship part of them, to
match the behaviors in Blink:

1. offset-path: none | path()

2. offset-distance

3. offset-rotate

4. offset-anchor

Note: We have implemented ray() for offset-path
, but there are
still some critical spec issues not resolved, so I will add a new
preference to disable it on beta and release channels.


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

*Spec*: https://www.w3.org/TR/motion-1/ (or
https://drafts.fxtf.org/motion-1/)

*DevTools*: We don't support DevTools for this motion-path now.

*WPT*:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/motion

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

New home for Firefox Bughandling Docs

[Emma Humphries]

Triage, regressions, priorities?

If you have questions about handling bugs in Firefox, check out our
documentation at its new home: https://firefox-bug-handling.mozilla.org/.

If you have questions, see an error, or would like to see documentation and
guides in area not covered; open an issue in our repo at
https://github.com/mozilla/bug-handling/.

Emma Humphries, Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

[Xidorn Quan]

On Fri, Nov 15, 2019, at 10:01 AM, Boris Chiou wrote:
> *DevTools*: We don't support DevTools for individual transforms now.

I think the current policy is that if it's worth devtools support, there should 
be a bug filed?

Also it seems to me this is something indeed devtools should be able to help 
more than just value inspection, e.g., devtools can probably show a combined 
transformation from all these properties as well as the old transform property.

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

deprecating mozilla-inbound

[Kim Moir]

Effective Thursday November 28, 2019, mozilla-inbound will be deprecated
for active development.  The repository will be changed to read-only for
historical reference.

You can refer to this bug for updates
https://bugzilla.mozilla.org/show_bug.cgi?id=inbound-outbound

Please reach out in the #conduit or #firefox-ci channels on Slack if you
have questions.

Thank you mozilla-inbound for your many years of service to the Mozilla
community.

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

Re: Intent to Ship: motion path module level 1

[Boris Chiou]

Hi Dirk,

Thanks for providing the link to the issue in Webkit. I reply to the
questions below:

> Blink doesn't support offset-anchor either it seems. Are you keeping it
behind a feature flag as well?
No, I am not planning to add a feature flag for it. It seems Blink has
almost finished this feature. Eric Willigers told me Blink has a bug on
`offset-anchor` (on an edge case, e.g. 0% 0%), so they haven't shipped it.
However I didn't see any new spec issues on it, so I think shipping it
should be fine. I'm ok to add an extra feature pref if you have concerns
about shipping it.

> The spec currently is a working draft and not a candidate recommendation
(CR). Is that going to get considered? Or did the CSS WG agree to ship?
There are still some other spec issues, at least for ray() function, so the
spec may not be ready for CR. However, since Blink has shipped it
(partially), and `offset-path:none|path()`, `offset-distance`, and
`offset-rotate` are stable, so it should be ok to ship them without asking
for permission.

> For the spec it might make sense to split into 2 levels: ... If 2
implementations support the 3 longhand properties consistently it brings
the spec of level 1 to CR faster.
Agree. it's a great suggestion. Should I file a spec issue for this, or you
would like to update the spec as 2 levels?

Regards,
Boris


On Sun, Nov 17, 2019 at 9:43 PM Dirk Schulze  wrote:

> Hi Boris,
>
> Blink doesn't support offset-anchor either it seems. Are you keeping it
> behind a feature flag as well?
>
> The WebKit bug is here: https://bugs.webkit.org/show_bug.cgi?id=203847
> At least initially I do not plan to implement offset-anchor either.
>
> The spec currently is a working draft and not a candidate recommendation
> (CR). Is that going to get considered? Or did the CSS WG agree to ship?
>
> For the spec it might make sense to split into 2 levels: Level 1 could be
> the 3 longhand properties offset-path (with the limitations you mentioned),
> offset-distance and offset-rotate and the shorthand offset. Level 2 would
> include the 2 remaining properties and the ray() and basic shape functions.
> If 2 implementations support the 3 longhand properties consistently it
> brings the spec of level 1 to CR faster.
>
> Greetings,
> Dirk
>
> 
> From: dev-platform  on behalf of
> Boris Chiou 
> Sent: Thursday, November 14, 2019 11:44 PM
> To: dev-platform
> Subject: Intent to Ship: motion path module level 1
>
> Hi, All
>
> As of Firefox 72, I intend to turn the preference of motion-path,
> layout.css.motion-path.enabled, on by default on all platforms. Blink has
> shipped it already but Webkit doesn't support it yet. There are some
> properties defined in the spec, and I would like to ship part of them, to
> match the behaviors in Blink:
>
> 1. offset-path: none | path()
>
> 2. offset-distance
>
> 3. offset-rotate
>
> 4. offset-anchor
>
> Note: We have implemented ray() for offset-path
> , but there are
> still some critical spec issues not resolved, so I will add a new
> preference to disable it on beta and release channels.
>
>
> *Bug to turn on by default*:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1582554
>
> *Spec*: https://www.w3.org/TR/motion-1/ (or
> https://drafts.fxtf.org/motion-1/)
>
> *DevTools*: We don't support DevTools for this motion-path now.
>
> *WPT*:
>
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/motion
>
> Thanks
> ___
> 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 unship: HPKP (dynamic key pinning)

[dkeeler]

Enabling certificate transparency in Firefox mostly depends on policy details 
that haven't been worked out yet. But yes, removing HPKP does not depend on CT.

On Monday, November 18, 2019 at 3:08:08 PM UTC-8, alex@gmail.com wrote:
> Hi Dana,
> 
> One thing I don't see mentioned here is certificate transparency, which, 
> while not a 1:1 replacement, nevertheless strongly contributes to the same 
> goal of control over issuance.
> 
> Is there a plan to implement SCT verification in Firefox, similar to what 
> Chrome and Apple have shipped? In either event, it sounds like the plan to 
> remove HPKP is not contingent on the answer on CT, correct?
> 
> Alex
> 
> On Sunday, November 17, 2019 at 9:16:56 PM UTC-5, Dana Keeler wrote:
> > The breadth of the web public key infrastructure (PKI) is both an asset 
> > and a risk. Websites have a wide range of certificate authorities (CAs) 
> > to choose from to obtain certificates for their domains. As a 
> > consequence, attackers also have a wide range of potential targets to 
> > try to exploit to get a mis-issued certificate. The HTTP Public Key 
> > Pinning (HPKP) [0] header was intended to allow individual sites to 
> > restrict the web PKI to a subset as it applies to their domains, thus 
> > decreasing their exposure to compromised CAs.
> > Unfortunately, HPKP has seen little adoption, largely because it has 
> > proved to be too dangerous to use. There are a number of scenarios that 
> > can render websites inoperable, even if they themselves don't use the 
> > header. Chrome removed support for it in version 72 in January of this 
> > year [1]. According to our compatibility information, Opera, Android 
> > webview, and Samsung Internet are the only other implementations that 
> > support the header [2]. At this point, it represents too much of a risk 
> > to continue to enable in Firefox.
> > A related mechanism, DNS Certification Authority Authorization (CAA) 
> > [3], also allows websites to restrict which CAs can issue certificates 
> > for their domains. This has seen much larger adoption and does not 
> > suffer from the drawbacks of HPKP.
> > Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable 
> > HPKP via a preference. New HPKP headers will not be processed, and 
> > previously-cached HPKP information will not be consulted.
> > The static list of key pinning information that ships with Firefox is 
> > still enabled, and these pins will still be enforced.
> > 
> > [0] https://tools.ietf.org/html/rfc7469
> > [1] https://www.chromestatus.com/feature/5903385005916160
> > [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
> > [3] https://tools.ietf.org/html/rfc6844
> > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
> > [5] Coincidentally, version 72

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