searching for reviewer(cpearce)
f574c731fcb0: Bug 1497034 - FeaturePolicy: autoplay, r=cpearce
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 09 Oct 2018 14:22:19 +0200 - rev 440236
Push 34810 by shindli@mozilla.com at 2018-10-09 16:24 +0000
Bug 1497034 - FeaturePolicy: autoplay, r=cpearce
2cdf1848b6a7: Bug 1496501 - Do not mark CDM input as unencrypted even if it has no encrypted bytes. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Mon, 08 Oct 2018 22:34:32 +0000 - rev 440119
Push 34807 by shindli@mozilla.com at 2018-10-09 09:27 +0000
Bug 1496501 - Do not mark CDM input as unencrypted even if it has no encrypted bytes. r=cpearce Bug 1494178 added code to mark samples with 0 encrypted ranges as unencrypted before they were fed to the CDM. This was to catch issues where we could mark such unencrypted samples as encrypted. However, the CDM expects certain samples that are clear to still be marked as encrypted. Specifically, WebM samples should be marked as encrypted if they are from an encrypted track and have the signal byte's encryption bit set (a marker for if the packet is encrypted), even if they have no encrypted ranges. The WebM demuxer is already doing this. Further inspection and testing of the mp4 demuxer shows it is behaving in line with Chromium's current mp4 parser, which we can expect prepares its data sensibly for Widevine. As the code removed here was added as a safety fallback, but is causing issues, and as the demuxers already appear to be doing the right thing, the fallback code can be removed. Differential Revision: https://phabricator.services.mozilla.com/D8024
b88586cb4fdd: Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:41:58 +0000 - rev 439965
Push 34801 by toros@mozilla.com at 2018-10-08 16:19 +0000
Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels. Depends on D7316 Differential Revision: https://phabricator.services.mozilla.com/D7318
5e7ea76f73f3: Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Mon, 08 Oct 2018 13:26:00 +0200 - rev 439963
Push 34801 by toros@mozilla.com at 2018-10-08 16:19 +0000
Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback. Depends on D7295 Differential Revision: https://phabricator.services.mozilla.com/D7296
2851d7aead76: Bug 1495025 - P2. Use lambda for callback. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Mon, 08 Oct 2018 13:24:19 +0200 - rev 439962
Push 34801 by toros@mozilla.com at 2018-10-08 16:19 +0000
Bug 1495025 - P2. Use lambda for callback. r=cpearce I find it easier to read than a function pointer making you search elsewhere to see what it's about Depends on D7294 Differential Revision: https://phabricator.services.mozilla.com/D7295
107add19c310: Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:39:50 +0000 - rev 439961
Push 34801 by toros@mozilla.com at 2018-10-08 16:19 +0000
Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits. When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT. Differential Revision: https://phabricator.services.mozilla.com/D7294
68efa7588ba8: Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:41:58 +0000 - rev 439921
Push 34796 by btara@mozilla.com at 2018-10-07 09:50 +0000
Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels. Depends on D7316 Differential Revision: https://phabricator.services.mozilla.com/D7318
7fd1f6103294: Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:40:51 +0000 - rev 439919
Push 34796 by btara@mozilla.com at 2018-10-07 09:50 +0000
Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback. Depends on D7295 Differential Revision: https://phabricator.services.mozilla.com/D7296
f1afe7e2a9e3: Bug 1495025 - P2. Use lambda for callback. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:40:18 +0000 - rev 439918
Push 34796 by btara@mozilla.com at 2018-10-07 09:50 +0000
Bug 1495025 - P2. Use lambda for callback. r=cpearce I find it easier to read than a function pointer making you search elsewhere to see what it's about Depends on D7294 Differential Revision: https://phabricator.services.mozilla.com/D7295
c62823871aca: Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:39:50 +0000 - rev 439917
Push 34796 by btara@mozilla.com at 2018-10-07 09:50 +0000
Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits. When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT. Differential Revision: https://phabricator.services.mozilla.com/D7294
528dbc463c22: Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:41:58 +0000 - rev 439546
Push 34778 by nbeleuzu@mozilla.com at 2018-10-04 15:22 +0000
Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder r=cpearce As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels. Depends on D7316 Differential Revision: https://phabricator.services.mozilla.com/D7318
c3b43ee1092e: Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:40:51 +0000 - rev 439544
Push 34778 by nbeleuzu@mozilla.com at 2018-10-04 15:22 +0000
Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback. Depends on D7295 Differential Revision: https://phabricator.services.mozilla.com/D7296
c548d816019d: Bug 1495025 - P2. Use lambda for callback. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:40:18 +0000 - rev 439543
Push 34778 by nbeleuzu@mozilla.com at 2018-10-04 15:22 +0000
Bug 1495025 - P2. Use lambda for callback. r=cpearce I find it easier to read than a function pointer making you search elsewhere to see what it's about Depends on D7294 Differential Revision: https://phabricator.services.mozilla.com/D7295
208624601a18: Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 04 Oct 2018 09:39:50 +0000 - rev 439542
Push 34778 by nbeleuzu@mozilla.com at 2018-10-04 15:22 +0000
Bug 1495025 - P1. Search for alternative pixel format when stream change. r=cpearce When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits. When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT. Differential Revision: https://phabricator.services.mozilla.com/D7294
2a4364e194c5: Bug 1495359 - FeaturePolicy: encrypted-media, r=cpearce
Andrea Marchesini <amarchesini@mozilla.com> - Tue, 02 Oct 2018 11:55:27 +0200 - rev 439165
Push 34757 by rgurzau@mozilla.com at 2018-10-02 16:04 +0000
Bug 1495359 - FeaturePolicy: encrypted-media, r=cpearce
14e7673d10f7: Bug 1494178 - Attempt to instantiate CDM10 before CDM9. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Wed, 26 Sep 2018 16:34:34 +0000 - rev 438322
Push 34716 by shindli@mozilla.com at 2018-09-26 21:51 +0000
Bug 1494178 - Attempt to instantiate CDM10 before CDM9. r=cpearce Depends on D6873 Differential Revision: https://phabricator.services.mozilla.com/D6874
e6f8e822851a: Bug 1494178 - Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Wed, 26 Sep 2018 16:34:32 +0000 - rev 438321
Push 34716 by shindli@mozilla.com at 2018-09-26 21:51 +0000
Bug 1494178 - Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce With the addition of an explicit encryption enum for CDM10 input data, if a sample has 0 encrypted bytes it must be marked as unencrypted. Historically we could let the CDM figure out based on the unencrypted + encrypted bytes. However, if we mark a sample as encrypted but it has 0 encrypted bytes, the CDM will fail to decrypt. This changeset adds a check to gracefully handle samples that are marked as encrypted but with no encrypted ranges. In such cases we mark the data as unencrypted and log that such data was encountered. This means we don't break playback of encrypted media should we overlook such cases, but have better detection via logging. Differential Revision: https://phabricator.services.mozilla.com/D6873
c4972079847a: Bug 1494144 - correct the autoplay result in autoplay log. r=cpearce
alwu <alwu@mozilla.com> - Wed, 26 Sep 2018 00:49:54 +0000 - rev 438228
Push 34712 by aiakab@mozilla.com at 2018-09-26 12:35 +0000
Bug 1494144 - correct the autoplay result in autoplay log. r=cpearce After bug1476555 landed, IsMediaElementAllowedToPlay() would only return boolean, not integer. We should modify AllowAutoplayToStr() in order to log the correct result. Differential Revision: https://phabricator.services.mozilla.com/D6864
8a1695f0c08c: Bug 1491889 - Update ChromiumCDMChild to hold a promise to track CDM init. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 25 Sep 2018 13:33:27 +0000 - rev 438115
Push 34710 by aciure@mozilla.com at 2018-09-25 21:48 +0000
Bug 1491889 - Update ChromiumCDMChild to hold a promise to track CDM init. r=cpearce This changeset extends the async initialize functionality added in the prior changeset by wrapping the Initialize resolver in a promise. This allows us to use familiar promise machinery to handle async init of the CDM. We do this by creating the promise and setting up handling when we receive the init message on the ChromiumCDMChild, but resolving the promise in the `OnInitialized` callback from the CDM to the ChromiumCDMChild. We still only support CDM9 as of this changeset. As such, we now manually call `OnInitialized` to make sure the ChromiumCDMParent is notified that the CDM has initialized. When we implement the CDM10 interface, these manual calls will be moved to the CDM9 compat layer, and Widevine CDM10+ can perform its own callback. This changeset adds a failure path to initialization, as the `OnInitialized` interface we implement allows for failure. However, since we manually call into this path for CDM9 we shouldn't get any such failures. Once CDM10 is fully implemented its possible that the init callback could indicate failure, and the handling here would be invoked. Depends on D6061 Differential Revision: https://phabricator.services.mozilla.com/D6066
53dfb7e2bc86: Bug 1491889 - Update chromium CDM interface to accommodate async init. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 25 Sep 2018 13:33:09 +0000 - rev 438114
Push 34710 by aciure@mozilla.com at 2018-09-25 21:48 +0000
Bug 1491889 - Update chromium CDM interface to accommodate async init. r=cpearce Starting at the Widevine CDM10 interface, the CDM is expected to make a callback to an `OnInititalized` function to signal initialization has taken place. Prior to this, it was sufficient to call the init function on the CDM, with no waiting for a callback. This changeset puts in place the IPDL to support async init, as well as the handling for the ChromiumCDMParent and ChromiumCDMProxy. The code is not fully updated to handle CDM10, so CDM9 is the only compatible CDM. Because CDM9 does not perform the init callback, we immediately call our IPDL to signal init has taken place. This also accommodates the clearkey case, which uses the CDM9 interface. Further changesets will put in place more elaborate handling to accommodate the possible failure of init, as well as implementing the handling `OnInitialized` function explicitly. Differential Revision: https://phabricator.services.mozilla.com/D6061
cb9048ebfec3: Bug 1491889 - Update ChromiumCDMChild to hold a promise to track CDM init. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 25 Sep 2018 02:43:55 +0000 - rev 437967
Push 34707 by ebalazs@mozilla.com at 2018-09-25 09:18 +0000
Bug 1491889 - Update ChromiumCDMChild to hold a promise to track CDM init. r=cpearce This changeset extends the async initialize functionality added in the prior changeset by wrapping the Initialize resolver in a promise. This allows us to use familiar promise machinery to handle async init of the CDM. We do this by creating the promise and setting up handling when we receive the init message on the ChromiumCDMChild, but resolving the promise in the `OnInitialized` callback from the CDM to the ChromiumCDMChild. We still only support CDM9 as of this changeset. As such, we now manually call `OnInitialized` to make sure the ChromiumCDMParent is notified that the CDM has initialized. When we implement the CDM10 interface, these manual calls will be moved to the CDM9 compat layer, and Widevine CDM10+ can perform its own callback. This changeset adds a failure path to initialization, as the `OnInitialized` interface we implement allows for failure. However, since we manually call into this path for CDM9 we shouldn't get any such failures. Once CDM10 is fully implemented its possible that the init callback could indicate failure, and the handling here would be invoked. Depends on D6061 Differential Revision: https://phabricator.services.mozilla.com/D6066
f8c53e2fdc7a: Bug 1491889 - Update chromium CDM interface to accommodate async init. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Tue, 25 Sep 2018 02:42:26 +0000 - rev 437966
Push 34707 by ebalazs@mozilla.com at 2018-09-25 09:18 +0000
Bug 1491889 - Update chromium CDM interface to accommodate async init. r=cpearce Starting at the Widevine CDM10 interface, the CDM is expected to make a callback to an `OnInititalized` function to signal initialization has taken place. Prior to this, it was sufficient to call the init function on the CDM, with no waiting for a callback. This changeset puts in place the IPDL to support async init, as well as the handling for the ChromiumCDMParent and ChromiumCDMProxy. The code is not fully updated to handle CDM10, so CDM9 is the only compatible CDM. Because CDM9 does not perform the init callback, we immediately call our IPDL to signal init has taken place. This also accommodates the clearkey case, which uses the CDM9 interface. Further changesets will put in place more elaborate handling to accommodate the possible failure of init, as well as implementing the handling `OnInitialized` function explicitly. Differential Revision: https://phabricator.services.mozilla.com/D6061
eaccb6c8b0d0: Bug 1493027 - part2 : add test. r=cpearce
alwu <alwu@mozilla.com> - Sun, 23 Sep 2018 22:12:43 +0000 - rev 437945
Push 34707 by ebalazs@mozilla.com at 2018-09-25 09:18 +0000
Bug 1493027 - part2 : add test. r=cpearce Differential Revision: https://phabricator.services.mozilla.com/D6541
fd4c5546dfa3: Bug 1493027 - part1 : access permissions without creating MediaManager. r=cpearce
alwu <alwu@mozilla.com> - Sun, 23 Sep 2018 22:11:06 +0000 - rev 437943
Push 34707 by ebalazs@mozilla.com at 2018-09-25 09:18 +0000
Bug 1493027 - part1 : access permissions without creating MediaManager. r=cpearce If a site had been granted persistent permissions, but hasn't accessed navigator.mediaDevices yet. Then, we can't read the permission because MediaManager hasn't be created yet. We should read these permissions without loading MediaManager. In addition, I noticed that even user only requests 'screen' permission, we would also add the 'camera' and 'microphone' permission in the nsIPermissionManager. That makes us no way to print the log to distinguish what actually permission user granted. Differential Revision: https://phabricator.services.mozilla.com/D6540
d706e4a7016f: Bug 1479218 - deny request when inner window is destroyed. r=cpearce
alwu <alwu@mozilla.com> - Mon, 17 Sep 2018 17:09:46 +0000 - rev 436774
Push 34659 by btara@mozilla.com at 2018-09-17 21:55 +0000
Bug 1479218 - deny request when inner window is destroyed. r=cpearce The AutoplayPermissionManager might be destroyed before the AutoplayPermissionRequest, so we can't get the response from request before AutoplayPermissionManager is destroyed. Therefore, we should manually reject the promise when the inner window is going to be destroyed. Differential Revision: https://phabricator.services.mozilla.com/D5906
02bd8c7d626e: Bug 1477767 - disconnect request when XPCOM is going to shutdown. r=cpearce
alwu <alwu@mozilla.com> - Mon, 17 Sep 2018 16:54:17 +0000 - rev 436773
Push 34659 by btara@mozilla.com at 2018-09-17 21:55 +0000
Bug 1477767 - disconnect request when XPCOM is going to shutdown. r=cpearce The reason we hit this assertion is that we still connected to Then() and waited for its result when the resolve or reject runnable which dispatched by ThenValue can't be executed because the target thread had been shutdown. Therefore, when XPCOM is going to shutdown, we should disconnect the Then() because it might not have a chance to execute its resolve/reject method. Differential Revision: https://phabricator.services.mozilla.com/D5893
639181de70e6: Bug 1487811 - P4: Implement CDM10 -> CDM9 compat layer. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Thu, 13 Sep 2018 15:11:17 +0000 - rev 436156
Push 34630 by nerli@mozilla.com at 2018-09-13 21:58 +0000
Bug 1487811 - P4: Implement CDM10 -> CDM9 compat layer. r=cpearce Implement a compatibility layer so that we can expose a CDM10 interface while still using CDM9. Notably, this layer checks to make sure the new encryption scheme introduced with CDM10 is not used with CDM9. Depends on D5630 Differential Revision: https://phabricator.services.mozilla.com/D5631
8f814dfe27bd: Bug 1487811 - P3: Add CDM10 functions to IPDL. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Thu, 13 Sep 2018 14:49:45 +0000 - rev 436155
Push 34630 by nerli@mozilla.com at 2018-09-13 21:58 +0000
Bug 1487811 - P3: Add CDM10 functions to IPDL. r=cpearce The CDM10 interface makes 2 notable changes here: 1) Instead of the binary choice between unencrypted and encrypted (which assumed cenc encryption), the interface now allows for specification of encryption used. Practically this means we will eventually need to support choosing between not encrypted, cenc, or cbcs. 2) The interface adds a bool for hardware secure codecs for use when initializing the CDM. This changeset adjusts the IPDL for the CDM to accommodate these changes. The changes are also supported in surrounding code, but are not fully plumbed to either the web, or the CDM. Fully supporting new encryption schemes and hardware secure codecs will require further work which is beyond the scope of this bug. Some formatting drive bys so new formatting and old formatting both match expected formatting by clang-format. Depends on D5629 Differential Revision: https://phabricator.services.mozilla.com/D5630
3d154d157bc7: Bug 1487811 - P2 Remove CDM8 interface specific IPDL. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Thu, 13 Sep 2018 14:49:27 +0000 - rev 436154
Push 34630 by nerli@mozilla.com at 2018-09-13 21:58 +0000
Bug 1487811 - P2 Remove CDM8 interface specific IPDL. r=cpearce Remove members only used by CDM8 from the IPDL and remove code that depended on the removed IPDL. Rename various instances of 'error' to 'exception' as from CDM9 'exception' is used exclusively to refer to promise failure states. Depends on D5628 Differential Revision: https://phabricator.services.mozilla.com/D5629
e9b9cb4d4328: Bug 1487811 - P1: Update Widevine headers and C++ code to prepare for CDM interface 10 support. r=cpearce
Bryce Van Dyk <bvandyk@mozilla.com> - Thu, 13 Sep 2018 14:49:10 +0000 - rev 436153
Push 34630 by nerli@mozilla.com at 2018-09-13 21:58 +0000
Bug 1487811 - P1: Update Widevine headers and C++ code to prepare for CDM interface 10 support. r=cpearce Update content_decryption_module.h and other Widevine headers. This removes the CDM8 interface and adds in the CDM10 and CDM11 interfaces. As such this patch removes references to CDM8 from the code and adds some of the foundations for supporting CDM10. Most of the CDM10 code will be implemented in another bug, but there are a number of cases where it was straight forward to shuffle CDM8+9 code -> CDM9+10, rather than deleting it and replacing it later. Differential Revision: https://phabricator.services.mozilla.com/D5628
58fc60f3fdf1: Bug 1485189 - part1 : dispatch related events when play is not allowed. r=cpearce
alwu <alwu@mozilla.com> - Tue, 28 Aug 2018 22:03:15 +0000 - rev 433912
Push 34525 by aiakab@mozilla.com at 2018-08-29 21:52 +0000
Bug 1485189 - part1 : dispatch related events when play is not allowed. r=cpearce "blocked" event is used for testing. "MozAutoplayMediaBlocked" event is used for changing the control UI on Fennec. Differential Revision: https://phabricator.services.mozilla.com/D4267
bb9759881cd7: Bug 1483703 - part4 : modify current telemtry scalar because we won't block media without audio track anymore. r=cpearce,francois
alwu <alwu@mozilla.com> - Wed, 22 Aug 2018 22:54:05 +0000 - rev 432949
Push 34492 by cbrindusan@mozilla.com at 2018-08-23 03:43 +0000
Bug 1483703 - part4 : modify current telemtry scalar because we won't block media without audio track anymore. r=cpearce,francois Since we don't block media without audio track anymore, the original telemetry scalar becomes useless. We need to change its meaning in order to know the number of allowed autoplay without audio track. Differential Revision: https://phabricator.services.mozilla.com/D3673
d915d805e964: Bug 1483703 - part3 : modify test. r=cpearce
alwu <alwu@mozilla.com> - Wed, 22 Aug 2018 22:52:04 +0000 - rev 432948
Push 34492 by cbrindusan@mozilla.com at 2018-08-23 03:43 +0000
Bug 1483703 - part3 : modify test. r=cpearce Differential Revision: https://phabricator.services.mozilla.com/D3672
3326c0e920d4: Bug 1483703 - part2 : add telemetry for the media which was blocked before loading metadata and ended up being without audio track. r=cpearce,francois
alwu <alwu@mozilla.com> - Wed, 22 Aug 2018 22:50:54 +0000 - rev 432947
Push 34492 by cbrindusan@mozilla.com at 2018-08-23 03:43 +0000
Bug 1483703 - part2 : add telemetry for the media which was blocked before loading metadata and ended up being without audio track. r=cpearce,francois Add two telemetry scarlar, "MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet. "MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track. By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata. Differential Revision: https://phabricator.services.mozilla.com/D3671
71ad474cdeeb: Bug 1483703 - part1 : allow media without audio track to autoplay. r=cpearce
alwu <alwu@mozilla.com> - Wed, 22 Aug 2018 23:31:58 +0000 - rev 432946
Push 34492 by cbrindusan@mozilla.com at 2018-08-23 03:43 +0000
Bug 1483703 - part1 : allow media without audio track to autoplay. r=cpearce We would allow media without audio track to autoplay after it had loaded the metadata. If media hasn't loaded metadata yet, we would treat it as audible media and then block it. Differential Revision: https://phabricator.services.mozilla.com/D3670
cd6a42517bb9: Bug 1483703 - part1 : allow media without audio track to autoplay. r=cpearce
alwu <alwu@mozilla.com> - Tue, 21 Aug 2018 20:58:26 +0000 - rev 432941
Push 34492 by cbrindusan@mozilla.com at 2018-08-23 03:43 +0000
Bug 1483703 - part1 : allow media without audio track to autoplay. r=cpearce We would allow media without audio track to autoplay after it had loaded the metadata. If media hasn't loaded metadata yet, we would treat it as audible media and then block it. Differential Revision: https://phabricator.services.mozilla.com/D3670
8fbba4053aa0: Bug 1482259 - Add Telemetry to know the proportion of silent part in the whole audio track. r=cpearce,francois
alwu <alwu@mozilla.com> - Wed, 15 Aug 2018 16:35:51 +0000 - rev 431648
Push 34450 by ebalazs@mozilla.com at 2018-08-16 09:22 +0000
Bug 1482259 - Add Telemetry to know the proportion of silent part in the whole audio track. r=cpearce,francois Use new telemetry histogram ID 'AUDIO_TRACK_SILENCE_PROPORTION' to know the proportion of silent part in the whole audio track. Differential Revision: https://phabricator.services.mozilla.com/D3066
1cee6e0d07e7: Bug 1476555 - Show notification when autoplay blocked globally. r=cpearce,johannh
Dale Harvey <dale@arandomurl.com> - Mon, 23 Jul 2018 16:43:08 +0100 - rev 431635
Push 34449 by dvarga@mozilla.com at 2018-08-15 22:19 +0000
Bug 1476555 - Show notification when autoplay blocked globally. r=cpearce,johannh MozReview-Commit-ID: EI0GiaoBNqX
753fc72a27d5: Bug 1480484 - add telemetry scalar to measure the count for blocked media element without audio track. r=cpearce,francois
alwu <alwu@mozilla.com> - Fri, 03 Aug 2018 13:21:03 -0700 - rev 430448
Push 34405 by ncsoregi@mozilla.com at 2018-08-08 09:57 +0000
Bug 1480484 - add telemetry scalar to measure the count for blocked media element without audio track. r=cpearce,francois This is used to count the potiential number of the blocked autoplay media element without audio track even if user was enable autoplay. It might happen on three cases, 1. play -> loadedmetadata 2. loadedmetadata -> play 3. loadedmetadata -> has 'autoplay' keyword In first case we need to check whether the play invocation has been called, and check other other cases before the media starts playing. In addition, the scalar name isn't consist with other names is because of the 40 maximum limitation of the ping name. MozReview-Commit-ID: 6Qm6TD4ME8I
a7067dbdc7b5: Bug 1480484 - add telemetry scalar to measure the count for blocked media element without audio track. r=cpearce,francois
alwu <alwu@mozilla.com> - Fri, 03 Aug 2018 13:21:03 -0700 - rev 430437
Push 34405 by ncsoregi@mozilla.com at 2018-08-08 09:57 +0000
Bug 1480484 - add telemetry scalar to measure the count for blocked media element without audio track. r=cpearce,francois This is used to count the potiential number of the blocked autoplay media element without audio track even if user was enable autoplay. It might happen on three cases, 1. play -> loadedmetadata 2. loadedmetadata -> play 3. loadedmetadata -> has 'autoplay' keyword In first case we need to check whether the play invocation has been called, and check other other cases before the media starts playing. In addition, the scalar name isn't consist with other names is because of the 40 maximum limitation of the ping name. MozReview-Commit-ID: 6Qm6TD4ME8I
8c52db0efc88: Bug 1480738 - part2 : add test. r=cpearce
alwu <alwu@mozilla.com> - Fri, 03 Aug 2018 12:57:38 -0700 - rev 430280
Push 34396 by aiakab@mozilla.com at 2018-08-07 09:35 +0000
Bug 1480738 - part2 : add test. r=cpearce MozReview-Commit-ID: 8GwifOpAQNf
23f078580a97: Bug 1480738 - part1 : only allow top-level video document to autoplay. r=cpearce
alwu <alwu@mozilla.com> - Fri, 03 Aug 2018 11:28:30 -0700 - rev 430279
Push 34396 by aiakab@mozilla.com at 2018-08-07 09:35 +0000
Bug 1480738 - part1 : only allow top-level video document to autoplay. r=cpearce Only allow top-level video document to autoplay in order to avoid autoplay from video document which is in the iframe. MozReview-Commit-ID: BbyjviK1BRK
4c8a057c6d54: Bug 1480281 - part2 : move exist log to autoplay log module. r=cpearce
alwu <alwu@mozilla.com> - Wed, 01 Aug 2018 17:50:19 -0700 - rev 429922
Push 34376 by btara@mozilla.com at 2018-08-03 10:10 +0000
Bug 1480281 - part2 : move exist log to autoplay log module. r=cpearce MozReview-Commit-ID: EtBRTjYG8k3
4c0d86611660: Bug 1480281 - part1 : add autoplay debug log module. r=cpearce
alwu <alwu@mozilla.com> - Wed, 01 Aug 2018 17:30:59 -0700 - rev 429921
Push 34376 by btara@mozilla.com at 2018-08-03 10:10 +0000
Bug 1480281 - part1 : add autoplay debug log module. r=cpearce Add new log module which allow us to debug by using "MOZ_LOG=Autoplay:5". MozReview-Commit-ID: 9CG5JyCw21G
8e1182e32a9f: Bug 1466926 - part1 : always allow extension background script to autoplay. r=cpearce
alwu <alwu@mozilla.com> - Tue, 10 Jul 2018 10:37:33 -0700 - rev 429673
Push 34371 by nerli@mozilla.com at 2018-08-02 08:52 +0000
Bug 1466926 - part1 : always allow extension background script to autoplay. r=cpearce In present web extension design (both Firefox and Chrome), background script can autoplay. We don't want to break this design, so we would always allow it to autoplay. MozReview-Commit-ID: 9BfWgll7PNx
92cbea18e430: Bug 1476701 - notify observer when audible autoplay occurred. r=cpearce,jaws
alwu <alwu@mozilla.com> - Wed, 25 Jul 2018 09:08:44 -0700 - rev 429478
Push 34365 by dluca@mozilla.com at 2018-08-01 09:51 +0000
Bug 1476701 - notify observer when audible autoplay occurred. r=cpearce,jaws In our autoplay shield-study, we want to collect the information which could tell us how many website contains audible autoplay media, but there is no way to get this information on current API desigin. Therefore, I would like to send a new notification when autoplay occurred. The extension code could get the information by following way, ``` Services.obs.addObserver((subject, topic, data) => { // DO SOMETHING }, "AudibleAutoplayMediaOccurred"); ``` MozReview-Commit-ID: 4bSYcxDZOGK
8890b8f7e9cc: Bug 1477415 - part2 : add test. r=cpearce
alwu <alwu@mozilla.com> - Mon, 23 Jul 2018 11:30:12 -0700 - rev 428374
Push 34333 by cbrindusan@mozilla.com at 2018-07-25 21:36 +0000
Bug 1477415 - part2 : add test. r=cpearce MozReview-Commit-ID: 9Besbb3JWRP
784d6695694c: Bug 1477415 - part1 : allow video document autoplay. r=cpearce
alwu <alwu@mozilla.com> - Mon, 23 Jul 2018 11:17:00 -0700 - rev 428373
Push 34333 by cbrindusan@mozilla.com at 2018-07-25 21:36 +0000
Bug 1477415 - part1 : allow video document autoplay. r=cpearce Allow autoplay for video document when user is directly viewing a video/audio by visiting its url. MozReview-Commit-ID: GnSxx32h6hm
e384aedb30b6: Bug 1477477 - Add preference for autoplaying muted media. r=cpearce
Tom Schuster <evilpies@gmail.com> - Sun, 22 Jul 2018 15:21:48 +0200 - rev 427700
Push 34312 by apavel@mozilla.com at 2018-07-22 21:47 +0000
Bug 1477477 - Add preference for autoplaying muted media. r=cpearce
694089774911: Bug 1476612 - AntiTracking should use nsIDocument::Get/SetUserHasInteracted instead of UserGestureActivation, r=cpearce
Andrea Marchesini <amarchesini@mozilla.com> - Thu, 19 Jul 2018 13:14:27 +0200 - rev 427293
Push 34299 by ncsoregi@mozilla.com at 2018-07-19 16:10 +0000
Bug 1476612 - AntiTracking should use nsIDocument::Get/SetUserHasInteracted instead of UserGestureActivation, r=cpearce