Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester 
wrote:
> As announced in this week's project call, sccache-dist schedulers have been
> deployed to mozilla offices, and those with hardware available can enroll
> servers based on the documentation here
> .

Just a reminder to not forget about us remotees! We are dying out here with 1+ 
hour compile times so anything would really help (even 20-20% improvement would 
go a long way). A lot of us have spare old macs, and if we can put them to good 
use with this, that would be amazing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[IMPORTANT] Submit your PI Requests for Firefox 72 QA feature testing by Nov 1

[Tom Grabowski]

Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx72. In order to help with the process,
please *submit your pi-request
*
by *November 1*. This
is needed to assure QA will be involved in your feature development work
for the 72 cycle. Kindly ensure to update the *Priority of the PI
request *(Highest,
High, Medium, Low, Lowest) as during feature prioritization process, this
will be factored in to ensure critical features have sufficient resources
assigned.

Please note that the *Feature technical documentation* for *features
require beta testing* needs to be ready before *November 8*. Please follow
the Feature Technical Documentation Guidelines Template

and share the information with the QA owners or add the link in the PI
request in JIRA. For *features that require Nightly testing*, please
provide documentation *as soon as possible*. QA cannot start working on
your feature without documentation.

*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

* Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle.

* Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these.

*Q: There's no way I'm going to remember to do this.*
A: Do it now! I'll also send out a reminder next week.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Jeff Gilbert]

Likewise I use `phlay` on git.

On Wed, Oct 23, 2019 at 1:35 PM Jörg Knobloch  wrote:

> On 23 Oct 2019 22:24, Emma Humphries wrote:
> > Will this make it easier for non-staff contributors to get their change
> > sets reviewed and landed?
> >
> > What else should we be doing for that.
> >
> > I have some ideas I'm working on for views in Bugzilla to help with that
> so
> > that contributors can see what's going on, and where they can take action
> > to help.
>
> Greetings from the Thunderbird sheriff!
>
> Just for the record: I'm using the Mercurial extensions 'hg phabsend'
> and 'hg phabread' as first described in Kris' post entitled "Re: Stopgap
> for Commit Series in Phabricator" on 26th July 2018 (yes, one - eight).
>
> That takes three minutes to set up and will work on any platform, also
> on Windows, where setting up Arcanist is apparently a 12-step
> process[1]. I don't know why these excellent extensions are not
> advertised more widely. Thanks to Ian Moody [:KWan] who pointed them out
> to me.
>
> 'hg phabsend' will complain if the reviewer isn't spelled correctly, I
> haven't tried without reviewer.
>
> Jörg.
>
> [1] https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html
>
> ___
> 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: Using MozPhab without Arcanist

[Jörg Knobloch]

On 23 Oct 2019 22:24, Emma Humphries wrote:

Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?

What else should we be doing for that.

I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's going on, and where they can take action
to help.


Greetings from the Thunderbird sheriff!

Just for the record: I'm using the Mercurial extensions 'hg phabsend' 
and 'hg phabread' as first described in Kris' post entitled "Re: Stopgap 
for Commit Series in Phabricator" on 26th July 2018 (yes, one - eight).


That takes three minutes to set up and will work on any platform, also 
on Windows, where setting up Arcanist is apparently a 12-step 
process[1]. I don't know why these excellent extensions are not 
advertised more widely. Thanks to Ian Moody [:KWan] who pointed them out 
to me.


'hg phabsend' will complain if the reviewer isn't spelled correctly, I 
haven't tried without reviewer.


Jörg.

[1] https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html

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

Re: Using MozPhab without Arcanist

[Emilio Cobos Álvarez]

On 10/23/19 10:24 PM, Emma Humphries wrote:

Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?

What else should we be doing for that.

I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's going on, and where they can take action
to help.


Somewhat unrelatedly, I think the most common issue I see with new 
contributors is they failing to set a reviewer. That means that their 
patch goes completely unnoticed... In that case not sure what can help, 
other than some of us noticing :/


I'm sure this is not a new problem though... That being said, it's a 
legit use-case, IMO, to update a WIP patch to phabricator without a 
reviewer, for example, to avoid spamming...


