Vendoring wheels has three benefits:
* There's far less files, so Firefox checkouts will be smaller.
* It works around `zipp` not allowing `pip install`
from extracted source `tar.gz` files. Now, we should
be able to use the pip resolver against vendored
packages, which will be needed for future
mach virtualenv work.
* `./mach vendor python` takes far less time to execute.
Since we need the raw Python to be available to add to the `sys.path`,
we extract the wheels before putting them in tree.
Due to the structure of some wheels being less nested
than of a source `tar.gz`, `common_virtualenv_packages`
needed to be adjusted accordingly.
`install_pip_package()` had to be tweaked as well since you can't
`pip install` an extracted wheel. So, we "re-bundle" the wheel
before installing from a vendored package.
Replace python packages with wheels where possible
This contains the vendoring changes caused by the
last patch.
For reviewing, there's a couple things to note:
* A bunch of files are deleted, since there's generally
less files in a wheel than in a source archive.
* There's a new `.dist-info` directory for each
extracted wheel, so expect roughly 5 or
6 new files for each wheel'd package.
* There should be no source code changes other than
moves from package names changing from having
`-` to having `_`.
Differential Revision: https://phabricator.services.mozilla.com/D116512
When the default and user branch values of a preference match, the user brach
value is effectively erased, and we keep no evidence that the user made a
choice. This changes makes normandy avoid that situation, so that user
preferences remain intact.
Differential Revision: https://phabricator.services.mozilla.com/D117949
Currently we prevent partial picture cache tile invalidation on all
Mali devices to workaround a driver bug. (See bug 1663355 and bug
1691955.) This driver bug affects some Mali-G and Mali-T devices, but
currently we apply the workaround for any Mali GPU.
Mali-400 may or may not be affected by the same driver bug, but since
it uses software webrender we certainly do not need to apply this
workaround.
Allowing partial invalidation should allow for smaller texture uploads.
Differential Revision: https://phabricator.services.mozilla.com/D118017
Calls to targetFront.isTopLevel can happen after a given target is destroyed, and
in such case `getTrait` was throwing as the `client` property of the target is nullified.
To fix this, we're directly checking if the targetForm has a `isTopLevelTarget`,
and if not, we default to the property we set in `setTargetType`.
Another issue was caused by the `_url` property, used in the `url` getter,
being nullified when in TargetMixin#destroy, which was making the WorkerDescriptor#name
to throw.
We now check that the url isn't null before trying to use it.
Differential Revision: https://phabricator.services.mozilla.com/D117011
- Don't throw when a placeable is enclosed in double straight quotes
- Catch single quotes used as genitive on plural nouns
Differential Revision: https://phabricator.services.mozilla.com/D117898
We always support these functions, so no need to use dlsym. The csd type
technically depends on the theme I think, so caching it globally is
wrong. Instead compute it once and pass it down to the two callers that
care about it.
Differential Revision: https://phabricator.services.mozilla.com/D117722
As pointed out by Harry, this will help in the short-term with
onboarding new developers who will be using M1 macs.
Note that this patch doesn't leverage the "instance" classes to define
whether they're artifact-mode compatible or not, and that's because:
* Most (all except one?) of the systems support artifact mode, therefore
* Since this is a temporary workaround, it's more deletable to have
a top-level `if/else` than to add a `supports_artifact_mode` property
to each Bootstrapper.
Differential Revision: https://phabricator.services.mozilla.com/D117946
SliceBugdet::step asserts that its argument is non-zero. Usually this is a
constant that is directly passed in, but in ParallelWorker it comes from a
function that returns some estimate of the work done. The problem is that in
this case we sweep an empty hash map the estimated work returned is zero.
The fix is just to ensure that we pass at least one as the steps.
Differential Revision: https://phabricator.services.mozilla.com/D118007
If we're destroying the frame loader of a replaced browsing context we'll end up
firing browser-shutdown-tabstate-updated for a tab that wasn't actually closed.
This results in us cleaning up Session Store state earlier than expected, which
means we drop future updates to SessionStoreInternal._closedTabs.
Fixes browser_sessionHistory.js, browser_async_remove_tab.js, and possibly
browser_491168.js for SHIP+BFCache.
Differential Revision: https://phabricator.services.mozilla.com/D117944
When middle mouse paste is enabled and middle click occurs in an editable
content or it's in a document whose `designMode` is `on`, we shouldn't start
the autoscrolling because the click must be intended for pasting clipboard
content or primary selection to the position.
Differential Revision: https://phabricator.services.mozilla.com/D117987
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
This patch makes the inspector use the new reflow resource instead of directly
handling a reflow front. This allows the grid inspector to update the list of
grids to include remote documents.
The grid inspector was also keeping references of layout fronts which was causing
issues with target switching.
A new test is added to ensure these different cases are now working properly.
Differential Revision: https://phabricator.services.mozilla.com/D117900
`nsIDocumentEncoder.OutputRaw` was misspelled as `nsIDocumentEncoder.OutRaw`.
Then, I investigate the expected result more. Then, I see that when only this
flag is set, any markups should be ignored except `<br>`. Therefore, I modified
the 2 test results which check `<p>`, `<div>` and `<br>` elements.
Differential Revision: https://phabricator.services.mozilla.com/D117966
As it's done on windows, preload libmozavcodec.so and libmozavutil.so
before sandboxing, this way this allows for a tighter sandboxing
(no filesystem access but /tmp for shm files, no prot_exec pledge..)
Depends on D116634
Differential Revision: https://phabricator.services.mozilla.com/D116635
The update to use the new UTS 35 locale canonicalisation algorithm (bug 1686052)
fixed this (spec) bug, so we just need to add the regression test and no further
code changes are necessary.
Differential Revision: https://phabricator.services.mozilla.com/D116986
We're using the will-navigate element as it fires very early
and we want to get rid of any data stored for the document
we're navigating away from.
Differential Revision: https://phabricator.services.mozilla.com/D117648
The values in ScaleOffset keys for the spatial node comparer can
often have very small differences that are causing invalidations but
are not going to affect the rendered content in any noticeable way.
This is _probably_ mostly due to inaccuracies in the way we calculate
the results in get_relative_transform. Instead of using the fast
form parent.inverse().accumulate(child), we could instead traverse
the tree from the parent, accumulating the local transforms. This
would be slightly less efficient but could probably be cached.
There may also be other sources of floating point inaccuracy that
is introduced in the calculations, so for now we will ignore any changes
which have a scale/translation change of < 0.001.
Differential Revision: https://phabricator.services.mozilla.com/D117968