This call gated by ifdef OS_WIN - so on Linux it would leak objects that were supposed to be ClearOnShutdown in the plugin process
--HG--
extra : rebase_source : 24c4233ec8735e0176d584b623ad626d0a9b5c3b
We get intermittent OOMs building aom with MSVC on win32. The PGO builds are
definitely a problem, but it may affect other builds as well. The plan for now
is to stop supporting AV1 on win32 until we switch to clang, which hopefully
is not too far away.
--HG--
extra : rebase_source : e2a754dc635d003c39cfa51b044d68a2a4a2f592
This reflects the API changes to the aom_codec_decode function and the removal
of I440. It also sets allow_lowbitdepth to give proper support for 8 bit video,
and removes the git version from the mime type.
MozReview-Commit-ID: GuTvnPkR1Er
--HG--
extra : rebase_source : 4540f74df335d59714a61d5f7e2ad7a54f8fa00d
The aomstats library is only used in the code examples, but we assume that all
libraries should be linked into libxul, which leads to an unresolved external
dependency on fatal at link time. This adds a guard to only build aomstats if
we are building the examples.
MozReview-Commit-ID: 8CRK3klUPk7
--HG--
extra : rebase_source : a50680122e4b55497a835101ef3e0f0c96cdd79e
The bitstream is frozen and we're updating to v1.0.0. There is no longer any need
to indicate which revision we're using in the mimetype.
--HG--
extra : rebase_source : 5f5bf8649bd21610ebf04661e8f80bacbb69ca09
This changes generate_sources_mozbuild.sh to call generate_sources_mozbuild.py
to generate sources.mozbuild and config files and removes the parts of the
script that are no longer necessary.
MozReview-Commit-ID: HgXIEw93z41
--HG--
extra : rebase_source : b54d23197e741c8e037ffc4b977c8d01c34197ef
This uses the cmakeparser to generate sources.mozbuild and the
config files for each platform.
MozReview-Commit-ID: CU6oIPJXtTw
--HG--
extra : rebase_source : b9f6707ed3f4ef6336a4fa2d75c46a5c26570528
The new "tooltip.css" file allows styling the default tooltip, which is created as native anonymous content.
MozReview-Commit-ID: ADWsFTNPfhw
--HG--
rename : toolkit/themes/linux/global/popup.css => toolkit/themes/linux/global/tooltip.css
rename : toolkit/themes/osx/global/popup.css => toolkit/themes/osx/global/tooltip.css
rename : toolkit/themes/windows/global/popup.css => toolkit/themes/windows/global/tooltip.css
extra : source : 4d511f7fc5b5c16fdfea91242dea6086cd57c8c3
extra : intermediate-source : b880ba94f5241a755282431a17cd9cb0f5f24e78
Such messages happen intermittently on Android, presumably from bfcache being
purged due to memory pressure (which would then cause the back() operation
behave like a fresh load). So on Android, we'll now treat these redundant
messages as a "todo()" failure, to indicate that something went wrong but avoid
turning the testsuite orange.
MozReview-Commit-ID: GkaxB06vL7q
--HG--
extra : rebase_source : 64c0c0a41452d573062774b2300a26aad179b309
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
This patch adds a new IPDL protocol PBackgroundLocalStorageCache. It is used by LocalStorageCache object to broadcast changes in local storage cache to other content processes. Each origin has its own PBackgroundLocalStorageCache, so now we can notify content processes that actually have a local storage cache for given origin. This greatly improves performance and reduces memory footprint especialy when local storage changes carry big strings and/or happen very quickly (before this patch all child processes were blindly notified).
We can start playing while we're awaiting a response to an autoplay-media
permission prompt, for example if the user clicks on a play button. In such
cases, it doesn't make sense to keep the autoplay permission request promise
connected in HTMLMediaElement, as since we're playing we'll be resolving the
play() promises and thus we won't be taking action on the autoplay request
promise's result. So we should just disconnect the autoplay permission request
promise if it's connected when we start playing.
MozReview-Commit-ID: 1aiCLXV7Ja9
--HG--
extra : rebase_source : c439e8f084ac8cc01db578d712e15d3174a08e71
