8ef9106d1ae1941ad83d24bb07226b8534f0cde1: Bug 1452575 - Enable ESLint for devtools/client/shared/**/*.jsm. r=jryans
Mark Banner <standard8@mozilla.com> - Mon, 09 Apr 2018 11:14:01 +0100 - rev 412553
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
Bug 1452575 - Enable ESLint for devtools/client/shared/**/*.jsm. r=jryans MozReview-Commit-ID: G7g94FkBbhp
4ed9006a80a08497b2dbb416b5f2fbdce397fc47: Bug 1452575 - Automatically fix ESLint issues in shared jsm files in devtools. r=jryans
Mark Banner <standard8@mozilla.com> - Mon, 09 Apr 2018 10:44:03 +0100 - rev 412552
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
Bug 1452575 - Automatically fix ESLint issues in shared jsm files in devtools. r=jryans MozReview-Commit-ID: 422ylOOSZUx
abb34767696c933e13bc4d71b89777e6f892c05a: servo: Merge #20602 - Don't make logical properties animatable (from hiikezoe:dont-make-logical-properties-animatable); r=emilio
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Tue, 10 Apr 2018 03:30:13 -0400 - rev 412551
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
servo: Merge #20602 - Don't make logical properties animatable (from hiikezoe:dont-make-logical-properties-animatable); r=emilio |animation_type| was renamed in 94fb839fdde, but the commit missed renaming one place. It means that some of logical properties might have been accidentally animatable. Logical properties should be animatable but we haven't yet implemented the proper Animate trait for logical properties. Source-Repo: https://github.com/servo/servo Source-Revision: e31fefdf7816ff76ff60c7067e89b8aae91d87cd
00ac14e011212f55d75afd6043ac8e41636dec5f: Bug 1452640: Test descendant invalidation for :host(..). r=xidorn
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 09 Apr 2018 23:23:17 +0200 - rev 412550
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
Bug 1452640: Test descendant invalidation for :host(..). r=xidorn MozReview-Commit-ID: 5DkQrgwg9GW
77d5f1b8d04fb60736a5d0d5fcab926bd974b6cc: Bug 1452640: Update test expectations for :host(..). r=me
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 10 Apr 2018 09:40:15 +0200 - rev 412549
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
Bug 1452640: Update test expectations for :host(..). r=me MozReview-Commit-ID: KE39gRnghGL
9a71f7c0daa04971d811c3a4b4a268b6b2ecfdf4: servo: Merge #20606 - style: Implement the functional :host(..) selector (from emilio:host); r=xidorn
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 10 Apr 2018 02:16:30 -0400 - rev 412548
Push 33808 by rgurzau@mozilla.com at Tue, 10 Apr 2018 16:53:55 +0000
servo: Merge #20606 - style: Implement the functional :host(..) selector (from emilio:host); r=xidorn We could invalidate in a slightly more fine-grained way, but I don't think it's worth the churn vs. keeping the special-cases minimal. Bug: 1452640 Reviewed-by: xidorn MozReview-Commit-ID: 5DkQrgwg9GW Source-Repo: https://github.com/servo/servo Source-Revision: e11c2d97552d192b761b0684c8c6852b9dea0921
50b945170f334bb5c7c3dad5a8e975251a369b3b: Bug 1451968: Add comm-central bracnhes to taskgraph project aliases; r=dustin a=reland
Tom Prince <mozilla@hocat.ca> - Thu, 05 Apr 2018 15:48:24 -0600 - rev 412547
Push 33807 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 16:34:42 +0000
Bug 1451968: Add comm-central bracnhes to taskgraph project aliases; r=dustin a=reland There are several project aliases for taskgraph's `run_on_projects`. Add the appropriate `comm-*` branches to those aliases. Differential Revision: https://phabricator.services.mozilla.com/D863
a8061a09cd7064a8783ca9e67979d77fb52e001e: Merge inbound to mozilla-central. a=merge
Csoregi Natalia <ncsoregi@mozilla.com> - Tue, 10 Apr 2018 12:56:48 +0300 - rev 412546
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Merge inbound to mozilla-central. a=merge
73a3eabd2bd29d2ef8945648615f49ed29b326c9: Bug 1448531 - Part 7: Request longer timeout for browser/base/content/test/general/browser_newTabDrop.js. r=bustage
Tooru Fujisawa <arai_a@mac.com> - Tue, 10 Apr 2018 14:12:28 +0900 - rev 412545
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1448531 - Part 7: Request longer timeout for browser/base/content/test/general/browser_newTabDrop.js. r=bustage
41039837009cec7d13229d5e3a3d0b1a2dc77f8a: Bug 1435133 - Test that we delay media play start until we know whether a media has audio or not. r=bryce
Chris Pearce <cpearce@mozilla.com> - Fri, 06 Apr 2018 17:13:39 +1200 - rev 412544
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1435133 - Test that we delay media play start until we know whether a media has audio or not. r=bryce Test that play() on a media without audio called before readyState >= HAVE_METADATA will still play. MozReview-Commit-ID: 1FeDrEfCEum
72144da2637d2bd2f0695010628c6db651482e23: Bug 1435134 - Don't play until we've reached metadata. r=bryce
Chris Pearce <cpearce@mozilla.com> - Tue, 13 Mar 2018 16:40:18 +1300 - rev 412543
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1435134 - Don't play until we've reached metadata. r=bryce We want to block playback of media which have an audio track, so if play() is called before the load of the resource has loaded metadata, we need to delay starting playback and resolving the play promise until we've figured out whether the media has audio. So if play() is called before we've reached readyState >= HAVE_METADATA, set a flag, and check that flag when we do reach HAVE_METADATA and start the play and resolve the promise then. MozReview-Commit-ID: 1K06NK2kfpw
2a39d6a9a949dac9c9cba0a9dfc1bd93de88c79e: Bug 1443942 - Move code to toggle high res timers into VideoSink. r=jya
Chris Pearce <cpearce@mozilla.com> - Fri, 06 Apr 2018 13:33:28 +1200 - rev 412542
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Move code to toggle high res timers into VideoSink. r=jya We have code in the MDSM to toggle on high resolution timers on Windows when we start/stop playing because the VideoSink relies on being awoken by timers to update the set of current frames in the compositor's queue, and on Windows 7 we end up dropping frames due to the timer lag without this. We assert in the MDSM's destructor that we've turned off high res timers (as they cause needless battery drain, so we only want them on when we need them), and the new test_mediarecorder_principals is hitting that assert on Windows. I think we're missing turning them off when we create a new VideoSink for outputting to the MSG. That affects the value returned by MediaDecoderStateMachine->mVideoSink->IsPlaying(), which is what we use to decide whether we should enable high resolution timers. We track whether we've enabled high res timers in MDSM::mHiResTimersRequested, and that gets out of sync with IsPlaying() when we re-create the MediaSink. Rather than trying to handle all the permutations of places where we need to turn off high resolution timers in the MDSM, we're better to move the code to toggle high res timers into the VideoSink, as that's actually where we need to be sure that we have high resolution timers enabled anyway. It's the VideoSink after all that is relying on timers for frame update, not the MDSM. Also remove the media.hi-res-timers.enabled pref, as we haven't needed it. MozReview-Commit-ID: 9dNxcYxPDZH
8b3f66ef0cc427ba2afca030b31194fb5b7aa95b: Bug 1443942 - Rewrite test_mediarecorder_principals. r=bryce
Chris Pearce <cpearce@mozilla.com> - Thu, 05 Apr 2018 13:35:14 +1200 - rev 412541
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Rewrite test_mediarecorder_principals. r=bryce I changed this test earlier in this set of commits to use midflight-redirect.sjs so that we get more reliable and predictable cross origin redirects during the download. Unfortunately this test now times out on Windows. This test times out on Windows because midflight-redirect.sjs redirects at 1/4 through the resource, whereas this test expects to be able to play through to 1/5 through the resource, and on Windows that seems to be not reached during playback. This is likely due to decode latency being higher on Windows. On top of that, the test's first case can sometimes call MediaRecorder.start() before the redirect has happened, and before the principal has changed, and so start() doesn't throw a SecurityError as expected, and the test intermittently fails. Additionally, the test's code could be clearer if we used async/await. So rewrite the test to use async/await, and take advantage of midflight-redirect.sjs's redirect being more predictable than the old dynamic_redirect.sjs. Basically, we can be careful to wait for either "loadedmetadata" or "error" on the media element in order to be more confident the redirect has or hasn't happened yet. We still can't be 100% sure that the redirect won't have already happened by the time our "loadedmetadata" handlers run. It's quite possible that the download has reached 1/4 through the resource by the time the loadedmetadata handler has run, so we need to handle the "error" and "loadedmetadata" events racing. MozReview-Commit-ID: 8plMjkXgjYt
f2306039790583a2c1f75888010d044600d75f82: Bug 1443942 - Ensure MediaCacheStreams are initialized with the length of the resource, not the length of the byte range response. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Apr 2018 12:36:00 +1200 - rev 412540
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Ensure MediaCacheStreams are initialized with the length of the resource, not the length of the byte range response. r=jya I'm seeing intermittent failures of test_midflight_redirect_blocked. In this test, our custom server responds to Firefox's 0- HTTP Byte Range request with a [0,200] response. When Firefox requests 200-, the server responds with a cross origin redirect, and then the remainder of the resource. However sometimes while running test_midflight_redirect_blocked the MP4 demuxer reads through all 200 bytes while trying to parse metadata before the redirect has occurred and fed more data into the cache, and so the demuxer thinks it's hit end of stream, and reports a failure. The demuxer thinks it's hit end of stream, because we initialize the MediaCacheStream length in ChannelMediaResource::Open() with the value of the Content-Length HTTP header. But in an HTTP byte range response, the Content-Length header tells you the length of the range returned, not the length of the entire resource. The length of the resource is in the Content-Range header, we need to use that if available. So to fix this intermittent test failure, we need to also parse the Content-Range header in ChannelMediaResource::Open(), and use the length from that if available. MozReview-Commit-ID: 29pPRsUvxag
79bd527dd8c86844f14a0c2306223f948f5cfcc0: Bug 1443942 - Fix dom/media/test/midflight-redirect.sjs. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Apr 2018 14:30:15 +1200 - rev 412539
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Fix dom/media/test/midflight-redirect.sjs. r=jya Problems here: * The variable `to` is undefined for byte range requests to the end of the resource, making the math fail. Firefox normally makes ranges requests like this. * The bytes.length/4 calculation may not be a whole number, so can result in a byte range header part of the way between two bytes. We need to round the length off. * Instead of re-calculating the contentLength, we can just use the length of the actual byterange substring being returned. That's clearer. * test_midflight_redirect_blocked needs the redirect to happen before metadata has completed loading, but other tests require the redirect to happen *after* metadata is loaded. So add a redirectAt query parameter for the requester to control when to redirect. MozReview-Commit-ID: I6n1NqK0Uze
e02b7f9e296d7f2373d4e77ab2f3567975f4aae3: Bug 1443942 - Switch over to midflight redirect for all redirect media tests. r=jya
Chris Pearce <cpearce@mozilla.com> - Thu, 29 Mar 2018 18:16:33 +1300 - rev 412538
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Switch over to midflight redirect for all redirect media tests. r=jya We have two SJS files; midflight-redirect.sjs and dynamic_redirect.sjs, which are very similar, but dynamic_redirect.sjs is buggy, so we should just use midflight-redirect.sjs. dynamic_redirect.sjs is buggy because it relies on the client doing multiple HTTP requests to it in order to redirect, but we can't actually guarantee this. Previously users of it would try things like setting a small MediaCache size, or only using Ogg for which we expect a seek to the end to calculate the duration, but I have observed the entire resource being downloaded in one hit before the media element has finished loading metadata, meaning the seek (in the Ogg case) can happen without another HTTP request. This is even with a small MediaCache. midfligh-redirect.sjs solves this problem by explicitly only returning a partial response, so the client is forced to make another HTTP request, which we will serve a redirect to. MozReview-Commit-ID: 39imyayhnBG
482dbcc619ce83241380b6e9376b9f9d1014b433: Bug 1443942 - Rewrite test_mixed_principals. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 28 Mar 2018 16:56:37 +1300 - rev 412537
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Rewrite test_mixed_principals. r=jya The original test is failing, as it assumed we'd not error when origins were mixed without CORS, and the original test was using outdated practises, so rewrite it. MozReview-Commit-ID: KlOH83GUOk
ee486ce2d6604682d4f6fa5a3264120829ba2cbe: Bug 1443942 - Make redirect SJS' serve with headers to prevent Necko caching. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 28 Mar 2018 16:55:46 +1300 - rev 412536
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Make redirect SJS' serve with headers to prevent Necko caching. r=jya Try to prevent Necko from caching the results of our SJS media responses, as some of the test that use it rely on the server being hit and serving a redirect. Sometimes the tests which rely on hitting a redirect in an SJS where timing out without this, as Necko would cache the response and not hit the server, and so not hit the redirect. Also include a noise parameter to increase the likelihood that the URL is unique, to further reduce the chance that Necko caches the result. MozReview-Commit-ID: 3cLEiDoh4HG
53d478be27969bb9a00c67b085d6dddbfd0b79b6: Bug 1443943 - Ensure redirect SJS' serve the correct content types. r=jya
Chris Pearce <cpearce@mozilla.com> - Wed, 28 Mar 2018 16:51:04 +1300 - rev 412535
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443943 - Ensure redirect SJS' serve the correct content types. r=jya dynamic_redirect.sjs and midflight-redirect.sjs are serving files with "Content-Type: video/ogg", which is incorrect and could lead to problems given that we're not always asking it to serve Ogg files. So include the type be to served as a query parameter. MozReview-Commit-ID: 5f0PXy8lL3G
038cca3ed2ca2b4aae354d14a6fbfc8b2e1ed6e5: Bug 1443942 - Test for blocking midflight redirects in media elements. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 06 Mar 2018 14:44:26 +1300 - rev 412534
Push 33806 by ncsoregi@mozilla.com at Tue, 10 Apr 2018 09:57:15 +0000
Bug 1443942 - Test for blocking midflight redirects in media elements. r=jya Test that playback works if we don't block, doesn't if we do block, and does if we do block and CORS is used. MozReview-Commit-ID: 9PTZXLOdHIU
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip