Re: Intent to Implement- Double-keyed HTTP cache

[Martin Thomson]

Hi Sebastian,

I'm glad to see us moving toward having better isolation in this way.

In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins.  That is, if A frames B and C, and B in turn also
frames C, then the two C frames are isolated from each other in the same
way that they are isolated from a top-level C.

I took a look at both the fetch issue and your patch and it wasn't clear
what strategy we're using.  As an aside, an issue on a repo isn't really a
specification.  I couldn't find a PR on fetch either.

What is the tuple we're keying on?

Cheers,
Martin

On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich 
wrote:

> Intent to Implement- Double-keyed HTTP cache
>
>
> Summary:
>
> Currently Browsers are vulnerable to cache-timing attacks, commonly
> referred to as XS Leaks attacks. Starting with Firefox 70 we want to
> explore a double-keyed HTTP cache. Instead of solely using the origin of
> the resource, we will double key the HTTP Cache using the top-level origin.
> Using the top-level origin as the 2nd Key in the HTTP Cache allows to
> counterfeit XS Leaks and eliminates the ability of checking cache contents
> across Origins.
>
> Bug:  Bugzilla 1536058
> 
>
> Standard: https://github.com/whatwg/fetch/issues/904
>
> Platform coverage: all platforms
>
> Estimated or target release: Firefox 70
>
> Preference: The feature will be pref'd behind
> “browser.cache.cache_isolation”
>
>  and disabled by default.
>
> Other browsers:
>
> webkit: shipped
>
> Chrome :
> implementing
>
> web-platform-tests: 
>
> Secure contexts:  This feature isn’t restricted to Secure Contexts.
> Estimated or target release: Firefox 70
> ___
> 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: Must we rebuild all our rust code constantly?

[ISHIKAWA,chiaki]

Well, I have a problem now after trying to update sccache just in case I 
need a new version in the future.


I did the following:

cargo install --force sccache

(I was not so sure of what the proper update procedure of already 
installed package. sccache 2.0.8-alpha-something was already installed.)


Then when I try to compile TB using the command script which worked for 
more than a few years suddenly printed the following and failed. I think 
I have messed up my cargo metadata somehow by the above command.


I have run |mach bootstrap| to see if it fixes the issue. It did not.

ERROR: Couldn't execute `cargo metadata` with manifest 
"/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust/Cargo.toml": 
Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "", 
stderr: "error: failed to select a version for the requirement `libc = 
\"= 0.2.62\"`\n  candidate versions found which didn\'t match: 0.2.60\n  
location searched: directory source 
`/NREF-COMM-CENTRAL/mozilla/third_party/rust` (which is replacing 
registry `https://github.com/rust-lang/crates.io-index`)\nrequired by 
package `mozjs_sys v0.0.0 (/NREF-COMM-CENTRAL/mozilla/js/src)`\nperhaps 
a crate was updated and forgotten to be re-vendored?\n" })
ERROR: Couldn't generate bindings for 
/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust.

make[4]: *** [backend.mk:72: .deps/ServoStyleConsts.h.stub] Error 1
make[3]: *** [/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:101: 
layout/style/export] Error 2

make[3]: *** Waiting for unfinished jobs
ERROR: Couldn't execute `cargo metadata` with manifest 
"/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust/Cargo.toml": 
Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "", 
stderr: "    Blocking waiting for file lock on package cache 
lock\nerror: failed to select a version for the requirement `libc = \"= 
0.2.62\"`\n  candidate versions found which didn\'t match: 0.2.60\n  
location searched: directory source 
`/NREF-COMM-CENTRAL/mozilla/third_party/rust` (which is replacing 
registry `https://github.com/rust-lang/crates.io-index`)\nrequired by 
package `mozjs_sys v0.0.0 (/NREF-COMM-CENTRAL/mozilla/js/src)`\nperhaps 
a crate was updated and forgotten to be re-vendored?\n" })
ERROR: Couldn't generate bindings for 
/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust.

make[4]: *** [backend.mk:11: .deps/webrender_ffi_generated.h.stub] Error 1
make[3]: *** [/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:101: 
gfx/webrender_bindings/export] Error 2


Does anyone have a clue how to restore order here?

TIA

Chiaki


On 2019/08/21 4:33, Markus Stange wrote:

On 2019-08-19 8:11 p.m., Dave Townsend wrote:
Thanks to a tip I've tracked this down. This seems to only be the 
case when
I have sccache enabled. Disabling it gives me nice quick incremental 
builds

again.


What's your sccache version? I think you may be hitting the following 
sccache bug which has been fixed already:

https://github.com/mozilla/sccache/issues/436

I'm using sccache 0.2.9 and I don't see rust code rebuilding constantly.

Markus
___
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: Must we rebuild all our rust code constantly?

[ISHIKAWA, Chiaki]

On 2019/08/21 3:52, Eric Rahm wrote:

mach clobber --full


Thank you for the tips.

I will try this.

At the same time, I have a feeling that the debug symbol that rustc 
generates may be a tad bigger than I would like it to be, but I need to 
investigate more about this.


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

Watch out for build issues on non-Unicode systems

[Mike Hommey]

Hi,

In bug 1575135 and bug 844509, we've changed how configure handles
strings from files and subprocesses, to normalize everything to Unicode.

On systems where the system locale is based on UTF-8 (e.g. most Linux
or macOS), this shouldn't make a difference.

On systems where the system locale is not based on UTF-8, this might
cause problems, so please watch out, especially on non-Latin Windows.

I don't believe things would have regressed (things should be handled
more or less similarly to before). I can think of a few things that
could fail, but for that matter, those I have in mind would have failed
before too.

However, it is possible that a few corner cases that are not covered by
automation lead to configure complaining about some key or values not
being unicode strings. If that happens, please file bugs with your
mozconfig and as much detail as possible.

Cheers,

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

Intent to unship: Legacy MathML syntax for numbers

[Frédéric Wang]

Hi,

After the changes mentioned in previous announcements [1] [2] [3] [4],
the valid MathML length values are almost a subset of CSS
 and we could consider relying on the CSS parser in
the future.

The only remaining difference is in the definition of numbers since
MathML3 allows the following case: an optional "-", followed by a
nonempty sequence of digits, followed by a dot. For example "42.px" is
valid MathML3 length and equivalent to "42px". For details see [5].

The MathML CG decided to align the definition of numbers on CSS [6].
This syntax is supported in WebKit too. However, it seems safe to unship
it without deprecation warning since it's really an edge case and it is
very unlikely that people/tools would write/generate a number ending
with a dot. I plan to do this in bug 1575596.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/yEMdIOo4i-0
[2] https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek
[3] https://groups.google.com/forum/#!topic/mozilla.dev.platform/G91-vBeC3Rw
[4] https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1574751#c2
[6] https://github.com/mathml-refresh/mathml/issues/23

-- 
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship New Certificate Viewer

[Nils Ohlmeier]

Wow. This is awesome. So much better then the old certificate viewer!

Thanks
  Nils

> On 16Aug, 2019, at 12:52, Danielle Leblanc-Cyr  
> wrote:
> 
> Hi everyone,
> 
> We’re Carolina and Danielle, two Outreachy interns who have been working
> with the Security Engineering team. We’ve spent the past few months working
> on porting over pieces of the Certainly Something
>  web
> extension (shout out to April for all of the work she put into it!), to
> create a new certificate viewer. We’re now at the point where we’ve landed
> most of our patches and the project is really coming together – we’re
> hoping to soon replace the existing Firefox certificate viewer.
> 
> We’ve worked really hard the past few months – getting accustomed to the
> Firefox codebase and workflow, learning about new tools, and creating as
> many tests as we could think of. We really appreciate all of the people and
> channels who’ve answered our (many) questions this summer, and who’ve
> helped to steer us in the right direction - especially our mentors, Johann,
> Dana and April.
> 
> The new implementation currently lives behind pref
> "security.aboutcertificate.enabled", which bug 1572368 will default to
> true. We’re hoping for this new certificate viewer to ride the trains in
> Firefox 71.
> 
> The summer has flown by, but we’re excited to continue contributing to
> Mozilla and to remain active members of this awesome community.
> 
> Thanks for all of the support!
> 
> This is the link to the web-extension which we used as a blueprint:
> https://github.com/april/certainly-something
> 
> And here is all the development of the project:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1553524
> 
> Carolina and Danielle
> ___
> 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

Doc review request for MIME type “codecs” parameter article

[Eric Shepherd (Sheppy)]

If anyone has time to spare at some point, I've finished drafting a new
article "The 'codecs' parameter in common media types” [1]. It’s intricate
enough, and gathers enough information from a wide enough variety of tricky
sources, that it would really benefit from a review for technical accuracy
from people with a closer familiarity with the topic.

