Re: Is super-review still a thing?

[Eric Shepherd]

It seems that, yes, a model in which a patch to a given component would
need reviews by any one person in a specific pool of reviewers makes a lot
of sense. Even more so if the patch submitter doesn't have to figure out
who is in the pool.

Having a mechanism that supports a secondary, high-level review for cases
involving a lot of interrelated patches, architectural changes, UX updates,
etc. would also make a lot of sense. Call it a meta-review, perhaps; as in
reviewing a meta bug's set of changes.

-- 
Eric Shepherd
Senior Technical Writer
Mozilla Developer Network
https://developer.mozilla.org/
Blog: http://www bitstampede.com/
Twitter: https://twitter.com/sheppy


On May 10, 2018 at 11:15 AM, Gregory Szorc  wrote:



On May 10, 2018, at 06:47, Randell Jesup  wrote:

On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
How we might use blocking reviewers in our workflow is still open, but
it could be used for training up reviewers, in which case the trainee
would be a regular reviewer and the module peer/owner would be a
blocking reviewer.


It's not uncommon for me to submit patches for review from multiple people
where I require all reviewers to sign off on the patch, usually because I
ask them to look at different parts of the patch. I don't think I have
ever sent a patch to get review from more than one person with the
intention of landing it if only one person OKs it. (I'd probably needinfo
people to get that kind of feedback.) So ignoring potential new workflows
like the training one you mention, I think I would exclusively use blocking
reviewers. It's good to know that Phabricator will help me avoid
accidentally landing patches when not all of my reviewers have signed off.


Agreed... but it sounds like they're not quite sure how this will be
used. I'm concerned that developers may be confused and just as for
review by N people, not realizing it can be landed when one of them
r+'s. (Especially if the developer doesn't frequently use multiple
reviewers.) At minimum, if this how it works, there will been to be
clear communication about when to use this - or (better!) to switch the
default to blocking, and have the unusual/more-work-to-ask-for case be
any-of.

Once in a blue moon I'll ask for a fast review from any of N people,
then cancel the r?'s once i have 1 r+. but this is really rare, and
mostly when there's a time deadline to land something ASAP (sec issue,
or to get in ahead of a merge date). 99% of the time when I ask for N
people, I need r+ from all of them.

On the other side, I do know that the build peers (IIRC) us a shared
reviewing setup, where most bugs are thrown in a pool for any of them to
review. But that's not the normal workflow for any other group I know
of in Mozilla, at least in Firefox. (I don't know them all, though.)


When you take a step back, I think you have to conclude that our current
model of requesting reviews from *individuals* is not practical for the
common case. The way our code governance model works is that groups of
people (module members) are empowered to sign off on changes. But because
existing review tooling (practically speaking) only allows assigning
reviews to individuals (as opposed to a group consisting of module
members), that’s what we do. I.e. tools are dictating sub-optimal workflows
that don’t match our governance model.

In the common case, I think group assignment is preferred. Maybe it assigns
to an available person at submission time. But the submitter should not
need to be burdened with picking an individual. (This picking requirement
is especially hostile to new contributors who don’t know who to pick for
review.)

Phabricator has the concept of a normal “reviewer” and a “blocking
reviewer.” “Blocking” means they must sign off before the review is marked
as accepted.

I think the world we’ll eventually get to is one where most reviews are
assigned to groups (ideally automatically by mapping files changed to
appropriate reviewers) as normal non-blocking reviewers in Phabricator. For
special cases, we can assign individuals for review and/or set “blocking
reviewers” so someone or a member of a group *must* sign off. The review
submission tooling should make all of this turnkey - allowing people to
easily opt in to the special case if warranted. But most review requirement
policies should be codified so tools can apply/enforce them without human
intervention.

It’s worth noting that in a future world where the review tool isn’t
constraining us to assigning reviews to individuals and where group
assignment is the default, assignments to individuals may represent
shortcomings in the distribution of expertise. I.e. if only one person is
capable of performing a review, then we have a bus factor of 1 and there is
a business continuity concern. Assigning reviews to groups - perhaps
specialized groups like “dom experts” instead of the normal “dom peers”
group - helps reinforce that reviewing - and the 

Re: Update on rustc/clang goodness

[Xidorn Quan]

On Fri, May 11, 2018, at 10:35 AM, Anthony Jones wrote:
> I have some specific requests for you:
> 
> Let me know if you have specific Firefox related cases where Rust is 
> slowing you down (thanks Jeff [7])
> Cross language inlining is coming - avoid duplication between Rust 
> and C++ in the name of performance 
> Do developer builds with clang

Regarding the last item about building with clang on Windows, I'd not recommend 
people who use Visual Studio for debugging Windows build to build with clang at 
this moment.

I've tried using lld-link as linker (while continuing using cl rather than 
clang-cl) for my local Windows build, and it seems to cause problems when 
debugging with Visual Studio. Specifically, you may not be able to invoke 
debugging functions like DumpJSStack, DumpFrameTree in Immediate Windows, and 
variable value watching doesn't seem to work well either.