Maybe tools like moz-phab could suggest reviewers, or have a warning for 
the "no reviewers" case?


 -- Emilio



-- Emma

On Wed, Oct 23, 2019 at 8:56 AM glob  wrote:


It's available now - make sure you're running the latest version by
running `moz-phab self-update`.


-glob

Henrik Skupin wrote on 23/10/19 11:49 pm:

Piotr Zalewa wrote on 22.10.19 17:25:


Since today MozPhab does not require Arcanist to submit patches in all
supported VCS's. It's an optional and experimental feature. Add the
`--no-arc` option to switch it on.

Great to hear, but is there also an ETA when this mode will be available
for users of Mercurial? When I use this option I get:


NotImplementedError: Mercurial revisions can't be submitted without

Arcanist

Thanks



--
glob — engineering workflow — moz://a

___
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: Using MozPhab without Arcanist

[Emma Humphries]

Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?

What else should we be doing for that.

I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's going on, and where they can take action
to help.

-- Emma

On Wed, Oct 23, 2019 at 8:56 AM glob  wrote:

> It's available now - make sure you're running the latest version by
> running `moz-phab self-update`.
>
>
> -glob
>
> Henrik Skupin wrote on 23/10/19 11:49 pm:
> > Piotr Zalewa wrote on 22.10.19 17:25:
> >
> >> Since today MozPhab does not require Arcanist to submit patches in all
> >> supported VCS's. It's an optional and experimental feature. Add the
> >> `--no-arc` option to switch it on.
> > Great to hear, but is there also an ETA when this mode will be available
> > for users of Mercurial? When I use this option I get:
> >
> >> NotImplementedError: Mercurial revisions can't be submitted without
> > Arcanist
> >
> > Thanks
> >
>
> --
> glob — engineering workflow — moz://a
>
> ___
> 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: To what extent is sccache's distributed compilation usable?

[Christopher Manchester]

As announced in this week's project call, sccache-dist schedulers have been
deployed to mozilla offices, and those with hardware available can enroll
servers based on the documentation here
.
That document also contains instructions for building as a client after
servers have been enrolled.

We're still actively working on improvements, but early testing has proved
the current setup to be usable and provide compelling build time
improvements.
Visit https://github.com/mozilla/sccache/issues for open issues or to file
as they come up. Issues specific to integration with Mozilla's build system
are tracked by bug 1439584
.

Please join #sccache on Slack for questions or discussion.

Chris



On Fri, Jun 7, 2019 at 10:13 AM Chris M.  wrote:

> I've been working through issues with distributed sccache, but I've
> recently sent instructions to people currently running icecream in the SF
> office on how to switch to running sccache-dist with IT managed hardware.
> We're going to use that as a test bed before rolling out more widely, and
> if all goes well there this should happen shortly (likely shortly after
> returning from Whistler).
>
> Regarding that bug, that's tracking IT work for the most part so probably
> needs to stay restricted. Most of the work I've been doing is tracked in
> sccache's github repo and can be followed there, or tracked by
> https://bugzilla.mozilla.org/show_bug.cgi?id=1499145.
>
> Chris
>
> On Wed, Jun 5, 2019 at 1:52 AM Miko Mynttinen 
> wrote:
>
>> Has there been any progress with this? Bug 1524533 is still restricted.
>>
>> Miko
>>
>> > On Apr 2, 2019, at 10:39 PM, Jeff Muizelaar 
>> wrote:
>> >
>> > That bug is restricted. Does it need to be?
>> >
>> > -Jeff
>> >
>> > On Tue, Apr 2, 2019 at 4:22 PM Kim Moir  wrote:
>> >>
>> >> The tracking bug for sccache being deployed to offices is here
>> >>
>> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1524533
>> >>
>> >> Kim
>> >>
>> >> On Tue, Apr 2, 2019 at 3:22 AM Frederik Braun 
>> wrote:
>> >>
>> >>> Am 01.04.19 um 22:16 schrieb Chris M.:
>>  Hi Emilio, if you're interested you're encouraged to try it out,
>> however
>>  we're shipping machines to offices now to run the schedulers, the
>> first
>> >>> of
>>  which I'll be testing in the SF office this week, so we're planning
>> an
>>  officially supported setup in the near future.
>> 
>> >>>
>> >>> That's great news. Can we follow progress or detailed plans somewhere?
>> >>> ___
>> >>> 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
>>
>> ___
>> 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: Cookie SameSite=lax by default and SameSite=none only if secure

[2027gruebertomasv]

On Thursday, May 23, 2019 at 4:34:14 AM UTC-4, Andrea Marchesini wrote:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> 
> Summary:yo dudes. were dem cookies at
>   "1.  Treat the lack of an explicit "SameSite" attribute as
>"SameSite=Lax".  That is, the "Set-Cookie" value "key=value" will
>produce a cookie equivalent to "key=value; SameSite=Lax".
>Cookies that require cross-site delivery can explicitly opt-into
>such behavior by asserting "SameSite=None" when creating a
>cookie.
>2.  Require the "Secure" attribute to be set for any cookie which
>asserts "SameSite=None" (similar conceptually to the behavior for
>the "__Secure-" prefix).  That is, the "Set-Cookie" value
>"key=value; SameSite=None; Secure" will be accepted, while
>"key=value; SameSite=None" will be rejected."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798
> 
> Platform coverage: all
> 
> Estimated or target release: 69 - behind pref
> 
> Preferences behind which this will be implemented:
>  - network.cookie.sameSite.laxByDefault
>  - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
> 
> Is this feature enabled by default in sandboxed iframes? yes.
> 
> Do other browser engines implement this?
>  - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  - Safari: no signal yet.
> 
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
> 
> Is this feature restricted to secure contexts? no

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

Re: Using MozPhab without Arcanist

[glob]

It's available now - make sure you're running the latest version by 
running `moz-phab self-update`.



-glob

Henrik Skupin wrote on 23/10/19 11:49 pm:

Piotr Zalewa wrote on 22.10.19 17:25:


Since today MozPhab does not require Arcanist to submit patches in all
supported VCS's. It's an optional and experimental feature. Add the
`--no-arc` option to switch it on.

Great to hear, but is there also an ETA when this mode will be available
for users of Mercurial? When I use this option I get:


NotImplementedError: Mercurial revisions can't be submitted without

Arcanist

Thanks



--
glob — engineering workflow — moz://a

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

Re: Using MozPhab without Arcanist

[Henrik Skupin]

Piotr Zalewa wrote on 22.10.19 17:25:

> Since today MozPhab does not require Arcanist to submit patches in all
> supported VCS's. It's an optional and experimental feature. Add the
> `--no-arc` option to switch it on.

Great to hear, but is there also an ETA when this mode will be available
for users of Mercurial? When I use this option I get:

> NotImplementedError: Mercurial revisions can't be submitted without
Arcanist

Thanks

-- 
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re[2]: C++ standards proposal for a embedding library

[mhoye]

-- Original Message --
From: "Henri Sivonen" 


Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a generic platform capability as
opposed to it being a thing that one chooses from a number of
competitive options, it seems bad to build on the assumption that on
Windows the platform capability is Trident, which isn't getting new
Web features anymore.
While I'm admittedly way, way out of my swim lane here, I'd like to 
second one Henri's concerns; the specification as proposed doesn't admit 
that Trident is effectively gone and that the Mozilla API referenced in 
(1.) embedding is marked as "Obsolete" in places and otherwise full of 
red flags:



https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/Roll_your_own_browser


... but I'm equally concerned that this specification repeatedly assumes 
that a possibly-unbounded amount of poorly-defined work done by 
unspecified other people will manifest itself somehow:



"To be useful, we’ll need to require support for a large number external 
standards (i.e., [X]HTML, CSS, SVG, ECMAScript, and possibly others). 
Our three-year release cycle is likely sufficient to maintain a proper 
list of such standards, but it’s still a large list, and to be clear, 
the transitive closure of this list is huge. Nevertheless..."


"Required security and functionality updates on many platforms for 
web-content support may be far more frequent than updates to the C++ 
standard library, and a web_view in the C++ standard library should 
automatically use this frequently-updated web-content software."