Make corrections, or suggest them to me and I’ll make them if you’re not
comfortable doing it yourself. I’m not picky. ;)

Thank you in advance!

[1]
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter


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

Intent to unship AppCache

[Jonathan Kingston]

The design of AppCache brings many problems to the web platform from a
performance and security perspective. Service workers have long solved the
same use cases as AppCache.

Removal of this code would bring a large reduction of code and complexity
that is largely unmaintained.

History

Four years ago, in Firefox 44, we marked the API as deprecated[1].

Back last year in Firefox 62, we disabled insecure AppCache and Chrome
followed suit[2].

Safari 11.1 added support for Service Workers, which are a replacement
technology [3].

Metrics

Chrome measures a few different metrics here which suggest 2.3%[4] of
secure page loads attempt to use the document visible API whilst only
0.27%[5] actually use the offline cache.

Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
however we don’t have a distinct metric for the API usage.

The last blocker for a removal was usage of AppCache by some Microsoft
online products.  I’m enquiring into if this is still applicable and also
want to ensure with this rollout plan that we don’t break these when the
user has an online connection.

Implementation

Bug where the code will be implemented[7].

Plan

   -

   In Firefox 70, Remove the previous preference
   “browser.cache.offline.insecure.enable” and related code, forcing all of
   the APIs to only ever be available over Secure Contexts despite user
   choice. Due to the insecure nature of insecure context AppCache it is a
   good time now to remove this fully.


   -

   Create a new preference that disables only the storage and use of
   AppCache data whilst permitting access to the dom property
   window.applicationCache and the “OfflineResourceList” interface.
   -

  Disable access in Nighty and beta for 70 for two releases before
  disabling for all other releases in 72.
  -

  Once storage is disabled in all releases:
  -

 Disable the API access in Nightly and beta via the existing
 preference (browser.cache.offline.enable) in version 72.
 -

 Wait two releases and then disable in all releases in Firefox 74.


This staged removal of AppCache is to reduce the risk of web compatibility
issues of the API being accessible to page scripts. Despite the API
presence it won’t have any ability to use the cache. We may look into
shimming these APIs depending on how the rollout plan goes.

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

[2]
https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ

[3]
https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html


