<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#15449 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: b783cacc54e52c468c27fe946dd1909af4561e9f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2d2eeb7abf3e355e844b9f31d23536d151badca8
Previously, we operated under the understanding that with Flash blocking activated, non-whitelisted documents would be set to CTA. We are changing that such that now, documents will only be CTA'ed if Flash is set to "Ask to Activate".
Flash blocking will now behave according to the following chart:
User Setting Flash block Whitelisted sites Blacklisted sites Unlisted sites
"Never ..." Off Deny Deny Deny
"Ask ..." Off Ask Ask Ask
"Always ..." Off Allow Allow Allow
"Never ..." On Deny Deny Deny
"Ask ..." On Allow Deny Ask
"Always ..." On Allow Deny Allow
This patch also completely reworks the flash blocking testing. Test data and most code remains consolidated, but will be run in multiple different tests. This avoids having to extend the timeout for Flash block testing to an extremely long length. The new Flash block testing additionally tests each of the six cases (rows) in the table above.
MozReview-Commit-ID: 5aPGUEiUiCv
--HG--
extra : rebase_source : d5f5711855d108a9a33b9d28aae6e312cc9cb432
Since the Shumway project is dead, we no longer register a stream converter for flash files. We can remove this check, as it will always return false.
MozReview-Commit-ID: CzC7wYmWEFp
--HG--
extra : rebase_source : 24373bc48da66fccb616864a6f03a5fc5d57ba9c
We recently changed how image compression works (bug 1350447) and
upgraded to Mercurial 4.1.1 (this bug). It's time to roll a new
image_builder Docker image.
This commit updates the version and hash of the image. The image
is already pushed to Docker Hub/Cloud. We just need to whitelist
it and deploy this change.
MozReview-Commit-ID: KQwJZ2OSGlt
--HG--
extra : rebase_source : 23f2686cd85256178b5d89c452aaeabe4e4198db
We've been running Mercurial 3.9 in automation for a while. Mercurial
4.1 is out. It has the usual performance improvements and bug fixes,
making it an attractive upgrade. But what really makes it enticing
is support for zstandard compression over the wire protocol. This will
reduce server-side CPU load and make transfers between 4.1+ servers
faster.
So, let's upgrade to Mercurial 4.1.1.
The produced packages are built from the current tip of the
stable Mercurial branch, not exactly 4.1.1. Specifically, they
correspond to revision ed5b25874d99. I did this because there is
a patch in the stable branch that drastically improves performance
on repos with many heads. When 4.1.2 is released in a few days, we
can upgrade to it and do away with the one-off.
MozReview-Commit-ID: 6BPhVheHQXI
--HG--
extra : rebase_source : d72452708fa0397272b79247d9d4844b35e5ee26
A few commits ago, we bumped up the default zstandard compression level
from 3 to 10 when we switched to multi-threaded compression. Even with
multiple threads, this was a bit slower.
For images that will be built once and read multiple times, it is
worthwhile to burn extra CPU once and produce a small image. However,
for other tasks where the number of reads is limited, it isn't
worth it to use this extra CPU. This commit uses the SCM level as
a proxy for "optimize for speed." If the task is associated with level
1 (a try push), we lower the compression level and optimize for
speed. Otherwise, we keep the higher compression level and
optimize for image size.
Credit goes to Jonas for this terrific idea.
MozReview-Commit-ID: Hui97KsZpgw
--HG--
extra : rebase_source : 5a98e554166b51b8caa62b38d82e91c7b9fcb7ab
Using --no-install-recommends prevents installation of unwanted
packages and helps reduce image bloat. Using it in image_builder
reduces the image size from ~212.5 MB to ~203.6 MB. Not the
biggest savings. But savings nonetheless.
I kept python-pip separate because using --no-install-recommends with
it fails to pull in setuptools, gcc, and other packages required for
building Python packages. Since these packages are only needed
for generating the Docker image, I didn't feel like teasing out
the actual dependencies. It takes a little longer to install
temporary packages and build the image. But the end result should
mostly be the same.
MozReview-Commit-ID: EVURGKFuWzb
--HG--
extra : rebase_source : e1f953079480c6d898569dc7e14dc97890d4f41e
The goal of this change is to switch to python-zstandard for Docker
image compression so we can employ multi-threaded compression. This will
cut down the wall time it takes to compress images, decreasing end-to-end
times.
In order to use python-zstandard, I needed to write a Python script
for doing the compression. Since I was writing a Python script, I
figured I'd move Docker image downloading to that script as well.
This way, the raw Docker image never hits disk: it is streamed straight
from Docker into a zstandard compressor and that output is written to
disk. For large images, this will eliminate a few gigabytes of disk
writes.
The one extra complication about this I don't care for is you need a
special Python package to teach the "requests" package how to download
from UNIX domain sockets.
MozReview-Commit-ID: EufaRzR6A4Y
--HG--
extra : rebase_source : 2143bfee729bdc075c3a87a1e607eff2f0c164d2
Let's see if this makes the intermittent failure situation improve!
Source-Repo: https://github.com/servo/servo
Source-Revision: 3345b83fb370536a354ce82bb3493576f873d822
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 28e701d2b61b6e40a11cf781d2f5e105e069076a
During the test, we open a new window which loads a URL, and have code to wait for that
initial browser to complete the load. For the initial browser, there is (when we open
a remote-able URL), the remoteness of that initial browser flips from non-remote to
remote. Sometimes, due to messaging / timing, the initial browser will send a message
saying that a load completed for the initial about:blank before the URL we actually
want is loaded. This causes the test to continue, and attempt to click on an element
that isn't actually on the page yet.
This modification allows us to wait for the initial browser to actually load the page
that we care about before proceeding.
I also changed some of the assertion messages to actually reflect what's being asserted,
as opposed to reflecting what is being revealed if the assertion fails.
MozReview-Commit-ID: 608SaA1nCVs
--HG--
extra : rebase_source : 0662d166e10de5036c40b278554ff5b3dd11de04
extra : source : 4255a184eac6d037763deb9319df652abf5f703b
Update rust-build docker image source to v0.4.3. This includes
some recent to how verification and taskcluster work to maintain
working scripts, and some changes for the newer cargo-building-
cargo build system, which aren't sufficient for bootstrapping.
MozReview-Commit-ID: 4IdbKVvco8m
--HG--
extra : rebase_source : f3cd2b7e8429648072ac02df5e8d4659c675f2ae
Also implements :link, :visited, and :any-link more efficiently, and stops
matching :-moz-read-only in everything that is not read-write, which is kind of
dumb, and probably creates some artifacts.
MozReview-Commit-ID: 6BQqi7nAWdT
--HG--
extra : rebase_source : 39dc6b481b3a92942dc3732990d8b9040d8e6d84
