The selectorText test happens to pass right now because well, we don't implement
the setter yet[1], but would fail if we implemented an specific invalidation in
the way I'd have done it yesterday.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=37468
MozReview-Commit-ID: DrMTgLzQcnk
Otherwise removal of stylesheets may get out of sync with other DOM changes, and
we may fail to invalidate the style of the affected elements.
Bug: 1432850
Reviewed-by: bz
MozReview-Commit-ID: DrMTgLzQcnk
Source-Repo: https://github.com/servo/servo
Source-Revision: bc7dd644f6f50bd6eb3fba1547808775ee9d7620
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a906350d0b2590d4634b95ddccb3a8294ec1cbfe
So far, the best we've been able to do is to upload an image to the
docker hub, and point an image's Dockerfile's FROM to the version
uploaded onto the hub.
That is a cumbersome process, and makes the use of "layered" docker
images painful.
This change allows to declare a parent docker image in the
taskcluster/ci/docker-image/kind.yml definitions, which will be
automatically loaded before building the image. The Dockerfile can then
reference the image, using the DOCKER_IMAGE_PARENT argument, which will
contain the full image name:tag.
Some details are left off, for now, such as VOLUMEs. At this point,
VOLUMEs should all be defined in leaf docker images.
--HG--
extra : rebase_source : 221cff0ca5a91d694ff5c3626fe707c15ba45e23
Now that `mach taskcluster-build-image` can, we can avoid all the manual
handling based on curl and jq in the image builder.
An additional advantage on relying on `mach taskcluster-build-image`
doing more is that less changes to the build-image.sh script will be
necessary, and thus less updates of the image builder docker image.
--HG--
extra : rebase_source : dd174d60675e41e4391894f28235c674c1840829
This allows to avoid writing out a tar file to then extract it to feed
it to `docker build`. This is essentially what the image-builder docker
image does, except it uses a temporary file for the tar.
--HG--
extra : rebase_source : 8275d737e02714fc198d3ba3d3e62e3f18d8e0bf
While spawning `docker load` is likely to work on developer machines,
on automation, it requires a docker client that is the exact same
version as the server running on the taskcluster worker for
docker-in-docker, which is not convenient. The API required for `docker
load` is rather simple, though, and can be mimicked quite easily.
While this change in itself is not necessary for developer machines,
it will allow to re-use the same command for the image-builder to
load a parent docker images when deriving one from another. We could
keep a code branch using `docker load` but it seems wasteful to maintain
two branches when one can work for both use cases.
--HG--
extra : rebase_source : d72956d7dd329b92564cbaa3fbfe0687d4d5d994
The zstd command we spawn, if available at all, might be the wrong
version: zstd changed its stream format in an incompatible way at some
point, and the version shipped in e.g. Ubuntu 16.04 uses the old format,
while the version taskcluster relies on uses the new format.
Relying on gps's zstandard library allows to ensure we use the right
version. Another advantage is that we can trivially pip install it in a
virtualenv if it isn't available on the system running the command.
If we're ridding ourselves of the subprocess spawning for zstd, we might
as well cover curl as well. Especially considering the error handling
when subprocesses are involved is not trivial, such that the current
error handling code is actually broken and leads to dead-lock
conditions, when, for example, curl is still waiting for the python side
to read data, but the python side is not reading data anymore because
an exception was thrown in the tar reading loop.
--HG--
extra : rebase_source : 054c37cfaa68bf475b37545ebaa99144584b93d4
The used pattern:
except Exception:
error = sys.exc_info()[0]
finally:
...
if error:
raise error
actually loses everything that is interesting about the original
exception. Not catching the exception just makes it thrown up the stack,
except when a different exception is thrown from the finally block,
which is what that if error: raise error is attempting to do... except
it doesn't throw the original exception, but its type only.
--HG--
extra : rebase_source : 17601fcc90fcdfefd93c4267f3cd33425d5326fd
Now that we don't need to read the contents of a file to hash the
contents of a docker image context, we can avoid creating a file
in generate_context_hash.
--HG--
extra : rebase_source : 98abe9bfdc48b612a3d251296991d0f769b449fd
This will allow us, down the line, to avoid creating a file at all in
some cases.
--HG--
extra : rebase_source : e4ea40341836cf24aa6d61c905b2efa660ee13f2
Our Web Worker code uses a thread pool where a single OS thread can be reused
for different worker scripts during its lifetime. Before this patch, we only
registered these threads with the profiler for the duration that they're
running a worker script. So the same OS thread could be registered with the
profiler during multiple disjoint time ranges, and we would expect the profiler
to treat those different registrations as different conceptual threads.
This had multiple advantages:
- The "thread name" of the conceptual thread can include the script URL:
"DOM Worker <scriptURL>". This allowed you to create thread filter which
match a part of the URL, so you had the option of profiling just the worker
threads you were interested in.
- We wouldn't waste time sampling a worker thread while it's idle and has no
script.
But it also had disadvantages:
- The profiler platform doesn't actually know how to deal with different
"conceptual threads" that share the same OS thread. This lead to surprising
breakage in different places. For example, the contents in the profiler
buffer are marked with ThreadId entries which use the OS thread id.
- What we show in the profiler UI didn't not match reality, and might be
confusing to some people.
I don't think the advantages are large enough to warrant teaching the rest of
the profiler platform to deal with conceptual threads. So this change makes us
stop doing the special thing and just register the OS threads for their entire
duration.
MozReview-Commit-ID: 82RtlRlwy3Y
--HG--
extra : rebase_source : 101e144f17718ea8f05e8bef8200b8ed41ee854e