[4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248

[5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246

[6] https://mzl.la/2TKRbvA
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Soft code freeze for Firefox 70, Aug 26

[Liz Henry (:lizzard)]

Correction, avoid risky changes from Aug 26th to Sept 2.
Thanks to kwierso for pointing out my typo.

- Liz


On Wed, Aug 21, 2019 at 10:41 AM Liz Henry (:lizzard) 
wrote:

> Hi there,
>
> On August 26th, we will be merging Firefox 70 from mozilla-central to beta
> for the first time. In order to avoid invalidating the testing we get
> out of late Nightly and the early Developer Edition builds and to ensure
> that we can roll out Beta 70 to a wider audience with confidence, we'd
> like to ask that any risky changes be avoided from July 1st until after
> the version bump to 71 on Sept 2. Please also be mindful of any
> landings late this week or over the weekend as there will be very little
> buffer between the first merge and shipping the 70.0b1 builds.
>
> Some reminders for the soft code freeze period:
>
> Do:
> - Be ready to back out patches that cause crash spikes, new crashes,
> severe regressions
> - Monitor new regressions and escalate merge blockers
> - Support release management by prioritizing fixing of merge blockers
>
> Do Not:
> - Land a risky patch or a large patch
> - Land new features (that affects the current Nightly version) — be
> mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
> lead to unexpected CI results
> - Flip prefs that enable new Features that were untested in Nightly cycle
> - Plan to kick off new experiments that might impact a feature's merge
> readiness
>
> Please let us know if you have any questions/concerns.
>
> Thanks,
>
> Release Management Team
>
>
> --
> 
> Liz Henry (:lizzard)
> Firefox Release Manager
> lhe...@mozilla.com
>


-- 

Liz Henry (:lizzard)
Firefox Release Manager
lhe...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Soft code freeze for Firefox 70, Aug 26

[Liz Henry (:lizzard)]

Hi there,

On August 26th, we will be merging Firefox 70 from mozilla-central to beta
for the first time. In order to avoid invalidating the testing we get
out of late Nightly and the early Developer Edition builds and to ensure
that we can roll out Beta 70 to a wider audience with confidence, we'd
like to ask that any risky changes be avoided from July 1st until after
the version bump to 71 on Sept 2. Please also be mindful of any
landings late this week or over the weekend as there will be very little
buffer between the first merge and shipping the 70.0b1 builds.

Some reminders for the soft code freeze period:

Do:
- Be ready to back out patches that cause crash spikes, new crashes,
severe regressions
- Monitor new regressions and escalate merge blockers
- Support release management by prioritizing fixing of merge blockers

Do Not:
- Land a risky patch or a large patch
- Land new features (that affects the current Nightly version) — be
mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
lead to unexpected CI results
- Flip prefs that enable new Features that were untested in Nightly cycle
- Plan to kick off new experiments that might impact a feature's merge
readiness

Please let us know if you have any questions/concerns.

Thanks,

Release Management Team


-- 

Liz Henry (:lizzard)
Firefox Release Manager
lhe...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement- Double-keyed HTTP cache

[Sebastian Streich]

Intent to Implement- Double-keyed HTTP cache


Summary:

Currently Browsers are vulnerable to cache-timing attacks, commonly
referred to as XS Leaks attacks. Starting with Firefox 70 we want to
explore a double-keyed HTTP cache. Instead of solely using the origin of
the resource, we will double key the HTTP Cache using the top-level origin.
Using the top-level origin as the 2nd Key in the HTTP Cache allows to
counterfeit XS Leaks and eliminates the ability of checking cache contents
across Origins.

Bug:  Bugzilla 1536058


Standard: https://github.com/whatwg/fetch/issues/904

Platform coverage: all platforms

Estimated or target release: Firefox 70

Preference: The feature will be pref'd behind
“browser.cache.cache_isolation”

 and disabled by default.

Other browsers:

webkit: shipped

Chrome :
implementing

web-platform-tests: 

Secure contexts:  This feature isn’t restricted to Secure Contexts.
Estimated or target release: Firefox 70
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship New Certificate Viewer

[Danielle Leblanc-Cyr]

Hi everyone,

We’re Carolina and Danielle, two Outreachy interns who have been working
with the Security Engineering team. We’ve spent the past few months working
on porting over pieces of the Certainly Something
 web
extension (shout out to April for all of the work she put into it!), to
create a new certificate viewer. We’re now at the point where we’ve landed
most of our patches and the project is really coming together – we’re
hoping to soon replace the existing Firefox certificate viewer.

We’ve worked really hard the past few months – getting accustomed to the
Firefox codebase and workflow, learning about new tools, and creating as
many tests as we could think of. We really appreciate all of the people and
channels who’ve answered our (many) questions this summer, and who’ve
helped to steer us in the right direction - especially our mentors, Johann,
Dana and April.

The new implementation currently lives behind pref
"security.aboutcertificate.enabled", which bug 1572368 will default to
true. We’re hoping for this new certificate viewer to ride the trains in
Firefox 71.

The summer has flown by, but we’re excited to continue contributing to
Mozilla and to remain active members of this awesome community.

Thanks for all of the support!

This is the link to the web-extension which we used as a blueprint:
https://github.com/april/certainly-something

And here is all the development of the project:
https://bugzilla.mozilla.org/show_bug.cgi?id=1553524

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Eric Shepherd (Sheppy)]

I’m glad to hear it; the presence of the EV indicator often occupied so
much space that the URL bar would become practically unusable. Example
attached.


On August 12, 2019 at 4:05:09 AM, Johann Hofmann (jhofm...@mozilla.com)
wrote:

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.


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: Fission Newsletter #2

[Neha Kochar]

Fission functionality is not platform-restricted as of right now for all
desktop platforms (mobile not there yet). As Bobby said, WebRender
dependency is solely for the memory reduction goal.

-Neha.

On Fri, Aug 9, 2019 at 2:37 PM Bobby Holley  wrote:

> On Fri, Aug 9, 2019 at 11:11 AM Nika Layzell  wrote:
>
> > On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner <
> a.beingess...@gmail.com
> > >
> > wrote:
> >
> > > Is dogfoodability at all platform-specific for fission? i.e. is windows
> > > the only platform that is really actively developed/maintained? (as
> would
> > > make sense at this stage)
> > >
> >
> > The platform shouldn't have much impact, as we're generally working on
> > non-platform-specific functionality at this point. The most testing has
> > been done on Linux at this stage, though we're still very-much in early
> > days. I wouldn't recommend using fission for day-to-day browsing, as
> sites
> > with many cross-site iframes can be very slow to load and quite unstable.
> >
> >
> > > More concretely, I was under the impression that fission had webrender
> as
> > > a dependency, is that mandatory? Is it actually enforced by the fission
> > > pref? (webrender's support of different platforms has varying levels of
> > > quality, although it is generally dogfoodable on all major platforms)
> > >
> >
> > We don't have a hard webrender dependency, and the browser should work
> > mostly-the-same on all platforms. Some edge cases with mouse event
> > targeting may work better with webrender enabled.
> >
>
> I believe the primary issue is that we need WebRender to hit our Fission
> memory targets.
>
>
> >
> >
> > >
> > > On Fri, Aug 9, 2019 at 1:43 PM Nika Layzell 
> > wrote:
> > >
> > >> Looks like gmail chewed up the formatting :-S
> > >>
> > >> Published gdocs link:
> > >>
> > >>
> >
> https://docs.google.com/document/d/e/2PACX-1vTuGpZNthNxk0OYRyBjiHpaKnyKdmb9AompceuncvFmjeXB0bfk-L_LSlQmRaqiqx8vKif-LzdnE2F8/pub
> > >>
> > >>
> > >> On Fri, Aug 9, 2019 at 1:33 PM Nika Layzell 
> > wrote:
> > >>
> > >> > Hey all!
> > >> >
> > >> > It's been a while (7 months!) since the first Fission newsletter,
> but
> > >> > we've made some exciting progress we'd love to tell you about!
> > >> >
> > >> > Enabling Fission on Nightly
> > >> >
> > >> > It's now possible to turn on Fission in nightly builds of Firefox by
> > >> > setting fission.autostart pref to true. Fission can also be enabled
> > for
> > >> > running tests using mach test … --enable-fission.
> > >> >
> > >> > When Fission is enabled, each cross-site iframe is loaded in a
> > different
> > >> > content process, meaning lots of different processes participate in
> > >> drawing
> > >> > a single tab. The hover tooltip for a Fission-enabled tab is
> annotated
> > >> with
> > >> > a "[F …]" containing a series of process IDs, as shown in the image
> > >> below,
> > >> > serving as a visual verification of an active Fission-enabled
> session.
> > >> >
> > >> >
> > >> > We currently do not recommend trying to use Fission for day-to-day
> > >> > browsing, as there are still known stability issues. However, if you
> > do
> > >> try
> > >> > it out, please file bugs/issues blocking fission-dogfooding
> > >> > .
> > >> >
> > >> > Fission Mochitests on mozilla-central
> > >> >
> > >> > Fission Mochitests were recently enabled as tier-2 jobs on
> > >> mozilla-central.
> > >> > This will allow us to run tests with Fission enabled on
> > infrastructure,
> > >> and
> > >> > prevent landing new features or code which don't support Fission.
> > Tests
> > >> > which do not currently successfully pass are marked as fail-if =
> > Fission
> > >> > or skip-if = Fission.
> > >> >
> > >> > We'd love your help migrating tests to run with Fission enabled!
> Here
> > >> are
> > >> > a couple of handy tips for making your test Fission-compatible:
> > >> >
> > >> >1.
> > >> >
> > >> >Use SpecialPowers.spawn(target, [args…], async (args…) => { … }),
> > to
> > >> >run code in potentially cross-origin iframes, as they may be in a
> > >> different
> > >> >process. This API is similar to the ContentTask.spawn API used by
> > >> >browser-chrome mochitests.
> > >> >2.
> > >> >
> > >> >Wait for document loads to complete before trying to run code
> > inside
> > >> >the target window, as a process switch may occur after the frame
> or
> > >> browser
> > >> >is created. For frames in content, this usually means waiting for
> > the
> > >> >load event.
> > >> >
> > >> >
> > >> > These tests may also be run on the tryserver, however they are
> > currently
> > >> > excluded from the default set. They are called M-fis, and can be
> found
> > >> in ./mach
> > >> > try fuzzy --full.
> > >> >
> > >> > Fixing these Mochitests is a goal of our next major milestone, M4!
> > >> There's
> > >> > a ton of awesome stuff happening in M4, which you can read about on
> > the
> > >> > wiki