MozReview-Commit-ID: RoAVWKb0qC

--HG--
rename : devtools/client/webconsole/new-console-output/test/moz.build => devtools/client/webconsole/new-console-output/test/fixtures/moz.build
rename : devtools/client/webconsole/new-console-output/test/stubs.js => devtools/client/webconsole/new-console-output/test/fixtures/stubs.js
extra : rebase_source : 1eb041f42860689e1013355294763238630c61f3

--HG--
extra : rebase_source : 15b8165ae03fc81f335f54e157173bef1a6eadf2

MozReview-Commit-ID: E83Hs7QDlLJ

--HG--
extra : rebase_source : 51dcd49ef9841fcbd4dad5ed841c46cf06f80d8e

MozReview-Commit-ID: E83Hs7QDlLJ

--HG--
extra : rebase_source : 111e05169271980ca000816eda3d1d71de650225

In the `python-test` mach command and the mozharness script for
the Marionette harness tests, use the vendored-in Pytest
instead of installing from pip.

Add the Marionette harness test requirements file to the
file_patterns in the definition of the marionette-harness taskcluster
job, as changes to the requirements should trigger the job to run.


MozReview-Commit-ID: J5pln2WB4GY

--HG--
extra : rebase_source : 5144ccfabb84eb0da244b24f6d27b59ae183c174

Vendor in Pytest (2.9.2) and its requirement Py (1.4.31),
so that it can be used for e.g. the Marionette
harness unit tests and a pytest plugin for mozlog.

Copy pytest and py package directories (extracted from
tars on Pip) into `mozilla-central/python/`, removing
some support files (e.g. changelog, docs, tests).
Add both `.pth` entries to `virtualenv_packages.txt`.
Add both paths to `SEARCH_PATHS` in `mach_bootstrap.py`.

MozReview-Commit-ID: IOTCOUxX8R9

--HG--
extra : rebase_source : e03d8a4be084062c0055b365bcc18da6dbb0b7a7

Backed out changeset 74b1d84ac6aa (bug 1113634) for failing Cpp unit test TestAudioEventTimeline. r=backout

This effectively reverts the change in 2f0d6ea822b5 (bug 1163057)
to own the files by root:root. Since that change landed, we su
to the "worker" user early during task startup. So there is no more
need to have /home/worker owned by root:root.

MozReview-Commit-ID: 77q9APiDKpb

--HG--
extra : rebase_source : 6f45af9c51fa6c0f9f14ea183b008e38f9388664

MozReview-Commit-ID: E2EuTblT30M

--HG--
extra : rebase_source : 6ffbd0c170dbac9584adbb83afe6fdfbc6501fe5

MozReview-Commit-ID: 8ORBttWN2Rj

--HG--
extra : rebase_source : 9ad6ae8aff9cbc81c773297d0bb2f7478fb3516e

MozReview-Commit-ID: 2CHJxPQdVEg

--HG--
extra : rebase_source : e7ca98136d7d954911683e66fcf39920aca24267

Bug 1113634 - Update mLastComputedValue in AudioEventTimeline when skipping events of same time; r=karlt

MozReview-Commit-ID: LuxSK6PHFHv

--HG--
extra : rebase_source : 2f0a906e747f30a83aa7237850245c056e932bd6

Fix permafail for mda on WinXP which has no h264

MozReview-Commit-ID: 35tlO5vPTLD

--HG--
extra : rebase_source : 4d0edc219f75bd2107a3828a4df6419d7449657a

Bug 1291667 - Removed unused variant 'MozNone' from StyleUserSelect enum class; r=heycam,manishearth

MozReview-Commit-ID: 53dJd2GYUdt

--HG--
extra : rebase_source : 406d58b113d3044eb9f48b02fdd0168494c22847

MozReview-Commit-ID: IcDt3XYvdlj

--HG--
extra : rebase_source : ea426ac572b6adfc09fd9440e45a0c26adde4373

MozReview-Commit-ID: 7ae467k5PSf

