64-bit Windows builds that use clang-cl need -mssse3 specified, just
like the 32-bit builds.
MozReview-Commit-ID: KAYXYAAw46I
--HG--
extra : rebase_source : c882da5408c6e081b9564c859e73eccc5671287b
This one also probably wouldn't cause problems, but getting rid of the CPOW
was so easy, I did so anyway.
MozReview-Commit-ID: IWNwpKF52gI
--HG--
extra : rebase_source : 909cf7fb351f9a7d27e806616e48592f169dae12
This one isn't intermittent but I noticed it in the logs and it was free to
fix.
MozReview-Commit-ID: D56wiHn3IfL
--HG--
extra : rebase_source : d8078fc995249d39d6c0e838d394f1465a9a3684
This was a little tricky to get right. The "spin the event loop" bit is weird
but doing a setTimout to call resolve is already redundant since resolve calls
the promise callbacks on the next turn of the event loop anyway. Basically,
the test just needed to move more stuff to the content process.
MozReview-Commit-ID: KrZZU5reJf7
--HG--
extra : rebase_source : 0817cdefc2e3941a5f59e3e8365d72395d8c4869
As it turns out, the workaround used to detect "not activated" service worker registrations works only
in e10s pages. In non e10s, service worker registrations are returned even if they are not in activated
state. Here we add the currently associated worker to the registration info, which will be used
to determine if the service worker is activated by about debugging.
MozReview-Commit-ID: ImeZcXQdBtO
--HG--
extra : rebase_source : f7e023708f8954b978b189025fd0b06c587d6a8e
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
Add AndroidCompositorWidget to act as the intermediary between gfx code
and GeckoLayerClient, in place of AndroidBridge. AndroidCompositorWidget
currently inherits from InProcessCompositorWidget, but when Android
eventually supports OOP compositing, it will be made to inherit from
CompositorWidget directly.
This command is mostly just a wrapper around `cargo vendor`, but it runs
it the right way and will install the cargo-vendor tool if necessary.
Additionally, the mach command will by default error if there are uncommited
changes to files other than Cargo.{toml,lock} in your working copy, and it
will stage changes to the vendored crates in your VCS after the update.
MozReview-Commit-ID: 2fMDBawNUMO
--HG--
extra : rebase_source : fe72f26aec795eb663c554933432e700ac5089c3
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
Iterators shouldn't have methods like write(); if you need to write to
an iterator, that logic should be handled by something outside of the
iterator...which also explains why we have a specialization of
nsCharTraits<nsWritingIterator<T>>. The HTML parser wants this for its
own reasons, so we have to make sure it continues to work.