After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
`_install_pip_package()` may be run from `populate()`, which
is invoked from a child Python process that doesn't
have in-tree Python modules in its sys.path.
An alternate solution would be to add in-tree modules
to the sys.path, but that seemed more costly than
simply using `tempfile` and `shutil`.
Differential Revision: https://phabricator.services.mozilla.com/D119834
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
Now that the upstream Python bug has been resolved since Python 3.4 (at
the latest), we can safely remove the environment variable workaround.
Differential Revision: https://phabricator.services.mozilla.com/D119687
It's possible for a virtualenv to have an incorrect list of directories
to add to the sys.path, such as the following cases:
* Its creation got cancelled halfway through
* The list of pths changed in a new revision
* It got modified by an external tool
By validating the list of provided pths against the list of required
pths, we can ensure that the virtualenv is more dependably up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D119686
This simplifies consumer logic, since they get the parsed list of pypi
and pth requirements, as well as the list of input files that were
parsed.
One benefit of this simplification is that we no longer
recursively create VirtualenvManagers.
Note that mach_bootstrap cannot (yet) take advantage
of `ParseMachEnvRequirements` because of a dependency cycle:
* `mach_bootstrap` must set up the `sys.path` to import
`ParseMachEnvRequirements`.
* `mach_bootstrap` would want `ParseMachEnvRequirements` to
determine which paths to add to the `sys.path`.
Differential Revision: https://phabricator.services.mozilla.com/D119685
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
This patch adds a new GeckoView build variant dubbed "lite". We are in the
process of adding some optional dependencies to GeckoView that are needed by
Fenix (like Glean and Nimbus) which are likely not going to be used by anyone
else at Mozilla. To avoid bloating third party consumers, we provide a
geckoview-lite build that doesn't contain any optional dependency.
The min SDK version of GeckoView (non-lite) is being increased to 21 to match
Glean's min SDK. Given that Fenix's min SDK version is already 21 and that the
lite version's min SDK is still at 16 this change is safe to do and will not
incur in any loss of usability.
Differential Revision: https://phabricator.services.mozilla.com/D114370
The very first time an Android AVD starts it runs some one time jobs to
properly set up the AVD.
To avoid running the setup every time we run tests in automation, we can boot
the AVD before packaging it so that the testing jobs can use a "prewarmed" AVD
instead.
Differential Revision: https://phabricator.services.mozilla.com/D119225
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
`_install_pip_package()` may be run from `populate()`, which
is invoked from a child Python process that doesn't
have in-tree Python modules in its sys.path.
An alternate solution would be to add in-tree modules
to the sys.path, but that seemed more costly than
simply using `tempfile` and `shutil`.
Differential Revision: https://phabricator.services.mozilla.com/D119834
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
Now that the upstream Python bug has been resolved since Python 3.4 (at
the latest), we can safely remove the environment variable workaround.
Differential Revision: https://phabricator.services.mozilla.com/D119687
It's possible for a virtualenv to have an incorrect list of directories
to add to the sys.path, such as the following cases:
* Its creation got cancelled halfway through
* The list of pths changed in a new revision
* It got modified by an external tool
By validating the list of provided pths against the list of required
pths, we can ensure that the virtualenv is more dependably up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D119686
This simplifies consumer logic, since they get the parsed list of pypi
and pth requirements, as well as the list of input files that were
parsed.
One benefit of this simplification is that we no longer
recursively create VirtualenvManagers.
Note that mach_bootstrap cannot (yet) take advantage
of `ParseMachEnvRequirements` because of a dependency cycle:
* `mach_bootstrap` must set up the `sys.path` to import
`ParseMachEnvRequirements`.
* `mach_bootstrap` would want `ParseMachEnvRequirements` to
determine which paths to add to the `sys.path`.
Differential Revision: https://phabricator.services.mozilla.com/D119685
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
I'm not sure what information would be useful in other OSes, so ifdef
the row for GTK for now, but I made this trivial to show in Windows /
macOS / Android as soon as they return useful information.
Differential Revision: https://phabricator.services.mozilla.com/D120331
Automatic update from web-platform-tests
Fix nested inline box fragmentation
This patch fixes when nested inline boxes are fragmented in a
line due to bidi reordering.
Before this change, the fragmented boxes are appended to the
end of |box_data_list_|. Then when |NGInlineLayoutStateStack::
CreateBoxFragments| creates inline boxes in the ascending
order of |box_data_list_|, it failed to add the fragmented
boxes into their parent inline boxes.
This is critical for out-of-flow positioned objects whose
containing block is an inline box, because they expect to be
propagated through all ancestor inline boxes.
|UpdateBoxDataFragmentRange| is a little tricky by appending
to a vector it is iterating. Changing it to insert to the
correct position makes the function even trickier. This patch
changes it to add fragmented boxes to a separate vector, and
let later process |UpdateFragmentedBoxDataEdges| to merge the
vector to |box_data_list_|.
Bug: 1229999
Change-Id: I7edcd209e1fdac06bab01b16d660383e7e9c37bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3038308
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#903356}
--
wpt-commits: d11611524641c4ae3bfbdc549ded99f22578ef4a
wpt-pr: 29711
Automatic update from web-platform-tests
webcrypto: merge tentative BigInt test into main (#29713)
--
wpt-commits: cdd0f03df41b222aed098fbbb11c6a3cc500a86b
wpt-pr: 29713
Automatic update from web-platform-tests
WPT: Add a test for ignoring unrecognized members in a web app manifest
This behaviour is inferred from the spec text on "processing the
manifest": https://www.w3.org/TR/appmanifest/#processing
and clarified by the non-normative text on extensibility:
https://www.w3.org/TR/appmanifest/#extensibility
Added as a more general test for the same no-required-behaviour of the
new_note_url field.
Bug: 1185678
Change-Id: Ic760c9dd473d71833e31be2ccfbde95b9c7086f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3038042
Commit-Queue: Glen Robertson <glenrob@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#903346}
--
wpt-commits: 1ef33da4b7e03fc9f915701b3a4a6fef3e76c6ad
wpt-pr: 29702
