StreamingLexer::Clone should always succeed because we are merely
creating a new SourceBufferIterator which is at the same position as the
given iterator. However it is possible if there is no more data after,
the current position, it could return COMPLETE instead of READY.
This should not happen during the first Advance loop however. We handle
the failure gracefully now, and if someone files a report with the
invalid ICO file causing this problem, then we can investigate further.
These tests pass when our test infrastruction is in PDT, but there are
underlying issues. Disable tests on Windows for now to allow migrating
tests to TaskCluster.
MozReview-Commit-ID: 5HigFMyyaP5
HangAnnotations was very complex, required a separate allocation, and used this
unfortunate virtual interface implementation which made it harder to do
interesting things with it (such as serialize it over IPC).
This new implementation is much simpler and more concrete, making
HangAnnotations simply be a nsTArray<Annotation>. This also simplifies some of
the IPC code which was added in part 7.
MozReview-Commit-ID: EzaaxdHpW1t
These changes are going to increase the amount of data which we collect from BHR
a lot. It would be dangerous to run it on beta, especially considering how soon
the next merge is.
This should turn it off for 100% of beta users if I understand the logic
correctly.
MozReview-Commit-ID: 3HyEKWdXaqU
BHRTelemetryService only runs in the parent process (and we can only submit
pings from there), so we need to send the data which we collect in the GPU and
Content processes over IPC to the parent process.
MozReview-Commit-ID: 8B5uZKbjNbU
This patch adds the BHRTelemetryService which is a JS implemented XPCOM service
that simply listens to the bhr-thread-hang observer notification, and uses the
data it collects from it to submit telemetry pings.
MozReview-Commit-ID: 2hPXAFmHrm5
We're going to use HangDetails as the type containing hang information. We'll
have a JS component which reads the data out of nsIHangDetails, builds the
payload, and submits it to telemetry for us.
We'll do it in JS because telemetry has to be submitted from JS.
This patch also adds IPC serization for the relevant types so that we can send
HangDetails objects over IPDL.
MozReview-Commit-ID: CeikKabY9Vs
A new test using the new APIs is introduced in a later part. This test no longer
functions as ThreadHangStats is no longer present.
MozReview-Commit-ID: HKmoP2An4GP
These will be used to implement IPC serialization and deserialization of the
HangDetails object to send over IPC. This is a temporary measure as
HangAnnotations is rewritten in part 11.
MozReview-Commit-ID: 1WHNvhDrMF5
This is the first part of purging the existing telemetry code for
ThreadHangStats from the tree. All of these features will be replaced with new
code for BHR telemetry in the future.
MozReview-Commit-ID: BhD5zY2LwUR
Currently Gecko treats 'auto' component value as zero for animation.
MozReview-Commit-ID: JBvTFzDw7Xy
--HG--
extra : rebase_source : 618e756bbbb66759eea50a8004740e737f8a94e1
Currently Gecko treats 'auto' component value as zero for animation.
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1387951
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: e0b834033d857b08985fc84e676fac636a8495dc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c4ba04702afbd72d77f23c1b8163d26998daefb7
Web contetnt processes only need access to a small amount of schema data, but
we currently send them the approximately 600K of full schema data that is
mostly useless to them.
This patch limits the schema data sent to web content processes to what they
actually need, and sends the rest only to extension content processes.
MozReview-Commit-ID: 6G0LThNTOu1
--HG--
extra : rebase_source : 36672ad6323e6466bba3e463fa4f0a16e3fd9090
This gives JS callers access to the remote type of remote message managers.
There's currently no way for extensions to access this unless they have a
<browser> element to check the remoteType attribute of.
MozReview-Commit-ID: A8Y3ZSG3rt8
--HG--
extra : rebase_source : e024922522da9a30265f05e9a8dbf7529dfe1d81
JS code is notified when a new ContentParent is created via normal
"ipc:content-created" notifications, but can't do anything with it, since
nsIContentParent is not scriptable. This allows JS callers to retrieve the
parent process message manager, which is the normal way they interact with
content children.
MozReview-Commit-ID: 7lcZ4XkJ6uR
--HG--
extra : rebase_source : f891c0e29863fc42fc2351a791ca3f1f7e2824b9