"I fully expect that, if we decide to go down this route, additional 
utilities and abstractions will be added to go along with it."


"It should be noted that, as a limitation derived from current 
implementations, the URI scheme handlers provide a kind of virtual 
file-system interface, and as such, do not support POST data being 
provided to the handler along with the URI itself. To support that, and 
other protocols directly, we may need to provide an actual socket-based 
server to which the web_view could connect."


"Implementations are encouraged to support the latest WHATWG living 
standards, [wai-aria], [WebGL], [webrtc], [webvtt1], [SVG11], CSS 
standards, DOM standards, and otherwise maximize compatibility with 
other implementations (see, e.g., Can I use... )"


"It is expected that, for security reasons, implementations might 
restrict or disable this interface for web content provided by some 
remote sources."



In short, there is a _lot_ of "should", "might" and "may" in this 
specification. I have to admit that on a re-read, the basic idea of a 
standard API used to invoke an _existing external third-party browser_ - 
that a C++ program might want to define some content and interactions 
and maybe ask questions and get reasonably well-formed answers back - is 
about 99% less incredibly bonkers than my initial impressions, and there 
may well be something there worth pursuing, but as drafted this spec 
presumes a lot of future work and glosses over a lot of serious 
questions as a result.


- mhoye

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

Re: Intent to ship: CSS subgrid

[Ashley Gullen]

On a practical point as a web developer, in this case CSS subgrid is a part
of the wider CSS grid feature. It seems odd to make parts of the CSS grid
feature available in insecure contexts while other parts (subgrid) are
unavailable. I would argue this decision should have been made for the CSS
grid feature as a whole, and apply consistently to all aspects of the CSS
grid feature, so we don't end up with the compatibility nightmare of
bits-and-pieces of features being available in some cases but not others.


On Tue, 22 Oct 2019 at 09:54, James Graham  wrote:

> On 22/10/2019 00:07, L. David Baron wrote:
> > On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote:
> >> Hi David,
> >>
> >> On 10/21/19 7:22 AM, L. David Baron wrote:
> >>> (That we haven't applied the policy that much because we've granted
> >>> exceptions because other browsers have shipped the features reduces
> >>> the effectiveness of the policy and its ability to meet its goals.
> >>> This is the sort of policy that is most effective if it applies to
> >>> the largest number of thngs, both because it has larger effects and
> >>> because it sets much clearer expectations about what will be limited
> >>> to secure contexts.  I think it's worth considering reducing that
> >>> exception to the existence of actual web compat problems from the
> >>> secure contexts limitation.)
> >>
> >> Can you unpack this a little here?
> >>
> >> Are we saying we would ship features in non-secure contexts because
> sites
> >> theoretically rely on that behavior due to another browser shipping as
> >> non-secure before we did? (This sounds like the current rationale for
> >> exceptions, I think).
> >>
> >> Or are we saying we would ship a feature by default as secure and be
> willing
> >> (compelled?) to move to non-secure if we discover sites rely on other
> >> significant market share browsers not requiring a secure context for
> said
> >> feature -- once our users reported the bugs (or we did some kind of
> analysis
> >> beforehand)?
> >
> > I'm saying that we've been doing what you describe in the first
> > paragraph but maybe we need to shift to what you describe in the
> > second paragraph in order for the policy on secure contexts to be
> > effective.
>
> Shipping a Gecko-first feature limited to secure contexts, when we don't
> have evidence that other browsers will follow suite, runs the risk of
> sites breaking only in Gecko once the feature is widely deployed.
> Although we can always change the configuration after breakage is
> observed, the time taken to receive a bug report, diagnose the issue,
> and ship the fix to users, can be significant. This is a window during
> which we're likely to lose users due to the — avoidable — compatibility
> problems.
>
> I would argue that in the case where:
>
> * There is no compelling security or privacy reason for limiting a
> feature to secure contexts
>
> * There is reason to suspect that other browsers will ship a feature in
> both secure and insecure contexts (e.g. because limiting to secure
> contexts would be significant extra work in their engine, or because
> their past behaviour suggests that the feature will available everywhere)
>
> the trade-off between nudging authors toward https usage, and avoiding
> web-compat hazards should fall on the side of minimising the
> compatibility risk, and so we should ship such features without limiting
> to secure contexts.
>
> Alternatively we could have a policy that allows us to initially ship
> Gecko-first features meeting the above criteria as secure-context only,
> but that requires us to remove the limit if other browsers start
> shipping to their development channels without a secure-context limit.
> That minimises the compatibility risk — assuming we follow through on
> the process — but adds extra bureaucracy and has more steps to go wrong.
> I doubt the incremental effect on https adoption of this policy variant
> is worth the additional complexity, and suggest we should use this
> approach only if we misjudge the intentions of other vendors.
> ___
> 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: C++ standards proposal for a embedding library