--HG--
extra : rebase_source : 96e79cc0ba99272d9573a427408e820cb496c106

MozReview-Commit-ID: 8wgRY9QHOYg

--HG--
extra : rebase_source : 4f55c867d67a4103fea332393cb8e8c7e9cd02b0

Bug 1294345 - Remove the TrackSet parameter from MediaDecoderStateMachine::InitiateDecodeRecoverySeek(). r=kaku

MozReview-Commit-ID: 7iXecyVAIXq

--HG--
extra : rebase_source : e9648409896caac46863a401984820a8ac123118

Bug 1293613: don't assume playback won't be finished by the time the seeked event is fired. r=gerald

The data added in the sourcebuffer is very short (less than one second); it is possible that playback has completed prior the event being fired.

MozReview-Commit-ID: INHAFmEhSut

--HG--
extra : rebase_source : 864c2a9623d672859b0ab836e25403e90ee2090c

MozReview-Commit-ID: CepvbVjoN1k

--HG--
extra : rebase_source : 4abe0fc35b25a865f3909fdf7d74f54736da6c97

MozReview-Commit-ID: 9iTzmMhw686

--HG--
extra : rebase_source : 4ee1bec4155367dc66a136a4f14c9c83cbdd8dd5

They should all run properly now.

MozReview-Commit-ID: YLjQ8jkNcf

--HG--
extra : rebase_source : d174f2ee27940f197225e47c359a106d78259c07

Should the events being waited for take a while to fire, we could have attempted to append more segments than the table contain causing an exception.

MozReview-Commit-ID: HnmLTqNQ5rb

--HG--
extra : rebase_source : f9b703a0ed1f3b950428dc55dd7943068bc6aa2d

Bug 1293613: Don't assume that once playing event has fired, the earlier appendBuffer has completed. r=gerald

The two operations are asynchronous and independent.

MozReview-Commit-ID: D2woSoIzE6p

--HG--
extra : rebase_source : bd9bb272d1040d20edbba53d43041cf7d5eb7bbc

Do not assume that the element is still seeking when the seeking event is actually fired (the seeking operation is asynchronous)

MozReview-Commit-ID: Ap24kUQK8R2

--HG--
extra : rebase_source : 6bf251e5156e2c306fe004c2c6d959549cddab77

- No html document existed, preventing the test to run.
- Remove test related to the updating attribute being cleared: see https://github.com/w3c/media-source/issues/118

MozReview-Commit-ID: GxOBnr5mqyh

--HG--
extra : rebase_source : 8b5573a444b9d19e2326bc1329ab7dc7ac7934c4

See issue https://github.com/w3c/web-platform-tests/issues/1939

MozReview-Commit-ID: LgDQRS8Xz3L

--HG--
extra : rebase_source : 79e0d67675b8cdcfc97bc0dc1d28a1ad97a2b85a

Audio track and video tracks have under most cases a different start and end time. Additionally, the mp4 file is poorly muxed and contains out of order frames. As such we keep a table of time and duration for each media segments.

The test itself was right, however it had an invalid time table to start with as it incorrectly used the dts (decode timestamp) instead of the pts (presentation timestamp).

MozReview-Commit-ID: G2uwK3rroj3

--HG--
extra : rebase_source : 13e0c020ed825f4285291b81dd1fa9da6956dd4b

https://w3c.github.io/media-source/index.html#mediasource-attach: "If the resource fetch algorithm absolute URL matches the MediaSource object URL, ignore any preload attribute of the media element, skip any optional steps for when preload equals none"
A dummy URL or a revoked one no longer matches the MediaSource object URL, as such, the preload attribute isn't to be ignored.

MozReview-Commit-ID: EW5TOv9SSf

--HG--
extra : rebase_source : f3019139d5c6d198555dc623cd13d7294055e0f6

