These are the Servo-side changes for [Bugzilla bug 1381389](https://bugzilla.mozilla.org/show_bug.cgi?id=1381389).
Source-Repo: https://github.com/servo/servo
Source-Revision: 513e6b297925387aa21d8382907d4b9283bf6c1e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f04cda9778e7ef619bfdff85b09bcb3fb6eefb2c
This was removed recently in the ComputedValues patch, and makes traversal
logging rather unusable.
Reviewed in https://bugzilla.mozilla.org/show_bug.cgi?id=1382357
Source-Repo: https://github.com/servo/servo
Source-Revision: 37d96f5ca9cf6df08dcb9a98455cbf297ec22cff
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ed1e3f1a7d8600447fc6a7c446812399752aef60
While decomposing a 3D matrix, we should normalize the 2nd row right after the
Y scale computation. However, we accidentally use the length of the 1st row to
do the normalization. This causes the wrong Scale3D function while decomposing,
and then leads to the wrong decomposed 3D matrix.
Here, we correct it by using the right value (the length of the 2nd row).
r=hiro https://bugzilla.mozilla.org/show_bug.cgi?id=1381196
Source-Repo: https://github.com/servo/servo
Source-Revision: a9b748f17a37bfbd8265f003ac6c240755b5a920
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 24b4878ac8430bbe87e3af64c6e8a2288a947b34
The issue here is that the DestroyFramesFor call does a ClearServoDataFromSubtree,
and then we subsequently fail to load the bindings, leaving ourselves with an unstyled
subtree that isn't marked with descendant bits and isn't rooted at a display:none element,
which is forbidden. This can trigger crashes when we call the innerText getter on one of
the unstyled elements, since that will first flush layout (which won't find the unstyled
subtree), and then invoke IsOrHasAncestorWithDisplayNone, which passes LazyComputeBehavior::Assert.
MozReview-Commit-ID: 7roBkH9fTGZ
There are a few places where we walk commit ancestry looking for things
attached to a specific revision. Because the repository name is attached
to the index path and because a revision can exist in multiple
repositories, we often have to perform N index lookups to find a result
for a specific revision. This is inefficient.
To facilitate faster index lookups by revision, we introduce a new route
that doesn't contain the repository name. In theory, we should be able
to do this globally - for all repos. However, the configuration of
tasks can vary significantly by repo. So e.g. a linux64 build on
"central" is sufficiently different from a linux64 build on "beta" or
"release." For that reason, this commit takes the conservative
approach and only defines a shared route for repositories with a similar
configuration: the "trunk" repositories.
MozReview-Commit-ID: 8rIgUbzW4eL
--HG--
extra : rebase_source : 301ed36424e0c69c25e63121809afb96ca327edc
extra : source : 543c503f745c89360398fd3207ddaea5c262a807
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
For reasons unknown to me, Windows CI is periodically failing to find
the Mercurial binary.
In addition, we've also reimplemented various VCS logic throughout
the build system. There is room to cut down on code complexity by
e.g. recording VCS info in configure instead of determining it
at run-time.
Also, for forensic purposes it is sometimes desirable to know which
VCS tool is in use by a build and which version of that tool is being
used.
This commit adds VCS type detection, binary searching, and version
resolution to configure.
substs now contains VCS_CHECKOUT_TYPE, HG, and GIT, which can be
consulted by downstream consumers.
If the Mercurial or Git versions could not be resolved, all variables
are not set. Otherwise, VCS_CHECKOUT_TYPE and one of HG or GIT is set.
If MOZ_AUTOMATION is set, we require that the VCS info be resolved.
This helps prevents weirdness in automation due to unexpected
environment configuration.
MozReview-Commit-ID: AMLy0Hfx5rD
--HG--
extra : rebase_source : edef9165d32dc47308a14b0fbabce3c1d3d28176
And include code to work around a bug on older Python versions.
MozReview-Commit-ID: 4pBnMQQJOGB
--HG--
extra : rebase_source : 6f7c5784230bd37b3496b9bb1781e8d342f741b4
We're about to make MOZ_AUTOMATION more strict about things like having
a source checkout.
The whole point of build-sm-package.sh is to verify that SpiderMonkey
can be built outside of Mozilla's source repo and automation from a
standalone package. Since the presence of MOZ_AUTOMATION can influence
so much behavior in the build system, unset it so that the job
tests a !Mozilla environment more accurately.
MozReview-Commit-ID: EMfyLKfY0uU
--HG--
extra : rebase_source : 3632a9abf9fac3f916ed9043f30d4b6aa4abb390
Avoid the confusing state of "Stylo: true (disabled by build)" by also checking
the build constant _and_ the pref / env var together.
MozReview-Commit-ID: jTK66cWcyv
--HG--
extra : rebase_source : 54e158ed4f3dbde27e410aa0a59fcac44c383db3
Bug 1381521 and bug 1380465 were opened to investigate and re-enable these tests.
MozReview-Commit-ID: KbiDfqfF0ht
--HG--
extra : rebase_source : c5479538c35a9698c214d463fb59d7ded4128e13
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
Previously we assumed count histograms were always present in payloads.
This was an erroneous assumption as count histograms were only 0 if they were
session histograms, or if they were from subsession histograms from subsessions
_after_ a subsession when they held a non-0 value.
So let's just treat count histograms as normal histograms from now on, without
any of this "sometimes 0" nonsense. This simplifies the code, tests, and our
understanding... and _should_ have few/zero downstream effects since the
existing behaviour was so poorly-understood (though exactly tested).
MozReview-Commit-ID: BH108ksygGw
TelemetrySession's getKeyedHistograms asks for each keyed histogram
individually. This is inefficient and doesn't work well with the storage
refactor.
So, plumb through a subsession keyed histogram snapshot API and convert
TelemetrySession over to using it.
MozReview-Commit-ID: Af9dTqw99UA
Previously we were doing bad string manipulation nonsense. Now when asked for
snapshots C++ can return a properly-formated Object tree.
MozReview-Commit-ID: HAvIbgzUvMU
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
- A histogram name identifies a set of histogram instances, for which storage and lookup will be handled in TelemetryHistogram.cpp.
So we remove the names from histogram code.
- Various unused macros in the header are removed.
- Remaining traces of StatisticsRecorder are removed from the Histogram class code.
- Some unused methods are dropped that were about printing histograms to ASCII etc.
MozReview-Commit-ID: BF2rLSpKOJ8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
This should be a straightforward performance improvement in pages with lots of CSS property values that the parser does not understand.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because there's no functional difference.
Source-Repo: https://github.com/servo/servo
Source-Revision: b70cbeb84caf5ec4a90a900fc5d4082989044acd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 18e9fcafa9b8e8137b3991331effc2a629ff3e88
There are some situations where spans are not properly synced from
current text to shadow text. This patch takes more steps to make sure
spans are synchronized.
MozReview-Commit-ID: 1xhsJllE7Ro
--HG--
extra : rebase_source : 743828adfe9dfda93480a5372697989a77492d52
`nsRange` registers mutation observers to adjust the range when content
changes. However, there are some cases where we adjust the start and/or
end offsets but don't notify selection listeners (i.e. we don't call
`nsRange::DoSetRange` to set the new range points, contrary to what the
comment above `nsRange::DoSetRange` says). This patch makes us call
`nsRange::DoSetRange` in those cases. The patch adds a testcase in
test_selectevents.html, and changes a few unexpected-pass cases in
test_composition_text_querycontent.xul that this patch fixed.
MozReview-Commit-ID: 73D8RYMS3MS
--HG--
extra : rebase_source : da0cc3073e4b8ad23c6f6eab42da5aa8b269cae9
When the start node is a non-container node (i.e. <br>), and the start
offset is 0, we should not include a newline character for the node. For
example, for this range,
> <br/>hello
> \___/
the start node/offset is (<br/>, 0) and end node/offset is ("hello", 1).
The calculated range offset should be 0, and the range length should be
2: 1 for the <br/> newline character plus 1 for "h".
The patch also ensures this behavior for pre-mode nsContentIterator, for
both start and end node adjustments. For start nodes, we include any
non-container nodes with offset 0 in the range. For end node, we exclude
any non-container nodes with offset 0 from the range.
MozReview-Commit-ID: Lt2tCLbapq7
--HG--
extra : rebase_source : 7d86b6cf04581f1cd71fa85f8c8586541b3a84e9
Brian Birtles
Swapnesh Kumar Sahoo
Manish Goregaokar
Bobby Holley
Jeremy Chen
gasolin
Gregory Szorc
Chenxia Liu
jwu
Edouard Oger
Chih-Yi Leu
J. Ryan Stinnett
Mike Conley
Isaac Schemm
Ehsan Akhgari
Wes Kocher
Chris H-C
Georg Fritzsche
Aaron Klotz
Josh Matthews
Jim Chen
ffxbld