3769d6c0fb13ed0b5b72c13a9292a3a5edd89493: Bug 1451005 - Enable the available memory tracker on Windows 64-bit; r?njn draft
Gabriele Svelto <gsvelto@mozilla.com> - Tue, 10 Apr 2018 14:30:09 +0200 - rev 779731
Push 105842 by gsvelto@mozilla.com at Tue, 10 Apr 2018 12:45:04 +0000
Bug 1451005 - Enable the available memory tracker on Windows 64-bit; r?njn MozReview-Commit-ID: ETg8y5lweXa
d0e72e001145e23c7449ec3344b7231fbf909301: Bug 1452929 - Fix eslint errors in devtools/server/tests/browser/browser_storage_browser_toolbox_indexeddb.js r=miker draft
Michael Ratcliffe <mratcliffe@mozilla.com> - Tue, 10 Apr 2018 13:31:06 +0100 - rev 779730
Push 105841 by bmo:mratcliffe@mozilla.com at Tue, 10 Apr 2018 12:31:43 +0000
Bug 1452929 - Fix eslint errors in devtools/server/tests/browser/browser_storage_browser_toolbox_indexeddb.js r=miker MozReview-Commit-ID: B5hgHqMcKSQ
00d27e2fc6fa3e35ae7f7eb699af0b770a6b4e6d: Bug 1448118 - Test for the storage inspector when running inside the browser toolbox r?nchevobbe draft
Mike Ratcliffe <mratcliffe@mozilla.com> - Fri, 23 Mar 2018 15:36:08 +0000 - rev 779729
Push 105840 by bmo:mratcliffe@mozilla.com at Tue, 10 Apr 2018 12:23:40 +0000
Bug 1448118 - Test for the storage inspector when running inside the browser toolbox r?nchevobbe MozReview-Commit-ID: DrNrHwYVo8U
4f77446122677ee4d87f7c14ed8de70aa7c7016d: Bug 1445160 - Enable inspect indexedDBs inside JSMs via Storage Inspector in browser toolbox r?nchevobbe draft
Michael Ratcliffe <mratcliffe@mozilla.com> - Wed, 21 Mar 2018 16:09:57 +0000 - rev 779728
Push 105839 by bmo:mratcliffe@mozilla.com at Tue, 10 Apr 2018 12:22:43 +0000
Bug 1445160 - Enable inspect indexedDBs inside JSMs via Storage Inspector in browser toolbox r?nchevobbe Fixed added file: and moz-extension: to prefix regex. MozReview-Commit-ID: JtCgzquybA4
a7fa2a9ec79c45ec5894712fa11f2725cd5d8a76: Bug 1452913 - Prevent hang of reftests when reading test objects list fails. draft
Henrik Skupin <mail@hskupin.info> - Tue, 10 Apr 2018 14:20:02 +0200 - rev 779727
Push 105838 by bmo:hskupin@gmail.com at Tue, 10 Apr 2018 12:20:39 +0000
Bug 1452913 - Prevent hang of reftests when reading test objects list fails. For the promise as returned by "OS.File.read()" the catch handler is missing, and as such the tests will never be started when the call to "read()" triggers an exception. It also results in a hang of the reftest harness. To prevent this, the failure has to be handled and appropriately reported. MozReview-Commit-ID: IX9thgjjahS
a91a4747f3fe7ecd79f93e19822a6303be6a8198: Bug 1452916: Remove dead error reporting code. r?bholley draft
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 10 Apr 2018 12:26:13 +0200 - rev 779726
Push 105837 by bmo:emilio@crisal.io at Tue, 10 Apr 2018 12:12:36 +0000
Bug 1452916: Remove dead error reporting code. r?bholley MozReview-Commit-ID: GAn0ASQzBt
26c60c96b474c45bcae969fbe12cf368d7a55c62: Bug 1452916: Expose the error reporting pref. r?bholley draft
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 10 Apr 2018 12:03:48 +0200 - rev 779725
Push 105837 by bmo:emilio@crisal.io at Tue, 10 Apr 2018 12:12:36 +0000
Bug 1452916: Expose the error reporting pref. r?bholley MozReview-Commit-ID: wkUSJ50Nne
1a5b0aafd24cb704b9cd178eefc3e902679b7b26: Bug 1451916 - Have geckodriver recognise chrome elements. r?whimboo draft
Andreas Tolfsen <ato@sny.no> - Fri, 06 Apr 2018 14:41:00 +0100 - rev 779724
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +0000
Bug 1451916 - Have geckodriver recognise chrome elements. r?whimboo Before we can deploy bug 1400233 which removes the JSON Object field "ELEMENT" from Marionette, we need to make geckodriver recognise "chromeelement-9fc5-4b51-a3c8-01716eedeb04". Technically a chrome element is not a web element, but geckodriver treats it as such. This is in line with previous behaviour but should at some point be changed when WebDriver supports these types of extensions. This patch does not drop support for the legacy web element identifier (ELEMENT) since it would entail dropping support for Firefox 55 and later. The new element identifiers were introduced in Firefox 58. MozReview-Commit-ID: GiBHcOcvGbh
a8061a09cd7064a8783ca9e67979d77fb52e001e: Merge inbound to mozilla-central. a=merge
Csoregi Natalia <ncsoregi@mozilla.com> - Tue, 10 Apr 2018 12:56:48 +0300 - rev 779723
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779722
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779721
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779720
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779719
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779718
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779717
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779716
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779715
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779714
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779713
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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 779712
Push 105836 by bmo:ato@sny.no at Tue, 10 Apr 2018 12:07:22 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip