This patch exists to avoid a crash in layout/style/test/test_animations.html. We end up
generating some ::before content, which causes us to style the new subtree at [1]. In
StyleNewSubtree, we fail the !postTraversalRequired assertion because
PrepareAndTraverseSubtree decided to traverse the tree twice (once to style it, and again
to restyle it for animations), and return that a post-traversal is needed.
The reason this issue happens with my NAC patches and not without is that we were previously
filtering out generated ::before content from the servo traversal, so the servo traversal
wouldn't have reached it and (presumably) the animation restyle wouldn't have happened and
we wouldn't have returned true for needing a post-traversal.
[1] http://searchfox.org/mozilla-central/rev/c48398abd9f0f074c69f2223260939e30e8f99a8/layout/base/nsCSSFrameConstructor.cpp#1918
MozReview-Commit-ID: 8tgzLjV8B3A
Windows AAC decoder decode a mono AAC stream into a stereo PCM. Bug 1347101 set the output to be mono, which caused a failure to find the appropriate IMFMediaType.
This partially revert bug 1347101 audio changes.
MozReview-Commit-ID: 2M4X4rKKvXl
--HG--
extra : rebase_source : 6b7330a7edfc2c0504171828526221dcccb6f8c5
When the agent is audible, we should check whether need to notify "blockStart"
immediately.
MozReview-Commit-ID: KmYLo9cEt4X
--HG--
extra : rebase_source : 71ad5892a30727f00fd3c764d83ade074bc85f15
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : fa86b3977e13d1f2a6b6233b6d608ccc331b5bf7
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
--HG--
extra : rebase_source : 953eed775637a19c6d5d323ab1549f6ed5f7ff31
When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.
The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.
We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.
MozReview-Commit-ID: CXv9VZqTRzY
--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb
When the agent is audible, we should check whether need to notify "blockStart"
immediately.
MozReview-Commit-ID: KmYLo9cEt4X
--HG--
extra : rebase_source : 5f29de593b85113001552ff0497621e603b40bc6
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : 28a8312373054b8e29b93267677de99dd862a074
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
--HG--
extra : rebase_source : 416113dd2282a979ea26c4694878c2f2db578274
Per bug 1322570 Comment 7, we could drop the GetParentAllowServo() when we
invoke UpdateProperties() from a SquentialTask, so allow it for now.
MozReview-Commit-ID: 52NauGaz4Zv
--HG--
extra : rebase_source : 617c3310a042ca49023ebad1801a2c283e4e212c
We often need to turn on both MediaSample and MediaDecoder logs when debugging sample activities.
So it is convenient to merge them into a single log module.
Use `MOZ_LOG=MediaDecoder:4` to show decoder logs.
use `MOZ_LOG=MediaDecoder:5` to show both decoder and sample logs.
MozReview-Commit-ID: JQtyoyrNRmV
--HG--
extra : rebase_source : 85739da85aa4059b058a9baccd5509c8149712d8
1. Use LOG() for OnMediaSink{Audio,video}Complete() which is not verbose.
2. Use LOGW() for OnMediaSink{Audio,Video}Error() which indicates an error.
MozReview-Commit-ID: 4Z5U32YlMPB
--HG--
extra : rebase_source : 2b2da51c17b6c7d9b4ec8b0f274c9ed018631374
This allows us to remove the #ifdef MOZ_ENABLE_WEBRENDER for the advanced layers
prefs from all.js. As additional advanced layers are turned on for webrender (or
non-webrender) they can be converted into override prefs without affecting the
call sites.
MozReview-Commit-ID: F9tMc23ow8A
--HG--
extra : rebase_source : 2244cb000711496ce5b7f1b50ef0314e1c312d94
X11.h #defines 'Status' and 'Failed' and 'Succeeded' which conflicts with
the enum in DetailedPromise. So rename the 'Status' enum in DetailedPromise
so that the build works on Linux.
Some of my changes here caused DetailedPromise to be included in more
places that it was before, which caused build failures on Linux.
MozReview-Commit-ID: KV5xKixXR3J
--HG--
extra : rebase_source : ef6cab901d74b78f613660f263f5e453d6044536
This is required for the browser clearing persistence tests to pass.
MozReview-Commit-ID: Ai9qc6Ds1IG
--HG--
extra : rebase_source : 80c2133e26742410fda983e3c18c35736fc013d0
This severs the ChromiumCDMVideoDecoder's connection with the CDM. The CDM process
will shutdown when the MediaKeys also severs its connection.
MozReview-Commit-ID: Aqc4y5Nxjvc
--HG--
extra : rebase_source : 5a2f77ffe84f9b99b4668520c838b29a428578d3
At this stage, I store video frames in memory in nsTArrays rather than in
shmems just so we can get this working. Once this is working, I'll follow up
with patches to switch to storing all large buffer traffic between the CDM and
other processes in shmems.
I'm not planning on preffing this new CDM path on until that's in place.
MozReview-Commit-ID: LSTb42msWQS
--HG--
extra : rebase_source : b7f162515a1a32b2c344c11d0fa5c7004cec2e15
The MediaKeys accesses the ChromiumCDMProxy on the main thread. But the
ChromiumCDMVideoDecoder will need to access the ChromiumCDMProxy on the decode
task queue in order to get a reference to the ChromiumCDMParent so that it can
talk to the CDM (on the GMP thread).
Additionally we'll need to shutdown the ChromiumCDMProxy, and if we do that
on the main threrad while the ChromiumCDMVideoDecoder is trying to get the
ChromiumCDMParent reference, we could hit thread safety issues.
So we need to hold a lock while reading or writing from the ChromiumCDMProxy's
reference to the ChromiumCDMParent. So add a GetCDMParent() function to the
ChromiumCDMProxy which takes the lock while reading or writing the reference.
This means that the caller will always get a valid reference. There is no guarantee
that the ChromiumCDMParent isn't shutdown after the reference is taken; if that
happens, the ChromiumCDMParent returned will fail on all operations.
In a later patch in this series, the ChromiumCDMProxy will anull its reference
to the ChromiumCDMParent on shutdown, and cause GetCDMParent to return null.
So callers need to null check the return value of GetCDMParent.
MozReview-Commit-ID: 4xL41YbwkxL
--HG--
extra : rebase_source : aa854e9d88965d7da60231d6f6a3912bf6ad2eeb
This commit refactors the SetDomain method in a Document to call a new function
IsRegistrableDomainSuffixOfOrEqualTo(), defined in HTML [1]. This commit tries
not to rename anything except input variables, so as to remain as clear as
possible. It likely should have various variables renamed, but given the
author's unfamiliarity with this module, review seems a good time to do that.
It's also duplicating comments a little bit; let me know which one(s) you'd like
to keep!
Note: Commentary on the HTML change is available in the PR [2], and the
rationale for this behavior in Web Auentication, where this algorithm will be
used, is also recorded [3].
Update 1: Refactored two new protected methods to avoid code duplication.
Update 2: Bugfix: Be sure to use CreateInheritingURIForHost for the
provided domain so as to catch internationalized domains.
Update 3: Nit-fix and rebase
[1] https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to
[2] https://github.com/whatwg/html/pull/2365
[3] https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-175766580
MozReview-Commit-ID: 4Dr8yOMdhez
--HG--
extra : rebase_source : 634bd3c7b60c7ad996ee38ab7314071b426e3f6f
Emilio Cobos Álvarez
Bobby Holley
Carsten "Tomcat" Book
Iris Hsiao
Jan-Ivar Bruaroey
Jean-Yves Avenard
Alastor Wu
Chris Pearce
Ting-Yu Lin
JW Wang
Mats Palmgren
Kartikaya Gupta
Daosheng Mu
J.C. Jones
Wes Kocher
Andrea Marchesini