Fission Mochitests moving to tier 1 and must all† pass by October 31st

[Kris Maglione]

Fission Milestone 4 is focused on getting all mochitests running and passing 
with Fission enabled. The deadline for the end of this milestone is October 
31st, approximately one month from today, and we still have a significant 
amount of work to do, with about 350 mochitests skipped and about 100 running 
but failing under Fission.


This is a high priority goal for the entire organization, which means that 
everyone is responsible for getting the tests that they maintain to pass. The 
DOM Fission team is available to help and to answer questions (you can find us 
in #domfission on IRC and #fission on Slack), but ultimately every team is 
responsible for its own tests.


You can check how many tests from your components are currently skipped or 
failing in the Are We Fission Yet dashboard: https://arewefissionyet.com/m4/


And you can get a more detailed lists of specific tests in our tracking 
spreadsheet‡: 
https://docs.google.com/spreadsheets/d/1kjp32JTuB4axM3wKx0iIYL2Ado-HcyeBhoY-siGxYAs/edit


There are also some basic tips for making tests Fission-compatible on the 
wiki: https://wiki.mozilla.org/Project_Fission/Enabling_Tests_with_Fission and 
in-tree docs with more details about working with Fission in non-test code: 
https://firefox-source-docs.mozilla.org/dom/dom/Fission.html For any questions 
not answered there, please reach out to the Fission team, and we will answer 
them as best we can.



Fission mochitests have been running on tier 2 for about a month now. We 
believe at this point that they are stable enough to run on every check-in, so 
in the month leading up to our deadline, they are moving to tier 1. Any 
check-in which causes a new M-fis failure will immediately be backed out, as 
will any patch which adds a new `skip-if` or `fail-if` annotation for Fission 
mode without approval from a member of the Fission team.



I also want to particularly thank Brian Grinstead for putting together the Are 
We Fission Yet dashboards, and Geoff Brown and Andrew Halberstadt for helping 
us get the data that we need to generate the dashboards and spreadsheets from 
treeherder.



† With some exceptions for tests of features which still require major 
platform work to become Fission compatible, and are in the M5 milestone. 
Moving tests to a later milestone requires approval from Project Fission 
management, and exceedingly strong justification.


‡ Only accessible to Mozilla staff. A read-only version is viewable at
https://docs.google.com/spreadsheets/d/e/2PACX-1vRRmnRUOy-KDDScK8o8Z6aKRaEtXKXb39Yn2OOPXoMgZwcMC3Oce3jgSjI5-jRK0jLS73gQYLkfSTJ_/pubhtml?gid=156071=true
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Negative radii in radial gradients.

[Emilio Cobos Álvarez]

These were always invalid per spec, but every browser parsed them.

Chromium was fixing a few of their bugs in the area (see 
https://github.com/w3c/csswg-drafts/issues/4042), and they made the 
change to reject negative lengths as well in:


 * https://bugs.chromium.org/p/chromium/issues/detail?id=1008112
 * https://bugs.chromium.org/p/chromium/issues/detail?id=978790

I think it makes sense, and somebody else independently filed:

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

So I think it's worth trying to get the change here.

Note that this affects both prefixed and modern gradient syntax.

Relatedly, recently people found interesting compat bugs in legacy 
gradients [1]... I may land a fix for that in the near future but that's 
not the point of this intent (that has ~no potential of breaking sites 
so I don't think it's worth an intent, so it's basically a bugfix).


There are WPTs for this change, and I didn't see a WebKit bug so I filed 
one at https://bugs.webkit.org/show_bug.cgi?id=202412.


Cheers,

 -- Emilio

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

Re: Web IDL interfaces now require explicit [Exposed] annotations

[Boris Zbarsky]

On 10/1/19 11:39 AM, Eric Shepherd (Sheppy) wrote:

Is the page “WebIDL bindings” up to date as well?


That page describes gecko-specific aspects of IDL, so usually does not 
need to be updated for spec changes.


That said, it looks like it was never updated for 
https://bugzilla.mozilla.org/show_bug.cgi?id=1489301 (removal of 
[Exposed=System]).  I'll fix that now.


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

Re: Web IDL interfaces now require explicit [Exposed] annotations

[Christopher Mills]

No. I didn't even know about that page ;-|

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Tue, Oct 1, 2019 at 4:39 PM Eric Shepherd (Sheppy) 
wrote:

> Is the page “WebIDL bindings” up to date as well? I often find it useful
> too.
>
> https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings
>
> On October 1, 2019 at 5:58:36 AM, Christopher Mills (cmi...@mozilla.com)
> wrote:
>
> I've removed the mention of PrimaryGlobal from
>
> https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file
> .
> It was only a small mention.
>
> I also removed the separate mention of the default value:
>
> "If no annotation is available, the default value is Window."
>
>
> 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: Web IDL interfaces now require explicit [Exposed] annotations

[Eric Shepherd (Sheppy)]

Is the page “WebIDL bindings” up to date as well? I often find it useful
too.

https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings

On October 1, 2019 at 5:58:36 AM, Christopher Mills (cmi...@mozilla.com)
wrote:

I've removed the mention of PrimaryGlobal from
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file
.
It was only a small mention.

I also removed the separate mention of the default value:

"If no annotation is available, the default value is Window."


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: Web IDL interfaces now require explicit [Exposed] annotations

[Boris Zbarsky]

On 10/1/19 5:58 AM, Christopher Mills wrote:

I've removed the mention of PrimaryGlobal from
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file.
It was only a small mention.

I also removed the separate mention of the default value:


Thank you!

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

Re: Web IDL interfaces now require explicit [Exposed] annotations

[Christopher Mills]

I've removed the mention of PrimaryGlobal from
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file.
It was only a small mention.

I also removed the separate mention of the default value:

"If no annotation is available, the default value is Window."

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Fri, Sep 27, 2019 at 8:10 PM Boris Zbarsky  wrote:

> Starting today (on autoland,coming to m-c soon), there is no more
> [PrimaryGlobal] extended attribute on interfaces in our Web IDL, and
> therefore all interfaces need an explicit [Exposed] annotation saying
> where they are exposed (e.g. [Exposed=Window] for the case that used to
> not have any annotation and default-exposed on mainthread).
>
> This aligns with upstream spec changes.
>
> If someone forgets to add [Exposed] on your interface, the parser will
> helpfully complain that there are globals the interface could be exposed
> on, but it's not exposed on any of them.
>
> Just copy/pasting IDL from specs should generally work; I believe most,
> if not all, specs updated to this upstream change a while ago.
>
> -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