- The WebM file manifest correctly indicates the duration as reported in the metadata. However, the last frame has an end time 0f 6.05s which would adjust the duration. As such it is incorrect to assume that after a full appendBuffer the duration will remain the same as set in the metadata.
(source: https://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing "5. If the media segment contains data beyond the current duration, then run the duration change algorithm with new duration set to the maximum of the current duration and the group end timestamp")

- When setting the duration, the actual final duration may be different to what was set as it will be aligned to the highest end time
(source: https://w3c.github.io/media-source/index.html#duration-change-algorithm ("4.1 Update new duration to the highest end time reported by the buffered attribute across all SourceBuffer objects in sourceBuffers.")

MozReview-Commit-ID: EpzSaSg8pWW

--HG--
extra : rebase_source : f4b998ba2a08edabd7eb3607101747ea7fa472d3

MozReview-Commit-ID: C8vMTcWiDJ5

--HG--
extra : rebase_source : 616e6670ba54ed94cd87aecc172976d9ca1e9a52

The tests incorrectly assume that all videos start at 0. However this is often not the case, in particular for the mp4 files.
The buffered range is the intersection of the audio track and the video track. As such, if the video track starts at a later time than 0, the buffered range of the source buffer can't be starting at 0.

Rather than using different videos, we properly use the correct values; this is done to ensure that buffered range are calculated correctly, regardless of the video content.

timestamps verify with mkvinfo utility for webm and ffprobe for mp4.

See issue https://github.com/w3c/web-platform-tests/issues/1939

MozReview-Commit-ID: AMKgJHEJsWr

--HG--
extra : rebase_source : 23420db6acf13e1e12928dfb2057fe9846abfe78

Given that we have a universal unpack method now do not keep 'unzip' in method names.
Also adapt arguments to be better understandable.

MozReview-Commit-ID: ClDB5mSVcI2

--HG--
extra : rebase_source : a98bb26748536115d254842df8257ba050ec8eac

Get rid of external unpack tools (unzip and tar) and use the Python internal classes instead.
This patch only changes this behavior for the base script class but not for custom code in other
test scripts and modules, which would make it too complex. A follow-up bug will be filed instead.

MozReview-Commit-ID: L0eoITlqTdC

--HG--
extra : rebase_source : c8bb3447bece192d6d8cbf3f505f840ec2843112

Test:
- That video decode suspends when enabled and delay is reached.
- That video decode doesn't suspend when disabled.
- That video decode doesn't suspend when video finishes before suspend delay.

These tests need to run from content process to observe the suspend
notifications via nsIObserverService, but access to gBrowser is in
chrome process in e10s. Thus, the reason for loading
background_video_chrome.js into chrome process and invoking functions
via async messages.

MozReview-Commit-ID: 2eE97FEUMPu

--HG--
extra : rebase_source : e48cc4dab54648bf0830f59f346a09ab3fb73f6e

To support mochitests, report change in video decode suspend state via
events mozentervideosuspend/mozexitvideosuspend.

MozReview-Commit-ID: EwMduLzcMVg

--HG--
extra : rebase_source : 5f1fed90964fae182f06d9fb480491728c5f1c97

The mochitest relied that the video track was processed first. Additionally, change for the file with only a single video track as the previous video didn't have aligned segments, making the use of sequence mode useless.
We swap the segment around, which allow to more easily visually inspect the result (counter goes forward and then back)

MozReview-Commit-ID: 33PsrmRF1GL

--HG--
extra : rebase_source : e98a7714f81f5c7913091128b5ee04cf41c2d09b

MozReview-Commit-ID: 2b3EyYCtNai

--HG--
extra : rebase_source : 41396c041ddfba75e381e656b2fa45d427e2a44f

Bug 1293646: [MSE] P2. Only reject a seek request with EOS if it's passed the explicit duration. r=gerald

With MSE, the actual duration is always exact as it is amended when data is added. We do not want to fire ended when we attempt to seek to unbuffered data once endOfStream has been called. Instead we will fire the waiting event.

MozReview-Commit-ID: Cl2uBLk2qRQ

--HG--
extra : rebase_source : 6763c6f5a6e15264e276e486fab4d39491ea7f1b