This gives us extra defense in depth.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2bbc458c5b2ad44d008cfa57415fe41d1a7ada5e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b4c8722fd8a88da9c8d3f21b600085da637e9a9e
When we set the playback rate to zero on a play-pending animation that is
resuming from an aborted pause we can arrive in a state where both the start
time and hold time are resolved. However, we previously added an assertion that
only one of these is ever set at a time.
Part of the assertion is warranted since that method contains the following
code:
if (mStartTime.IsNull()) {
mStartTime = StartTimeFromReadyTime(aReadyTime);
if (mPlaybackRate != 0) {
mHoldTime.SetNull();
}
}
Here StartTimeFromReadyTime requires a non-null hold time. So either mStartTime
or mHoldTime needs to be non-null. The requirement that only one or the other be
non-null, however, is not in the spec and not necessary (as the test cases in
this bug show).
What this assertion does bring to light, however, is that in the case where we
have *both* the start time and the hold time, we need to consider whether to use
the start time as-is, or calculate it from the hold time.
I have filed the following spec issue for this:
https://github.com/w3c/web-animations/issues/200
MozReview-Commit-ID: CTCT7Up1E5n
--HG--
extra : rebase_source : 95233f7cd2bc3c4bcc56615d8387fe54852986c1
The method isn't called and the comments referring to it are no longer applicable.
MozReview-Commit-ID: 2FFWhj7wzht
--HG--
extra : rebase_source : 5987c52a2a220185a61a45d18a6229aa7e5d8ea3
For now, convert 10/12 bits YUV image to 8 bits. Native support will be tracked in bug 1379948
MozReview-Commit-ID: LOr9X5xxKY7
--HG--
extra : rebase_source : 279e00832543501616af0a4a5958917b72533a4c
This allows for decoding VP9 profile 2 and 3.
At this stage, it is not possible to render the decoded frames.
MozReview-Commit-ID: DFXMvaM8Ynb
--HG--
extra : rebase_source : e17f24a00595461910f6d0cbd8ef4ba25453e8c5
There's no guarantee that the stride of the uv planes is twice as wide as the y plane's stride. This relationship is only true between the planes' width.
MozReview-Commit-ID: JInge1c86Z1
--HG--
extra : rebase_source : 0e9cf5be06812712d50a42db7630f396d0020791
When we generate the glyph mask for a transformed frame in
GenerateAndPushTextMask, the transform vector had been applied into aContext[1],
so we should find a way to prevent applying the vector again when painting the
glyph mask.
In bug 1299715, I tried to prevent double apply at [2], it caused two problems:
1. We only skip generating nsDisplayTransform, but we may still create a
nsDisplayPerspactive bellow. Since the parent of a nsDisplayPerspective must be
a nsDisplayTransform, which have been ignored, so we hit this assertion.
2. We skip all transform for all frames while painting the glyph mask, which is
not correct. We should only skip double applying transform vector of the root
frame.
This patch fixes both of these issues:
a. We will still create a nsDisplayTransform for the root frame if need. But
the transform matrix we apply into the target context will be an identity
matrix, so we fix#1 above.
b. In #a, we change the transform matrix to an identity matrix only for the root
frame of the glyph mask, so we fix#2.
[1]
https://hg.mozilla.org/mozilla-central/file/59e5ec5729db/layout/painting/nsDisplayList.cpp#l752
[2]
https://hg.mozilla.org/mozilla-central/file/ce2c129f0a87/layout/generic/nsFrame.cpp#l2806
MozReview-Commit-ID: 973lkQQxLB6
--HG--
extra : rebase_source : aef80444e94d3af7eca776c981f8faded03bc985
We register the nsIWebProgressListener at the root docshell(GetSameTypeRootTreeItem) to handle video element embedded in iframe.
MozReview-Commit-ID: D4CavLDAnKD
--HG--
extra : rebase_source : 93032297272bbfc8570dce0c8c13ea9f0d45f7a8
In geckoview_example multiprocess mode, preload child process during
startup to make e10s startup faster.
MozReview-Commit-ID: GinwBZlrnps
--HG--
extra : rebase_source : a43ef4708d311c9a100aafba0c84ee4a2e27090b
We need to wait for GeckoThread to load the Gecko libs in the main
process before we can launch any child processes, so that the child
process doesn't try to extract libs, which can conflict with any
extraction going on in the main process.
MozReview-Commit-ID: 2gUd2R1TUBI
--HG--
extra : rebase_source : d48b9e2e744669a89f2b761cf6936f28948c17c3
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
Refactor the code in GeckoProcessManager and GeckoServiceChildProcess so
that, we can have a ChildConnection object that's bound but not started.
This way we can bind the connection to preload Gecko child process, but
hold off starting until told by Gecko main process.
Some code is simplified. For example, `IChildProcess.stop` is removed in
favor of killing the child process directly.
MozReview-Commit-ID: 4XgmTuT0IAs
--HG--
extra : rebase_source : 94fe748556c66f639d1f8e5bb26c28ea3ed950b3
Normally when we interpolate values for CSS properties we convert empty values
(such as the empty "from" value created for a by-animation) to a suitable zero
value. However, when we use discrete interpolation that step never occurs and in
some rare cases that means we end up setting the empty value on the target
attribute directly which will have an incorrect result (e.g. setting "" for the
height property will have no effect, whereas setting "0px" will).
This patch makes us perform the empty value to zero value conversion when
performing discrete animation.
Unfortunately it is not possible to test this behavior with shorthands since
there are currently no shorthand properties that are additive.
MozReview-Commit-ID: JFT1tis1RAR
--HG--
extra : rebase_source : cc444b6d4d5571c8ab231d88c4d349ea0713baaa
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
The difference between GetXULRunnerStubPath and XRE_GetBinaryPath was
removed in bug 552864.
--HG--
extra : rebase_source : 20060486de82c04bc888fade5be1f42675bc5d07
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
There's an intermittent which might be spurious because ASN.1 signatures might
sometimes be less than 70 bytes, but the actual floor is probably 68 (32 + 32
+ 4).
It's a sanity check, so I've adjusted it down and also am now emitting the
offending key bytes if this triggers again.
MozReview-Commit-ID: 1wwU9Q3BUPF
--HG--
extra : rebase_source : 2877deb770f8bf4bcf31dae40f75016892dc9d53
