I am not confident that this will fix the underlying issue causing this crash,
but given how small of a change it is, I figure it's worth trying to land
quickly to see if the crash rate drops with it.
Differential Revision: https://phabricator.services.mozilla.com/D124503
Covers the case where we finish late because the callback took a long time,
and the case where we fired really late (eg; because of sleep).
Differential Revision: https://phabricator.services.mozilla.com/D123814
We could fix the testcase in this patch by promoting
`FlexLine::mTotalItemMBP` to `AuCoord64`, but then
`layout/generic/crashtests/1488762-1.html` will start crashing. It is
because `FlexItem::OuterMainSize()` can return negative size due to
integer overflow, and the negative sizes will accumulate in
`mTotalOuterHypotheticalMainSize`.
Instead of promoting more variables to `AuCoord64` to workaround huge
margin/border/padding that we cannot handle gracefully, this patch
tweaks the assertion to check only if `mTotalOuterHypotheticalMainSize`
and `mTotalItemMBP` have valid values.
Differential Revision: https://phabricator.services.mozilla.com/D124409
We had logic in both `mach_bootstrap` and the Mach Bootstrapper to
create the state_dir.
This joins them and has the added benefit of creating the state dir
earlier in the Mach lifecycle (as will be needed for early instantiation
of the Mach virtualenv).
Differential Revision: https://phabricator.services.mozilla.com/D120400
It was originally added to "create-mach-environment" because that would
eventually be called by "./mach bootstrap".
However, as "create-mach-environment" is going away, this moves it
closer to the command that it's meant to impact.
Differential Revision: https://phabricator.services.mozilla.com/D120399
Though it's acceptable for an optional dependency to not be installed,
it *is* a problem if it's installed to the wrong version.
Differential Revision: https://phabricator.services.mozilla.com/D122886
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
This required migrating several strings to Fluent, and the bulk of this patch
is those migrations. The rest of the items matched up with an entry in the app
menu, so those items were switched over to use the app menu strings.
Differential Revision: https://phabricator.services.mozilla.com/D124270
There can be a scenario where an initial cache is pushed to an accessible via an update and not an "initial" push that a doc load or a subtree show would give.
For example, an accessible might not have a name, description, or numeric value (that is all we currently cache), but then get a name later in its lifetime. If that is the case the accessible will get a cache AccAttributes with a DeleteEntry value for "description" since its description is still empty. That entry should not be stored in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D124484
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
There are two problems that this patch addresses:
1) The path to the VS solution file that we're using to launch it is malformed,
because os.path.join is using backslash seperators, but we're passing it a
path which already contains forward slash seperators, and mixing the two is
not valid. This is preventing VS from being launched at all.
2) We're throwing if explorer.exe does not return 0 when we call it to launch
VS, but explorer.exe always returns 1 when run this way, even if it
succeeded, so we output a spurious exception to the console.
Differential Revision: https://phabricator.services.mozilla.com/D124488
Rather than deleting the expected target directory of each package
that's being vendored, clear the whole `third_party/python` directory
and re-populate it from scratch.
As part of this, there's an "exclusion" list for packages that can't
be vendored from PyPI.
This has some benefits:
* It'll be harder to forget scraps of files and directories and leave
them in `third_party/python`.
* The exclusion list makes it more clear which packages are managed
manually, and the friction it adds to the workflow will guide
developers to use "requirements.in" instead.
The `test_up_to_date_vendor` test will verify that the vendor directory
is always clean.
Differential Revision: https://phabricator.services.mozilla.com/D123124
Note that, as part of adding this packages to the automated vendoring
system, some dependencies were automatically added - most notably,
dependencies of `taskcluster` that become visible with Python 3.6+.
Also, adds `**/.git` to the exclusions because:
* `.git` is part of our `.hgignore`, but
* `.git` is part of the `aiohttp` `tar.gz` file.
Since the file isn't needed for `pip install`-ing `aiohttp`,
and since we want `./mach vendor python` to be a no-op when there's
no requirement changes, we exclude it.
Differential Revision: https://phabricator.services.mozilla.com/D123122
Add pystache to vendor `requirements.in` so that it's vendored according
to `./mach vendor python` "ignore" rules.
This ensures that sufficient files are vendored such that installing the
package from it's `setup.py` file is possible.
Differential Revision: https://phabricator.services.mozilla.com/D122898
The existing version of `pyasn1-modules` (`0.1.5`) is incompatible with
our version of `pyasn1` (`0.4.8`).
By bumping `pyasn1-modules` to `0.2.8`, we now meet its compatibility
requirements.
Differential Revision: https://phabricator.services.mozilla.com/D122897