I've filed a bug[1] for the debugging function issue (and probably should file 
another for the watching issue as well).

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


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

Update on rustc/clang goodness

[Anthony Jones]

You may already know that the Low-Level Tools team support important tools and 
code infrastructure. Lately we’ve also been improving our rustc/clang (LLVM) 
story and I’d like bring everyone up to date.

There are a lot of important and interesting things going on:

* Michael Woerister and Nathan Froyd recently (mid-March) enabled Rust 
incremental compilation for Firefox developers
* Michael is experimenting with cross language inlining[1] (rustc/clang) 
using LTO
* Preliminary results show compiling LLVM with clang and using LTO on 
rustc improves stylo compilation time by around 15% [on-my-machine measurements]
* LTO requires more work to support Firefox
* Nick Nethercote has started speeding up rustc[2] and has already had a 
number of wins
* David Major has got Windows clang builds working with green tests
* LTO is still buggy (but works well enough to run benchmarks) and PGO 
won’t run on Windows
* Win32 - clang with LTO w/o PGO is marginally faster than MSVC with 
LTO/PGO
* Win64 - clang with LTO w/o PGO is ~5-10% slower than MSVC with LTO/PGO
* Windows users can build locally with clang[3]
* Mike Hommey is tracking improvements and regressions in the Rust compiler 
(performance regression[4], crash reporting[5] and more crash reporting[6])
* Tom Tromey is continuing to work on first class Rust support in GDB and 
LLDB

Note: this a summary of things rustc/clang stuff that is happening only.

Ultimately, I’d like to see us standardise on clang on all platforms because it 
makes Rust/C++ integration better as well as making things simpler for 
developers and build system maintainers. We’ll get more done if we make our own 
lives simpler.

I have some specific requests for you:

Let me know if you have specific Firefox related cases where Rust is 
slowing you down (thanks Jeff [7])
Cross language inlining is coming - avoid duplication between Rust and C++ 
in the name of performance 
Do developer builds with clang

Anthony

[1] https://github.com/rust-lang/rust/issues/49879
[2] 
https://blog.mozilla.org/nnethercote/2018/04/30/how-to-speed-up-the-rust-compiler-in-2018/
[3] 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl
[4] https://github.com/rust-lang/rust/issues/49873
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1456150
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1448868
[7] https://github.com/rust-lang/rust/issues/50584

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

Re: Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

As the removal has rode the trains through Beta without issue I'm going to
remove AppCache over insecure contexts for stable as originally stated for
62.

The work is happening here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460478

Mike west did a wonderful job of adding web-platform-tests thank you!

https://github.com/w3c/web-platform-tests/commit/bf17459a71ff4d1ea280bae54dd046ecf86e0628



On Fri, Feb 2, 2018 at 2:58 PM, Jonathan Kingston  wrote:

> This has now landed into central and appears to be sticking:
> https://www.fxsitecompat.com/en-CA/docs/2018/support-for-
> application-cache-on-insecure-sites-has-been-deprecated/
>
> I have filed a follow up bug to remove "OfflineResourceList" interface we
> use: https://bugzilla.mozilla.org/show_bug.cgi?id=1435261
>
> Also Anne filed a bug on the standard as it appears other browsers are
> interested now in doing the same: https://github.com/whatwg/
> html/issues/3440
>
> This also means we can move the tests into Web Platform Tests to ensure
> all browsers implement the same.
>
>
> On Fri, Jan 19, 2018 at 6:55 PM, Jonathan Kingston 
> wrote:
>
>> > Its been suggested before that we could leave the applicationCache
>> global in place, but just make it do nothing in insecure contexts.
>>
>> I did see this idea of keeping the applicationCache global in one of the
>> bugs, I think if we have breakage we could try this as a follow up piece of
>> work along with other approaches like expiring the cache more often.
>>
>> On Fri, Jan 19, 2018 at 5:47 PM, Ben Kelly  wrote:
>>
>>> On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor  wrote:
>>>
 > When the pref is set to false the API will be removed:
 >
 >   -
 >
 >   window.applicationCache will be removed
 >   -
 >
 >   The cache service Firefox implements for AppCache will be disabled
 over
 >   Insecure Contexts
 >
 >
 > When the pref is set to true the code will produce an additional
 developer
 > console warning about the removal timeline.
 >
 > In Nightly and Early beta for 60; the pref will be set to false
 removing
 > the API.

 It will be interesting to see if we get reports of pages (that don’t
 feature test) throwing with the missing applicationCache global. A few
 years (and laptops) ago I had done some site corpus grepping — I’ll see if
 I can find any of that data.

