Bug 1451005 - Enable the available memory tracker on Windows 64-bit; r?njn MozReview-Commit-ID: ETg8y5lweXa

Bug 1452929 - Fix eslint errors in devtools/server/tests/browser/browser_storage_browser_toolbox_indexeddb.js r=miker MozReview-Commit-ID: B5hgHqMcKSQ

Bug 1448118 - Test for the storage inspector when running inside the browser toolbox r?nchevobbe MozReview-Commit-ID: DrNrHwYVo8U

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

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

Bug 1452916: Remove dead error reporting code. r?bholley MozReview-Commit-ID: GAn0ASQzBt

Bug 1452916: Expose the error reporting pref. r?bholley MozReview-Commit-ID: wkUSJ50Nne

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

Merge inbound to mozilla-central. a=merge

Bug 1448531 - Part 7: Request longer timeout for browser/base/content/test/general/browser_newTabDrop.js. r=bustage

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

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

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

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

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

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

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

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

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

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