When first introduced, test-verify was only run when .js/.html/.xul/.xhtml files
were changed. Recently, it seems to run on every push. This is a speculative fix:
There may be confusion between "test-verify" and "test-verification" so I am
using "test-verify" consistently.
This adds a --verify flag that is compatible with other Mozilla test
harnesses i.e. it runs each test 10 times without restarting and then
runs it 5 times with restarts, and then repeats with chaos mode
enabled.
This uses the code from, and can replace, the |wpt run --stability|
flag from upstream although that has different default behaviour
(running 10 times with restarts). More work is needed to avoid
duplicating all the code, however.
MozReview-Commit-ID: 7oUEwJk7uhZ
While the crash reporter client is submitting a crash report, the report itself
stays in the crashes directory. We suspect that in some cases, if the browser starts
up while the crash reporter client is still sending the report, the unsubmitted
crash report handler will also attempt to send the same report.
This patch makes the unsubmitted crash report handler wait approximately 10 minutes
after the session starts before doing the unsubmitted crash report scan.
MozReview-Commit-ID: KkrPDa1Qwv1
--HG--
extra : rebase_source : cafecef5776a21a76c64300eb53fdde28e09d18b
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: J0MCc2V9hWT
--HG--
extra : rebase_source : 8617cfaa7391457867f01c1b619cb871a21bf3f5
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: GEZzCGbVqB1
--HG--
extra : rebase_source : dd4fab7f34da7c5465ba474db670cf583e8dadf4
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: GX2FX4YDusO
--HG--
extra : rebase_source : 06d7bae5cbae99d2987881f26f7ebd26965c1799
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 9jSBdZRIGuV
--HG--
extra : rebase_source : cd1b2f500e9a833f7d42bce53bdaec2118e0d4c3
Prevents crashes from improperly freed memory.
Fixes#19008, fixes#18950, fixes#18949.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19008.
- [x] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: e1dac69a4054f208accd18aa443cae19ec7eaf53
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 8e6b767fd6674558de1febd6cf5f907c18158669
Non unified telemetry needs "toolkit.telemetry.enabled" to be set to true
in order for Telemetry to be collected at all.
MozReview-Commit-ID: C7rdov3xFqs
--HG--
extra : rebase_source : 74d4b83ff4d16d2ff224dbe44c14cc867b5e9a64
In some circumstances it is possible to sample a timed element in the active
state with a time that precedes is current interval.
One possible sequence of steps leading to this situation is as follows:
1. A timed element (e.g. <set>, <animate>) with a non-zero begin time is the
child of <svg> element A (its "time container") but has yet to be sampled.
2. In order to resolve its initial interval, the timed element registers a
startup milestone with its time container at time 0.
3. However, before the sample is performed where the timed element's initial
current interval is resolved, <svg> element A is detached from the document
tree.
4. The timed element is then attached to a different <svg> element B that has
a current time greater than the begin time of the timed element and less than
that of <svg> element A.
5. Since the timed element is still in its startup state it registers its
startup milestone again, this time with its new time container, i.e. <svg>
element B.
6. A tick occurs or the document has its style flushed such that a sample is
performed.
This includes running the milestone sample which causes the timed element to
resolve its initial current interval. Furthermore the subsequent regular
sample of the timed element causes it to transition into its active state
because the current time of <svg> element B is greater than the begin time of
the timed element.
7. <svg> element A is re-attached to the document.
8. When we go to run the next sample, we iterate through all time containers
associated with the document's animation controller which includes both <svg>
element A, and <svg> element B.
9. <svg> element A renders up its 0 milestone from step (2) since it has yet to
run it. It converts this to parent time, i.e. the time space of the animation
controller, which will be zero or less depending on the current time of <svg>
element A when it was re-attached.
10. Since the milestone from <svg> element A will be the earliest milestone
time, it will be used as the next milestone sample time.
11. The timed element is then sampled using this time, but first it is converted
to a time in the time space of the timed element's time container, which is
now <svg> element B.
As a result of this conversion, the sample time may end up being *before*
the beginning of the timed element's current interval. Since timed elements
never expect the time to go backwards an assertion fails when it detects
that it is active, but is being sampled before its current interval.
For this particular case, ignoring the "early" sample seems to be the most
appropriate action.
More generally, however, we can anticipate other cases similar to this where
milestones are registered that cause the sample time to temporarily go
backwards. A quick audit of nsSMILTimedElement::DoSampleAt suggests that, with
the code changes from this patch, that is probably ok.
As an alternative we could, perhaps, try to drop and re-create all milestones
when time containers are re-attached to the document tree but that would add
more complexity and would not necessarily cover other similar cases of this
situation.
I have verified that the crashtest included in this changeset fails without the
code changes also in this changeset.
MozReview-Commit-ID: KKGYRayNkpo
--HG--
extra : rebase_source : 832d4b357a2a2fe07abf9eab3a6046599aff3ef5
Bug 1378258 removed malloc_print_stats and bug 1379890 further removed
the subsequently unused arena stats. It turns out there are also some
huge stats that have been unused since bug 1378258, and that are still
there, so remove them.
--HG--
extra : rebase_source : ae71c7507143503dff8d2e517352a97eb53e4676
Repack of the new Visual Studio release using the packaging
scripts from bug 1407678. This version also includes the
pgo runtime, resolving a performance regression from the
previous package.
MozReview-Commit-ID: LhoVyG4IwmP
--HG--
extra : rebase_source : 0d3d2f28f05335976d236e5f76893307c252dc96