In Stylo, if there exists one or more <script> elements in the document, frame
construction might happen earlier than the UpdateCharSet(), which leads to an
incorrect style data for the frames. So, we force a restyle in this situation,
to make the style data of all the descendants up-to-date.
MozReview-Commit-ID: BwCwp6Ndvmc
--HG--
extra : rebase_source : 0cfadd3d57b4f8482251f8006a51740873cda3b9
In Stylo, we read font related user prefs to set the default font size only
if we set 'font-size' property. However, users are allowed to set their
preferred minimum font size through the user prefs, even without using
'font-size' property.
Gecko used to do this in nsRuleNode::SetDefaultOnRoot, which calles the
default constructor of nsStyleFont and does the minimum font size applying
right after. Moving the minimum font size applying into the default
constructor of nsStyleFont shoud be no harm to Gecko, but makes Stylo
share the same code path and behave the same.
MozReview-Commit-ID: BDcJX92o0uR
--HG--
extra : rebase_source : 88d9c73d0eb793ffe8a5dc424361f21f6acd078b
This is meant as a stop-gap measure to stop the obviously bad thing from happening.
MozReview-Commit-ID: Gqvc32K04xD
--HG--
extra : rebase_source : 04f1b5cb7ead6b7949b8433b3fc75c0d67283315
Bug 1354020 causes that IMM-IME on Windows 7 doesn't work with --no-remote. Although I think that this issue is OS or IME bug, when default window proceduce by RegisterClass is DefaultWindowProcW, Google Japanese IME doesn't work.
I am not sure why this issue occurs when lpfnWndProc is DefWidnowProcW and DDE isn't started. But for workaround, we should revert a part of bug 1354020 changes.
MozReview-Commit-ID: BkxlZnm8mIh
--HG--
extra : rebase_source : 21c1d86fb5628dbd726a15e5057a536271cfb26d
The UID and GID that a task executes under is dynamic. As a result,
caches need to be aware of the UID and GID that owns files otherwise
subsequent tasks could run into permission denied errors. This is
why `run-task --chown-recursive` exists. By recursively changing
ownership of persisted files, we ensure the current task is able
to read and write all existing files.
When you take a step back, you realize that chowning of cached
files is an expensive workaround. Yes, this results in cache hits.
But the cost is you potentially have to perform hundreds of thousands
of I/O system calls to mass chown. The ideal situation is that
UID/GID is consistent across tasks on any given cache and
potentially expensive permissions setting can be avoided. So, that's
what this commit does.
We add the task's UID and GID to run-task's requirements. When we
first see a cache, we record a UID and GID with it and chown the
empty cache directory to that UID and GID. Subsequent tasks using
this cache *must* use the same UID and GID or else run-task will
fail.
Since run-task now guarantees that all cache consumers use the same
UID and GID, we can avoid a potentially expensive recursive chown.
But there is an exception. In untrusted environments (namely Try),
we recursively chown existing caches if there is a uid/gid mismatch.
We do this because Try is a sandbox and any random task could
experiment with a non-standard uid/gid. That populated cache would
"poison" the cache for the next caller. Or vice-versa. It would be
annoying if caches were randomly poisoned due to Try pushes that
didn't realize there was a UID/GID mismatch. We could outlaw "bad"
UID and GIDs. But that makes the barrier to testing things on Try
harder. So, we go with the flow and recursively chown caches in
this scenario.
This change will shine light on all tasks using inconsistent UID
and GID values on the same cache. Bustage is anticipated.
Unfortunately, we can't easily know what will break. So it will be
one of those things where we will have to fix problems as they arise.
Fortunately, because caches are now tied to the content of run-task,
we only need to back out this change and tasks should revert to caches
without UID and GID pinning requirements and everything will work
again.
MozReview-Commit-ID: 2ka4rOnnXIp
--HG--
extra : rebase_source : ccb2b0a9230694f989775b26d5276fd3ac928af3
extra : source : 083d2e1cc8fe44b04e44f74bda3dd8bc75ba826c
run-task's --chown and --chown-recursive are only used on volumes and
caches - the only locations that aren't controlled by the Docker image
itself and thus whose permissions could be "undefined."
Previous commits have taught run-task about the locations of all caches
and volumes. Therefore, we no longer need to manually define paths to
chown. Instead, we can chown as a side-effect of the path being a
cache or a volume.
So, this commit changes run-task to chown caches and volumes
automatically. Since we no longer have a use for --chown and
--chown-recursive, those arguments are removed.
There /could/ be some paths that are caches or volumes but aren't
getting defined as such in Taskgraph. I consider this a bug in
Taskgraph and the recourse is to properly define a path as a cache or
a volume there.
MozReview-Commit-ID: 1yqrhjil6gy
--HG--
extra : rebase_source : 82c9ccb33f09d3ce50a6b7c6021e1e5b77d1b738
We recently introduced support for telling run-task about caches so
it could sanitize them automatically. We also recently taught
docker-worker and docker-engine how to declare volumes.
Building on that work, we now pass a list of paths corresponding
to Docker volumes to run-task.
run-task now verifies volumes behave as expected. Unless the volume
paths correspond to caches, run-task verifies they are empty and chowns
them to an appropriate owner.
Requiring empty volumes is an arbitrary decision. But as the inline
comment says, it keeps things simpler and makes caches and volumes
behave more like each other.
MozReview-Commit-ID: 5lm2uIitrS3
--HG--
extra : rebase_source : abb0be1a36f24d8d818515885dd2a75d13aed48a
We're about to ban files in Docker volumes so they behave almost
identically to caches (which start empty).
We move the install of nexus.xml from Docker image time to
task time. This also means that changes to nexus.xml don't result
in having to rebuild the Docker image.
MozReview-Commit-ID: JIjeJN4mt2
--HG--
rename : taskcluster/docker/android-gradle-build/nexus.xml => taskcluster/scripts/builder/build-android-dependencies/nexus.xml
extra : rebase_source : 53848f06820bda7979b2ae15456e07f8aed2363d
See the inline comment for the rationale here.
This check may not catch all volumes and caches. But after subsequent
commits refactor how permissions for caches and volumes are handled,
this edge case will likely result in permissions errors in the task,
so it isn't worth worrying about.
Several Dockerfile have been updated to add missing VOLUME so the check
passes.
In the case of desktop1604-test, we stopped removing
/home/worker/.cache because you can't remove a mount point, which is
what volumes are inside Docker containers.
MozReview-Commit-ID: GEyNkkX00kN
--HG--
extra : rebase_source : 19b3165d8c6e4431aa43dca51828be255e82e34f
Docker volumes are host-mounted filesystems. We typically mount
caches at their location. But not always. The reason we define
VOLUME in Dockerfiles is we're guaranteed to get a fast host
filesystem instead of AUFS when a cache isn't mounted.
In this commit, we teach the docker-worker payload builder about
the existence of Docker volumes. Docker volumes can be declared
inline in the YAML. More conveniently, we automatically parse out
VOLUME lines from corresponding in-tree Dockerfile.
We'll do useful things with this data in subsequent commits.
MozReview-Commit-ID: BNxp8EDEYw
--HG--
extra : rebase_source : 1aa6dbb000386cd2789d526708ce369640d532c9
Previously, we conditionally added caches to a task if the current
parameters warranted it.
In order to audit that all caches fulfill basic requirements, we need
to have unconditional knowledge of all caches.
This commit introduces an optional key on each cache entry stating
whether it should be skipped in "untrusted" environments. When we
convert a task definition to a worker payload, we filter out these
caches if necessary.
This change uncovered an inconsistency with filtering caches. In
one location we filtered on the source repo name. In others, we
filtered on the SCM level.
Setting the caches in the spidermonkey kind also changed slightly
to ensure we're not overwriting existing caches. I don't think this
has any behavior changes. But the new method is more correct.
MozReview-Commit-ID: 1crpdWHqQ68
--HG--
extra : rebase_source : 69469014dcc92d4de98d5e887b10542af00e05be
~ in paths is mostly a shell-ism. Let's not use it.
The real reason for this is it interfes with upcoming commits that
audit cache and volume paths.
MozReview-Commit-ID: AhjMwg5gexx
--HG--
extra : rebase_source : dd997a5d9c1123beecaa14bc5458a9338b3e07db
Static analysis in my editor was complaining about the old pattern.
Why not fix it while I'm here.
MozReview-Commit-ID: HtrGenolNXb
--HG--
extra : rebase_source : e3ffc4f7961dfd90767b6d1af2b93ad7551de3be
<!-- Please describe your changes on the following line: -->
Automatically verify that derive() lists are alphabetically ordered #18172
---
<!-- 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#18172 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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: 474369618965569407d127b1e8c481e757cc59d3
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 421aa68def8e17f70580477a4203494db3b69382
activity_stream_dismiss was being used to dismiss the welcome screen before but
this string is intended to be used in a different location for a different
purpose and thus should never have been set to the same string.
It's necessary to change the String here so we can modify the contents of the
activity_stream_dismiss String.
MozReview-Commit-ID: 87zaHQ5TJjN
--HG--
extra : rebase_source : c20167ccb9cdba1350b81094cb1a4ffea7b842a9
The menu button is hard to find so we decided to add support for long-click on
the whole row, which is consistent with top sites.
MozReview-Commit-ID: 1Wqa5r9ezWU
--HG--
extra : rebase_source : 88236273f6e1d26c6e6ef770b281f814f9c0b66e
If AddMediaElementToURITable() is called after the decoder Load failed, mDecoder
will be reset and it is sufficient to assert mDecoder only.
MozReview-Commit-ID: 58WT8zFeiFj
--HG--
extra : rebase_source : 712579b544e9a9ce971778b85795d06e58bd4ea5
extra : intermediate-source : 470e2d8a20010e11d7a7dce5540957e89439811e
extra : source : 59f4b2b33212794aa1cf3e8782737a2d4af8c241
As part of the normalization process for WebExtension API calls, we need to
extract and validate the full set of value properties (including properties
X-rays would normally deny access to) from cross-compartment objects. This
currently involves waiving X-rays, enumerating property descriptors, and
unwaiving X-rays - all through X-ray wrappers and waivers - and generating a
lot of expensive and short-lived wrappers in-between.
This helper reads out the list of safe properties from within the object's
compartment, and then copies them over to an object in the target compartment,
without any X-ray overhead, or any unnecessary intermediate wrappers or
compartment switches. It cuts about 40% off the overhead of our normalization
code.
MozReview-Commit-ID: H582oAYocaX
--HG--
extra : rebase_source : 7f7d5df605bc6544cb7f1c0c7e224d81b211e09c
extra : histedit_source : f980a03413b5e65fc6fa272c012a769d2764d89b
Like part a, but for `choices` messages rather than error messages.
MozReview-Commit-ID: 7dJ0NL2fUh5
--HG--
extra : rebase_source : 477f1364c0904bde78d54eae083bdb8e49ee5732
extra : histedit_source : 38c336b3a59481b6f2523798367159fb757c6485
For choices types, when one choice fails, we don't need the original error
string, since another choice may succeed, and we generate the final error
based on all of the options. Nevertheless, we spend a lot of time generating
JSON strings for the failed inputs in those cases, which adds up to about 12%
of the remaining overhead at this point.
MozReview-Commit-ID: 6nXBAv2W20V
--HG--
extra : rebase_source : 5894bc4b9e8d64ac9505f27240ea4fabfcb5f02f
extra : histedit_source : 0e8b5e0315abd672a57a60420453a1e0681c9df6
The Array and ArrayBuffer type checks we do in getBaseType add up to a
significant amount of overhead given the number of times we call them,
especially when X-ray overhead comes into play. These changes allow us to
avoid X-ray overhead altogether.
MozReview-Commit-ID: KlRuxeElIfp
--HG--
extra : rebase_source : c7f00fb8c35965476e7c7b888b6af36714c1323f
extra : histedit_source : fc559e665e60e9bbb688eebe6c6e6da5dacec748
In the code that I'm profiling, the XPC WrappedNative overhead of calling
these functions adds up to about a quarter of the time spent executing the
code. The overhead of the WebIDL versions is negligible.
MozReview-Commit-ID: 30qJy5RtP9d
--HG--
extra : rebase_source : 4fe73f4b9bde052a0eadf7d5634f792e16ca1c94
extra : histedit_source : ec61152a0181f3b0e28023c951e7181c43216d2f
Jeremy Chen
Grigory Kruglov
Drew Willcoxon
Brian Grinstead
Wes Kocher
Oriol Brufau
Dão Gottwald
Jonathan Kingston
Mike Hommey
Makoto Kato
Ed Lee
Gregory Szorc
Clément DAVID
Michael Comella
JW Wang
Tom Prince
Jed Davis
Michael Layzell
Kris Maglione
Christoph Kerschbaumer
Alexander Surkov
"dragan.mladjenovic"