>>>
>>> Its been suggested before that we could leave the applicationCache
>>> global in place, but just make it do nothing in insecure contexts.
>>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unprefix: ::-moz-selection.

[Emilio Cobos Álvarez]

In the CSSWG April F2F in Berlin this was extensively discussed and the 
CSSWG allowed / recommended us to unprefix this despite changing the spec.


Just landed the change unprefixing this on inbound, let me know if you 
see something broken because of it.


Thanks!

 -- Emilio

On 3/26/18 9:16 AM, Emilio Cobos Álvarez wrote:

Hi,

In bug 509958 I intend to unprefix the ::-moz-selection pseudo-element.

The situation here is not great wrt the spec saying what we do, or what
other implementations do for that matter, see [1].

However other engines have shipped this unprefixed for a long time with
the same semantics that we implement, and we're seeing webcompat
problems due to people forgetting to include ::-moz-selection in their
style sheets, see bug 1427680 or bug 1448670 for some examples.

Given I don't think other engines have any incentive to implement what
the spec says (given it's slower, and has the chance of giving them
webcompat headache), and that we're compatible with them, I proposed to
adapt the spec to reality in that spec issue, and unprefix our
pseudo-element.

Let me know if there's any concerns with this plan. Thanks!

  -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/2474
___
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: Is super-review still a thing?

[Gregory Szorc]

On May 10, 2018, at 06:47, Randell Jesup  wrote:

>>> On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
>>> How we might use blocking reviewers in our workflow is still open, but 
>>> it could be used for training up reviewers, in which case the trainee 
>>> would be a regular reviewer and the module peer/owner would be a 
>>> blocking reviewer.
>> 
>> It's not uncommon for me to submit patches for review from multiple people
>> where I require all reviewers to sign off on the patch, usually because I
>> ask them to look at different parts of the patch.  I don't think I have
>> ever sent a patch to get review from more than one person with the
>> intention of landing it if only one person OKs it.  (I'd probably needinfo
>> people to get that kind of feedback.)  So ignoring potential new workflows
>> like the training one you mention, I think I would exclusively use blocking
>> reviewers.  It's good to know that Phabricator will help me avoid
>> accidentally landing patches when not all of my reviewers have signed off.
> 
> Agreed... but it sounds like they're not quite sure how this will be
> used.  I'm concerned that developers may be confused and just as for
> review by N people, not realizing it can be landed when one of them
> r+'s.  (Especially if the developer doesn't frequently use multiple
> reviewers.)  At minimum, if this how it works, there will been to be
> clear communication about when to use this - or (better!) to switch the
> default to blocking, and have the unusual/more-work-to-ask-for case be
> any-of.
> 
> Once in a blue moon I'll ask for a fast review from any of N people,
> then cancel the r?'s once i have 1 r+.  but this is really rare, and
> mostly when there's a time deadline to land something ASAP (sec issue,
> or to get in ahead of a merge date).  99% of the time when I ask for N
> people, I need r+ from all of them.
> 
> On the other side, I do know that the build peers (IIRC) us a shared
> reviewing setup, where most bugs are thrown in a pool for any of them to
> review.  But that's not the normal workflow for any other group I know
> of in Mozilla, at least in Firefox.  (I don't know them all, though.)

When you take a step back, I think you have to conclude that our current model 
of requesting reviews from *individuals* is not practical for the common case. 
The way our code governance model works is that groups of people (module 
members) are empowered to sign off on changes. But because existing review 
tooling (practically speaking) only allows assigning reviews to individuals (as 
opposed to a group consisting of module members), that’s what we do. I.e. tools 
are dictating sub-optimal workflows that don’t match our governance model.

In the common case, I think group assignment is preferred. Maybe it assigns to 
an available person at submission time. But the submitter should not need to be 
burdened with picking an individual. (This picking requirement is especially 
hostile to new contributors who don’t know who to pick for review.)

Phabricator has the concept of a normal “reviewer” and a “blocking reviewer.” 
“Blocking” means they must sign off before the review is marked as accepted.

I think the world we’ll eventually get to is one where most reviews are 
assigned to groups (ideally automatically by mapping files changed to 
appropriate reviewers) as normal non-blocking reviewers in Phabricator. For 
special cases, we can assign individuals for review and/or set “blocking 
reviewers” so someone or a member of a group *must* sign off. The review 
submission tooling should make all of this turnkey - allowing people to easily 
opt in to the special case if warranted. But most review requirement policies 
should be codified so tools can apply/enforce them without human intervention.

It’s worth noting that in a future world where the review tool isn’t 
constraining us to assigning reviews to individuals and where group assignment 
is the default, assignments to individuals may represent shortcomings in the 
distribution of expertise. I.e. if only one person is capable of performing a 
review, then we have a bus factor of 1 and there is a business continuity 
concern. Assigning reviews to groups - perhaps specialized groups like “dom 
experts” instead of the normal “dom peers” group - helps reinforce that 
reviewing - and the knowledge required to perform it - is a shared 
responsibility and isn’t limited to single individuals. This is another reason 
why I think it is a good idea to lean heavily towards group-based review over 
individual. Even if the group consists of a single person, a group reinforces 
that the responsibility is distributed.

I think that once review submission doesn’t require submitters to choose 
reviewers and reviews magically end up on the plates of appropriate people, 
we’ll all look back at our current workflow and view it as primitive.
___
dev-platform mailing list

Re: Intent to unprefix: ::-moz-selection.

[Emilio Cobos Álvarez]

Sorry for not following up on this earlier, Ehsan, somehow this slipped 
through my inbox.


On 4/6/18 1:26 AM, Ehsan Akhgari wrote:

::-moz-selection seems like a fairly popular feature.  PublicWWW claims
it's seen on a million sites:
https://publicwww.com/websites/%22%3A%3A-moz-selection%22/

After this change, is it feasible to detect the usage of the prefixed
pseudo-element so that existing code that uses ::-moz-selection would emit
a helpful console warning?  It would be nice to have a way to communicate
to web developers that they can now remove the Gecko specific rules.


It is feasible, but it's not clear to me how worth it is to land this 
now. In particular, we're going to keep parsing ::-moz-selection for now 
as an alias, since as you mentioned it's a fairly popular feature, and 
people won't be able to remove it for a while if they want to support 
ESR and similar.


If we decide to remove the prefixed version, developers would get a in 
the console automatically if they have the CSS error filter enabled that 
would look like:


  Unknown pseudo-class or pseudo-element ‘-moz-selection’.  Ruleset 
ignored due to bad selector.


Which should be enough to hint them that they can remove it.

 -- Emilio


On Mon, Mar 26, 2018 at 9:21 AM Emilio Cobos Álvarez 
wrote:


Hi,

In bug 509958 I intend to unprefix the ::-moz-selection pseudo-element.

The situation here is not great wrt the spec saying what we do, or what
other implementations do for that matter, see [1].

However other engines have shipped this unprefixed for a long time with
the same semantics that we implement, and we're seeing webcompat
problems due to people forgetting to include ::-moz-selection in their
style sheets, see bug 1427680 or bug 1448670 for some examples.

Given I don't think other engines have any incentive to implement what
the spec says (given it's slower, and has the chance of giving them
webcompat headache), and that we're compatible with them, I proposed to
adapt the spec to reality in that spec issue, and unprefix our
pseudo-element.

Let me know if there's any concerns with this plan. Thanks!

  -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/2474
___
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: Is super-review still a thing?

[Randell Jesup]

>On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
>> How we might use blocking reviewers in our workflow is still open, but 
>> it could be used for training up reviewers, in which case the trainee 
>> would be a regular reviewer and the module peer/owner would be a 
>> blocking reviewer.
>
>It's not uncommon for me to submit patches for review from multiple people
>where I require all reviewers to sign off on the patch, usually because I
>ask them to look at different parts of the patch.  I don't think I have
>ever sent a patch to get review from more than one person with the
>intention of landing it if only one person OKs it.  (I'd probably needinfo
>people to get that kind of feedback.)  So ignoring potential new workflows
>like the training one you mention, I think I would exclusively use blocking
>reviewers.  It's good to know that Phabricator will help me avoid
>accidentally landing patches when not all of my reviewers have signed off.

Agreed... but it sounds like they're not quite sure how this will be
used.  I'm concerned that developers may be confused and just as for
review by N people, not realizing it can be landed when one of them
r+'s.  (Especially if the developer doesn't frequently use multiple
reviewers.)  At minimum, if this how it works, there will been to be
clear communication about when to use this - or (better!) to switch the
default to blocking, and have the unusual/more-work-to-ask-for case be
any-of.

