On Android, the life cycle of graphic buffer is equal to Android's codec, and
it would be released immediately if we shutdown the decoder.
Since the buffer has been release, the memory we access is totally meaningless.
The result is we would render the black image on the screen.
In addition, I suspect this issue might be one of the root cause which results
in lots of timeout for media mochitest, so I would like to land this patch first,
and then do the follow-up in bug1367983.
MozReview-Commit-ID: 5eZph6MItZs
--HG--
extra : rebase_source : 99036cd087bf758c8a70be686c40fa2d84d7f6c1
This implements some methods exposed on DOMWindowUtils and used by
reftests, for the WebRender codepath. The implementation is very similar
to the implementation in LayerTransactionParent.
MozReview-Commit-ID: HP8OxzIzS7P
Test to confirm valid 'inherit' value of -moz prefixed properties during
animation. This also means to confirm the algorithm of clone_XX methods
of stylo.
NOTE: This file should have only animatable properties that have '-moz' prefix.
In this patch, appends following properties.
* -moz-box-align
* -moz-box-direction
* -moz-box-orient
* -moz-box-pack
* -moz-float-edge
* -moz-orient
* -moz-osx-font-smoothing
* -moz-user-focus
* -moz-user-input
* -moz-user-modify
* -moz-window-dragging
MozReview-Commit-ID: GfBfMkvfgGm
--HG--
extra : rebase_source : f2e220ccc0c6864ad15416a2cda470f64eeb62be
See bug 1346723. I would like to turn off undo when not user interaction. Except to Gecko, other browsers don't create undo history by input.value setter.
MozReview-Commit-ID: 9P1eOKTXCXN
--HG--
extra : rebase_source : 44967a19300827af6187c4f906e09ed09808cd30
When not using eSetValue_BySetUserInput, we should use SetText transaction instead for fast path. For backward compatibility, when input.value setter is by user interaction, I keep original way. Because the original way doesn't replace all text when some string matches.
MozReview-Commit-ID: IDm7Y1NBmaK
--HG--
extra : rebase_source : 625085737f5c110dac11f9bc8a38c98a703ce2b1
This makes it easier to tell what's going on; whether we've created a
MediaKeySystemConfiguration which can persist state.
MozReview-Commit-ID: L4dbmMVYhsM
--HG--
extra : rebase_source : e47e60f5091b6b5477b2c8bd63ba408922706082
This will enable us to re-use the logging code in MediaKeySystemAccess to log
the configuration we end up instantiating the MediaKeySystemAccess with.
MozReview-Commit-ID: AMnauhMLJ1R
--HG--
extra : rebase_source : a2dfeb7b263108ac1c60bfe2f47755e0a73d6324
We want requests for MediaKeySystemAccess with persistentState to be rejected
if the window is in Private Browsing mode. This is primarily so that users in
Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be
provisioned/used in a given time period, and the device ID is persisted in the
persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be
unable to continue watching DRM video.
MozReview-Commit-ID: JWNO1kcU2ST
--HG--
extra : rebase_source : ad4e22629acfdd82aff8ead764949939726adbf4