[Henri Sivonen]

On Tue, Oct 22, 2019 at 11:55 PM Botond Ballo  wrote:
> Given that, would anyone be interested in reviewing the proposed API
> and providing feedback on its design? I feel like the committee would
> be receptive to constructive technical feedback, and as a group with
> experience in developing embedding APIs, we are in a particularly good
> position to provide such feedback.
>
> The latest draft of the proposal can be found here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

These comments are still more on the theme of this API being a bad
idea for the standard library on the high level as opposed to being
design comments on the specifics.

Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a generic platform capability as
opposed to it being a thing that one chooses from a number of
competitive options, it seems bad to build on the assumption that on
Windows the platform capability is Trident, which isn't getting new
Web features anymore.

Further on the Trident point, it doesn't really work to both say that
this is just exposing a platform capability and to go on to say that
implementations are encouraged to support [list of Web specs]. This
sort of thinking failed for the various Web on TV initiatives that got
whatever Presto and WebKit had. If the mechanism here is the Trident
embedding API on Windows, then you get whatever Trident has.

I'm curious how developers of libstdc++ and libc++ view the notion of
WebKitGTK+ as a platform capability. The C++ standard libraries are
arguably for Linux while the "platform capability" named (WebKitGTK+)
is arguably a Gnome thing rather than a Linux-level thing. That WPE
WebKit exists separately from WebKitGTK+ seems like a data point of
some kind: https://wpewebkit.org/

Section 4.4 argues against providing a localhost Web server
capability. I understand that the goal here is a user experience that
differs from the experience of launching a localhost HTTP server and
telling a Web browser to navigate to a localhost URL. However, the
additional arguments about the HTTP/2 and HTTP/3 landscape evolving
quickly and requiring TLS seem bad.

For localhost communication, HTTP/1.1 should address the kind of use
cases presented (other than the launch UX). Without actual network
latencies, HTTP/2 and HTTP/3 optimizations over HTTP/1.1 aren't _that_
relevant. Also, the point about TLS doesn't apply to HTTP/1.1 to
localhost. The notion that it's easier to create a multi-engine Web
engine embedding API that allows the embedder to feed the Web engine
pseudonetwork data is simpler than creating a localhost HTTP/1.1
server seems like a huge misestimation of the relative complexities.

Moreover, for either this API and a local HTTP server to work well, a
better way of dynamically generating HTML than is presented in the
example is required. It doesn't make sense to me to argue that
everything belongs in the standard library to the point of putting a
Web engine API there if a mechanism for generating the HTML to talk
with the Web engine doesn't belong in the standard library. If the
mechanism for generating the HTML is something you pull from GitHub
instead of something you get in the standard library, why can't
https://github.com/hfinkel/web_view be pulled from GitHub, too?

Finally, this seems very hand-wavy in terms of the security aspects of
loading remote content in a Web engine launched like this. My
understanding is that this has been an area of security problems for
Electron apps. It seems irresponsible not to cover this in detail, but
it also seems potentially impossible to do so, given the need to work
with whatever Web engine APIs that already exist as "platform
capabilities".

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

Re: Intent to prototype: JavaScript weak references

[Jonathan Coppeard]

On Friday, 18 October 2019 17:05:41 UTC+1, Jonathan Coppeard wrote:
> Preference:
> 
> This feature will be controlled by the javascript.options.weakrefs pref, 
> which will be off by default.

Correction: for consistency with other experimental features the pref used will 
be javascript.options.experimental.weakrefs.

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