Once in a blue moon I'll ask for a fast review from any of N people,
then cancel the r?'s once i have 1 r+.  but this is really rare, and
mostly when there's a time deadline to land something ASAP (sec issue,
or to get in ahead of a merge date).  99% of the time when I ask for N
people, I need r+ from all of them.

On the other side, I do know that the build peers (IIRC) us a shared
reviewing setup, where most bugs are thrown in a pool for any of them to
review.  But that's not the normal workflow for any other group I know
of in Mozilla, at least in Firefox.  (I don't know them all, though.)

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: URL.createObjectURL(MediaStream)

[Randell Jesup]

I was behind on m.d.platform, I'm afraid.

tl;dr: This is Long, but in the end I support removal of
createObjectURL(MediaStream) in 62.

For anyone who wants to see why, read below.  It does make some
important points to think about when considering removal, especially
about how to gauge usage.

>On 4/23/18 3:50 AM, Andrea Marchesini wrote:
>> I introduced a deprecated message in bug 1334564, the 7th, February 2017.
>
>When we have this data, it's worth mentioning what telemetry shows for such
>a deprecation message.
>
>I just checked and out of about 5.8 billion pageloads on Beta 60, about
>160,000 used this method [1].  For Beta 59 those numbers are 7.6 billion
>and 700,000 respectively [2].
>
>So about .01% of pageloads are using this feature on beta 59; about .003%
>on beta 60.

So: I Really Really want to see createObjectURL(MediaStream) go away - I
fought for srcObject, we got it into the spec, and I fought attempts to
ignore it by Google.  And I fought attempts to reinstate it.

That said...

>That does seem low enough that removal might be reasonable, as long as
>there isn't some site like Hangouts which uses it, and is not usable in
>Firefox yet but we would like to be usable...

I think first-tier sites like Hangouts, appear.in, WebEx, talky.io, etc
will be fine and likely are using srcObject already (or will quickly
switch).

Second-tier sites I suspect will have a fair number get hit by it, but
likely they'll mostly correct it quickly.  Some may well do the "use
Chrome" bit.  Some do that already (Slack, I'm looking at you!!)

Small sites, demos, unusual uses, examples all over the web: they'll
mostly stay broken.  Of course no matter when we change a lot of them
will break - almost by definition they're not being updated.  (Some blog
posts/demos might get updated or people will comment "change to srcObject".)

So, I'm torn.  I want to see it gone, and usage will never be 0.
However...  With lots of (not all) web features, disabling it doesn't
kill the entire page/application.  Perhaps something doesn't look right,
or some subset of the page doesn't work.  With WebRTC (and friends like
WebAudio), if the connection the media elements fails, then the entire
application is likely fubar.

And until not that long ago, Chrome didn't even support srcObject, let
alone promote it in all their demos, examples, etc.  They added support
for it in Chrome 52, less than 2 years ago.  They did an
IntentToDeprecate in January, with plans to deprecate in 65 or 66 and remove
in 68 - 70 was suggested (because they're worried too many sites still rely
on it).  66 only just shipped a few weeks ago.  Their demo sites as of
January still mostly used srcObject (they did a PR for HTML5 Rocks after
deciding to deprecate).

Deprecation in blink discussion:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tWzutytXsqc

Safari supported srcObject by late 2017 in Safari 11 (perhaps also in
10), and as of early this year had already removed
createObjectURL(MediaStream).

We announced deprecation almost 6 months before Chrome even supported
srcObject, so when we announced deprecation isn't really the driving
factor here.

