This allows us to run SMIL tests that include a combination of additive and
non-additive animation.
MozReview-Commit-ID: 2uVN184h7Ge
--HG--
extra : rebase_source : f6a3dc70e20c09cbfdb8cc3149e2820575866b89
This is just a minor refactoring to simplify ValueFromStringHelper before we
refactor it further in the next patch (and so we can re-use this definition to
produce debug warning for Servo since we don't handle negative values there
yet).
MozReview-Commit-ID: CfcnI2Be5di
--HG--
extra : rebase_source : 4e052cc37d24671159f32c3e0ca3bc48f5a73c54
We will use this later in this patch series to simplify the creation of SMIL's
ValueWrapper objects.
MozReview-Commit-ID: 7EF9CN2SdwQ
--HG--
extra : rebase_source : e7cf5adc4c3f72dcc4b99625a8d0cb1a2d17f7d4
We will use this type later in this patch series in nsSMILCSSProperty so this
patch moves it to a separate file so it can be re-used.
MozReview-Commit-ID: 4Z7YbsQ9xz4
--HG--
extra : rebase_source : 0f6f7248d1a4dfc77360829f3a0e6ed263f156db
In the next patch in this series we would like to use this functionality in
nsSMILController as well so this patch moves it to somewhere we can share it.
MozReview-Commit-ID: 1IzWoCCw4aD
--HG--
extra : rebase_source : 9f2b230f774135c0c5bf60ebdff358ce0a6bc087
PR for [Gecko bug 1355348](https://bugzilla.mozilla.org/show_bug.cgi?id=1355348)
---
- [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 they are tested on the Gecko side
Source-Repo: https://github.com/servo/servo
Source-Revision: 8824a68063aa4f3ca87454468f382e4d2be66487
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 936553a846e86eacae01601c1ff1f515550200c6
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 1b7905c101b7ebf406e88c73be5d0e069b7342c0
Tests for page timeout durations have to use an HTTPD handler that delays
or slows down document load. Otherwise there a risk that the timeout error
is not returned before the document finishes loading.
MozReview-Commit-ID: HGGcXfCuaSH
--HG--
extra : rebase_source : c79b01ca4e56e21877c6fe94309b7b0424d9b552
In the case when the trigger callback inside navigate() uses a generator,
the code has to be synchronized and needs to wait until the contained
command has been completed.
MozReview-Commit-ID: 8qKUMvH7HpS
--HG--
extra : rebase_source : 19a87058d62088701914ab2a468ddffaecec1fe2
In the case of switching to an in-process frame, the checkLoad timer
is setup which waits for the frame's content to finish loading.
But the command doesn't actually wait for those events and calls
sendResponse() immediately. This causes a race condition for the
following commands.
MozReview-Commit-ID: 6vuQ7paQ55K
--HG--
extra : rebase_source : ceb590f435d84ead4eba2e718e1ebaa01900d33f
A frames timing function is a type of timing function that divides the input time into a specified number of intervals of equal length, each of which is associated with an output progress value of increasing value.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#15740.
- [X] There are tests for these changes, and web-platform-tests/css-timing-1 also provides tests.
Source-Repo: https://github.com/servo/servo
Source-Revision: 15cf1acc720197b80ff1ad97ea5ddc495f5744fd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0266050134e4f669e10f178c3f06dbeee99f2cc0
Similar to some previous commits, we prefer non-throwing constructors
in order to ensure we never lose a reference to an unclosed stream.
InpuStreamReader(..., Charset) is preferred over InputStreamReader(..., String)
since the latter can throw when the String is not a valid Charset.
(In reality we know that our Charset Strings are correct, but the compiler
isn't able to determine that for itself. Moreover, using the preparsed
Charset is more efficient.)
MozReview-Commit-ID: 9z07G3hqPI3
--HG--
extra : rebase_source : 6ed740bf5a1e5296bd2afe5c58b19a43acab0647
The primary issue is that we use a throwing InputStreamReader
constructor. If it throws, then any nested streams will be lost.
We can fix that by using the non-throwing InputStreamReader
constructor (which uses a Charset as the second parameter,
instead of a String which causes an Exception to be thrown
if it can't be parsed)
We also simplify some nested Stream's a little: most of the
Stream constructors don't throw, so there's no harm in not keeping
individual references to those that don't throw - and that
results in less Stream references for us to handle.
MozReview-Commit-ID: 2hyRFGVmGnU
--HG--
extra : rebase_source : 15dd97d28012a017326b01ae8ddc370c7f1ec484
MergeCursor can handle null cursors (and is lightweight), we
don't need to specifically handle each case - which results in simpler
code.
MozReview-Commit-ID: CGwMi9LKYTj
--HG--
extra : rebase_source : 74c0c83ba4e8ea6ca036c24372ee7ff07a1cbc78
A quick fix for hazard bustage by increase the NUM_ALLOWED_WRITE_HAZARDS
from 3 to 7 is pushed in bug 1348173 comment 37. In this bug, we shall do
the actual fix and restore the NUM_ALLOWED_WRITE_HAZARDS.
The -moz-border-*-colors bindings trigger errors because they're using
outparams (nsStyleBorder) which further manipulate its member (mBorderColors)
which is a double raw pointers. Since we don't have the ability to
whitelist the indirect access to mBorderColors[x] list, we can only add
them to the ignoreContents for now.
We might be able to move these bindings to the whitelist of the above
treatAsSafeArgument function, if we could refactor mBorderColors to use
nsTArray directly.
MozReview-Commit-ID: 2cQz58K2A10
--HG--
extra : rebase_source : af2b5b944fb9d19fe28f57eaa37f77174d48bfa4
So we can cancel the bad test as soon as possible and give a better description about the error.
MozReview-Commit-ID: ExKIK2HqJkN
--HG--
extra : rebase_source : 26391dfea33ab792cc5f0dc58fa42e6309e0c699
extra : source : 138125800895658a6feb88e3f90487d62b955f6a
We can remove AbstractMediaDecoder::UpdateEstimatedMediaDuration() which
has no callers at all.
MozReview-Commit-ID: Eub12jQ25KK
--HG--
extra : rebase_source : f564b84a147252bd98c13fe475af971808880c8c
extra : intermediate-source : 4c0870a71b2091c39f5fc67c5cf21dea0a4cc459
extra : source : 1bfe40324a3801f8d60384b247d85f04b8971bbe
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: K3Bz3uEXLDK
--HG--
extra : rebase_source : ade3cbd61c764b73a22c360572a525127dbadbc5
extra : intermediate-source : 013227a4aa645fc34a82c44130db6c847d74960b
extra : source : 1ab7ce426b557e4ce9979e023f9e84b4690eeaaa
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
I removed it, but seems it can be hit. It'd be nice to have a test-case where it
fails though...
MozReview-Commit-ID: 7Xa3dNHwFMn
--HG--
extra : rebase_source : 7f0d8df2f571b84745c41bf675f12a9340016775
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
Carsten "Tomcat" Book
Brian Birtles (:birtles)
Alex Chronopoulos
Brian Birtles
Rob Thijssen
Henrik Skupin
Henri Sivonen
Luke Chang
Chris Manchester
Boris Chiou
Andrzej Hunt
Jeremy Chen
Phil Ringnalda
JW Wang
Chris Pearce
Iris Hsiao
Emilio Cobos Álvarez
Sean Lee
Jared Wein
Wes Kocher