The current code is wrong in several ways when transforms are applied, but
even if it were correct, it would give the wrong behavior. See comment in
patch for more details.
MozReview-Commit-ID: 3RaPuvENnWa
--HG--
extra : rebase_source : 25aab67e56f157bdfa500aa7cf029c6ebe90e12a
extra : absorb_source : 4da2fd9f11e008b7b70b86b184ade673a68e6978
On-screen coordinates for points in remote frameloads are calculated relative
to the screen origin of the top-level window, while event coordinates are
calculated relative to the nearest widget. Since popups have their own widgets
separate from the top-level window, their native client offsets have no
particular relation to the origin of the top-level window, and we need to
manually calculate them relative to the origin of the top-level widget
instead.
MozReview-Commit-ID: EDyEyu37XuY
--HG--
extra : rebase_source : 5d3f7a3fb9518d7a0cf149b8c2f579805d75eb3b
extra : absorb_source : f48ee4b131ff67ae686d12f81ed2ad19b934e81e
Note we will move OnDecodeWarning() from MDR to MFR when removing MDR.
MozReview-Commit-ID: 92jpwy6ghH2
--HG--
extra : rebase_source : 72e84f364cdab589efe60e70a071816cb4404955
extra : intermediate-source : fc7ff704e2096935b949ed8b9f6e73945db56a79
extra : source : 6e65a382de5de478948d434fc238a6afe231d2ac
Note we put OnWaitingForKey() in MediaDecoderReader for MediaDecoder references
MDR instead of MFR. The function will be moved into MFR when we remove MDR and
have MediaDecoder reference MFR instead.
MozReview-Commit-ID: LBGfGmc6yFm
--HG--
extra : rebase_source : 473c95cf6eb5e7e4065f9c1251af7dacb78538a5
extra : intermediate-source : 85981e2bafa1047f8321c02de6f0726c32506811
extra : source : 5203bf6895273701ef36a81d2e827e7a7c219fdb
We will use MediaEventSource to plumb the event from MFR to the media element.
MozReview-Commit-ID: 4gaEx7vYybE
--HG--
extra : rebase_source : fd595399e2db4e76ad117636768e160c2f054775
extra : intermediate-source : 1fc86c40dc83e79306c721b1acb0f31803181509
extra : source : d24b62a6041966b2639e5543c9ecccc4f7656a0d
On developer builds, use $MOZ_DEVELOPER_OBJ_DIR to whitelist the object dir in the content sandbox so that symlinks to the object dir from .app/ files can be loaded.
MozReview-Commit-ID: J4YdpxgbD8i
--HG--
extra : rebase_source : 19e369fe9ae29418d9d79e1fb83246474d858f34
The U2FSoftTokenManager is a synchronous implementation and thus didn't need a
timeout so far. We need it for the U2FHIDTokenManager though to let user
interaction timeout properly.
Thus, add a timeout argument to the methods required by the U2FTokenTransport
interface and forward that to the token manager implementations.
Also, one unused include of nsIProgrammingLanguage, which is unrelated.
MozReview-Commit-ID: LJf2NSwmaYG
--HG--
extra : rebase_source : 63dfca9185535dbfa695cf2f383d81a14ce423c0
This adjusts tests to also check origin-based RP IDs, for interop
purposes. When we officially move up to WD-06, we'll want to remove these.
MozReview-Commit-ID: FJRg7vxZIcN
--HG--
extra : rebase_source : 6b89ef1ec5f8f6312bc00740b171540dd2a111cf
A recent fixup commit [1] changed "RP ID" fields in WebAuthn to be domain
strings rather than origins, which matches the current editor's draft of
Web Authentication. Unfortunately, this is contrary to the interop WD-05,
which requires they be origins.
We should be tolerant of origins for now, and in the follow-on Bug 1381126
we'll remove this tolerance once we get past initial WD-05 interop.
[1] https://hg.mozilla.org/mozilla-central/rev/e173fd86d931
MozReview-Commit-ID: Cz2KaHvOIHz
--HG--
extra : rebase_source : eafac0cbab324c566a7ae64004f85258ca3ba805
1. Pause the Exoplayer when navigating to another page and resume playback when navigating back.
2. Fix the OOM issue.
MozReview-Commit-ID: 5UGmBzpObsb
--HG--
extra : rebase_source : f8f268612687669e1b31881465600b02b3531c55
We will use MediaEventSource to dispatch the 'encrypted' events.
MozReview-Commit-ID: KY3nS9OrysI
--HG--
extra : rebase_source : 4e1fa125b099567426f5a6ea2c825b77d407b2c4
extra : source : 8413b0625159d85a5814cb3bd748121653735e96
So we can reduce dependency on AbstractMediaDecoder.
See bug 1378295 comment 1 for the detail.
Note it is not ideal to repeat |init.mCrashHelper = ...| several times in
this patch. We will re-visit it to reduce code duplication after bug 1378295
is done.
MozReview-Commit-ID: AEC56ukqtYr
--HG--
extra : rebase_source : 07554566af74b65f391811e55847e58365ac81fe
extra : source : 7f613117f815369f65256408b221131683c0dd82
This patch disables Geolocation API when fingerprinting resistance is enabled.
The way we disable it is the same as how we disable this API for non-secure
origins that we will reject the request from this API and still keep this API
around.
MozReview-Commit-ID: 5D7Bf6Rplm8
--HG--
extra : rebase_source : b28f33f70a59dc670089dcbbb82f2720a059c341
This allows protocol handlers that load data from a privileged URI (chrome/file/jar) to make the channel's principal
as well as the redirect to look like (to) an unprivileged URI or a URI allowed to load to function correctly.
This allows protocol handlers that load data from a privileged URI (chrome/file/jar) to make the channel's principal
as well as the redirect to look like (to) an unprivileged URI or a URI allowed to load to function correctly.
This patch is going to loose the criteria of skip-to-next-key-frame.
The original rules are here:
http://searchfox.org/mozilla-central/rev/31311070d9860b24fe4a7a36976c14b328c16208/dom/media/MediaFormatReader.cpp#1559
Skip-to-next-key-frame is triggered if the playback position is LARGER than the next key frame time.
But, from the video-track point of view, when the skip-to-next-key-frame is triggered, it skips to the next-next key frame.
Here is an example, say, we are playing a media file with its playback position at time _a_,
and its video decoding is falling behind at time _v_.
The next key frame is at time _k1_ and next-next key frame is at time _k2_.
a
----|---------|---------|-------------|----------------> time
v k1 k2
When the playback position _a_ passes _k1_ (_a_ > _k1_), the skip-to-next-key-frame is triggered,
and the demuxer jumps to _k2_ directly.
The idea here is to give a chance when (_a_ == _k1_), let demuxer jump to _k1_ and see if the video decoding could catch up.
MozReview-Commit-ID: 6aRSYDOI1ds
--HG--
extra : rebase_source : c448df7af9f83b9127bad9bae28f353b40669b7f
1. Moving UpdateA/VInfo to HLSTrackDemuxer and related changes.
2. Handle audio format change by changing the stream id.
MozReview-Commit-ID: IJmSvygZLVf
--HG--
extra : rebase_source : fb90c1454f20ff930626b6febf74b7cb0c4d20b9
We found that a window will not get focus immediately after exiting full screen
mode on Linux. This seems to be a long-standing issue which surfaces due to the
change of background HTML parsing timing. So, we try to get focus everytime
before requesting full screen mode to ensure the request will not fail because
of the focus issue.
MozReview-Commit-ID: 2pOShFZcq8A
--HG--
extra : rebase_source : a92fad6a5e31e7387824da42ef2655a0f7ba002f
This patch is mainly to make IdleTaskRunner reusable by nsHtml5TreeOpExecutor.
The only necessary work to that purpose is to remove the dependency of
sShuttingDown, which was a static variable in nsJSEnvironment.cpp.
The idea is to have a "ShouldCancel" as a callback for the consumer to
return sShuttingDown.
In addition to sShuttingDown, we use std::function<bool()> as the runner
main callback type.
MozReview-Commit-ID: FT2X1unSvPS
--HG--
extra : rebase_source : dc9bcf669a95dda5c40bccde2cbc836099536eb5
Nothing is changed in this patch except for renaming and code move around.
The strategy is to have the final file setup in this patch without any
detail change. The actual code change will be in the next patch so that
we can focus on reviewing the diff in the next patch regarding IdleTaskRunner.
MozReview-Commit-ID: 4Bul9mZ7z1n
--HG--
extra : rebase_source : 22aeb5dca58501ec335ef8bc7b0efb6aea565bbf