When comparing Chrome's usage for createObjectURL(MediaStream) and
srcObject, it's clear that while srObject is getting used more in the
last ~3 months (since the decision to deprecate??), and is used more
than createObjectURL, usage of createObjectURL isn't decreasing - if
anything it's slightly trending up.  And ~1/4 of all uses are
createObjectURL.

https://www.chromestatus.com/metrics/feature/timeline/popularity/1606
https://www.chromestatus.com/metrics/feature/timeline/popularity/1603

This goes back to Boris's discussion of the usage in telemetry -
unfortunately, that doesn't tell us how much the alternative/replacement
for the deprecated feature is used.  (For future telemetry on
feature-disabling, this would be a good idea when it's feasible.)  And
of course we only have beta stats, not release (which chrome has).

BTW, this is the 'real' bug in Chrome for removing it:
https://bugs.chromium.org/p/chromium/issues/detail?id=800767=2
The patch to the Deprecation file tells devs it'll be gone in 68.

At 1.5-2 months per Chrome release, that means that in about 2.5 months
it will be removed from Chrome, if they don't delay removal.  They might.


So, in the end, I absolutely support removing it, since if we remove in
62, it will get to release in about Sep 9th, which is likely *after*
Chrome actually removes it (likely around late July or August).  If
Chrome delays to 70 as someone in the thread suggested (and I see as
possible), that would be perhaps October-ish.

Kill it with fire.  :-)

>-Boris
>
>[1]
>https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2018-04-18=__none__!__none__!__none___channel_version=beta%252F60=USE_COUNTER2_DEPRECATED_URLCreateObjectURL_MediaStream_PAGE_channel_version=null=*=Firefox=1_keys=submissions_date=2018-03-04=0=1_submission_date=0
>

Intent to unship http-equiv cookies

[Jonathan Kingston]

Meta tags provide equivalent behaviour to sending HTTP headers via the
“http-equiv” attribute.

Set-Cookie can be used to provide cookies to the user via this attribute:


However this behaviour isn’t restrictable via a Content Security Policy.
This gives an attacker the ability to change a users cookies via an XSS
exploit and also fixate session cookies.

Impact on the Web:

The HTML specification has removed this behaviour:

https://github.com/whatwg/html/pull/3649

Web platform tests:

https://github.com/w3c/web-platform-tests/blob/master/cookies/meta-blocked.html

Chrome removed in version 65 and it appears Edge has implemented the
changes to land in the next release.

The usage of the feature is intermittent according to Chrome: “shows up on
~0.02% of pages, with intermittent spikes up to ~0.06%. Cloudflare's error
page seems like a reasonable explanation of this behavior”.

Chrome’s intent to deprecate:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/0sJ8GUJO0Dw/iMmcXLIGBAAJ

Chrome code: https://bugs.chromium.org/p/chromium/issues/detail?id=767813

Removal implementation:

The rollout strategy is to disable via a preference and let it ride the
releases to stable.

Firefox will remove access to this feature in Firefox 62

The work will commence in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1457503

Kind regards

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

W3C Proposed Recommendation: Web Driver

[L. David Baron]

A W3C Proposed Recommendation is available for the membership of
W3C (including Mozilla) to vote on, before it proceeds to the final
stage of being a W3C Recomendation:

  Web Driver
  https://www.w3.org/TR/webdriver/
  https://w3c.github.io/webdriver/webdriver-spec.html
  Deadline for responses: Thursday, May 24, 2018

If there are comments you think Mozilla should send as part of the
review, please say so in this thread.  Ideally, such comments should
link to github issues filed against the specification.  (I'd note,
however, that there have been previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage.)

This is something that we implement, and David Burns is one of the
editors of the document, so we should definitely comment (probably
in support).

-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

W3C Proposed Recommendation: Canonical EXI

[L. David Baron]

A W3C Proposed Recommendation is available for the membership of
W3C (including Mozilla) to vote on, before it proceeds to the final
stage of being a W3C Recomendation:

  Canonical EXI
  https://www.w3.org/TR/exi-c14n/
  Deadline for responses: Thursday, May 24, 2018

If there are comments you think Mozilla should send as part of the
review, please say so in this thread.  Ideally, such comments should
link to github issues filed against the specification.  (I'd note,
however, that there have been previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage.)

EXI is a compressed binary format for XML; Canonical EXI defines a
way of canonicalizing certain things that might vary between
theoretically-equivalent documents, which is apparently useful for
things like XML Signature.  We don't implemented any of these things
as far as I'm aware.

-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