Apple's submission

Update format-utf-8.htm, everything but UTF-8 should be disallowed.

Update tests for DAP proximity events

Update storagesize6xml.xml

Make tpl2tc.py actually generate the checked-in files

Update from W3C master

Catch up to W3C master

…y-state

Upstream negative-playback-rate.html, positive-playback-rate.html from Blink

Previously, the "stability checker" script would report results for
duplicate test names in the same format as results for non-duplicate test
names, without any additional commentary. For example, a test run for a
test that included two stable subtests with the same name ("test #1") and
one unstable subtest ("test #2") might produce the following output:

    |       Test         |   Subtest |         Results            |                Messages                |
    |--------------------|-----------|----------------------------|----------------------------------------|
    | `/infra/demo.html` | `test #1` | **PASS: 20/10**            |                                        |
    | `/infra/demo.html` | `test #2` | **FAIL: 5/10, PASS: 5/10** | `assert_true: expected true got false` |

Without proper context, these results caused confusion for contributors.

Extend the rendered output to communicate the reason for failure more
directly by including the count of tests in excess, e.g.:

    |       Test         |   Subtest |         Results            |                Messages                |
    |--------------------|-----------|----------------------------|----------------------------------------|
    | `/infra/demo.html` | `test #1` | **PASS: 20/10**, EXCESS:10 |                                        |
    | `/infra/demo.html` | `test #2` | **FAIL: 5/10, PASS: 5/10** | `assert_true: expected true got false` |

…01 of https://codereview.chromium.org/2781623008/ )

Reason for revert:
external/wpt/IndexedDB/parallel-overlapping-cursors.html is failing on the win7 webkit bot: https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%29/builds/9419.

Original issue's description:
> More thorough overlapping cursor tests.
>
> BUG=705837
>
> Review-Url: https://codereview.chromium.org/2781623008
> Cr-Commit-Position: refs/heads/master@{#461932}
> Committed: https://chromium.googlesource.com/chromium/src/+/0c187ee3c2b8fc9d0dd81758f892cf6fd0ba4c3f

TBR=jsbell@chromium.org,dmurph@chromium.org,pwnall@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=705837

Review-Url: https://codereview.chromium.org/2803563002
Cr-Commit-Position: refs/heads/master@{#461991}

Revert of More thorough overlapping cursor tests. (patchset #2 id:60001 of https://codereview.chromium.org/2781623008/ )

Add mime type:extension mapping for media types.

Fix pickling of SourceFile objects

Sync with upstream

Closes #2

Historically, findMediaFile() helped choose the right extension based
on what the browser could play. Chromium cannot play some proprietary
formats (h264, aac, etc), so this check would choose the .ogv format
in that case.

But things have gotten crufty.
1) A long time ago we started running layout tests on builds that *do*
   include proprietary codecs
2) But we lie about that to the tests via
     media::RemoveProprietaryMediaTypesAndCodecsForTests()
   This makes debugging tests a pain because manual execution doesn't
   call this method and its easy to forget that the test wrapper does.
3) Lots of tests never bothered to call findMediaFile anway and just
   hardcoded the use of an mp4 with proprietary codecs, which worked
   because the method in #2 above only changes canPlayType responses,
   it doesn't remove the actual support for proprietary codecs.
4) findMediaFile is about to be busted anyway because it only queries the
   file mime type without supplying codec info. eg
      canPlayType("video/mp4") == "maybe" -> lets use the mp4!
   and even chromium will now "maybe" for this now that we no longer
   consider mp4 proprietary (though codecs like h264 still are!)

So this patch does the following:

1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
   maintains the existing behavior and avoids a massive rebaseline.
2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
   and manual runs now behave the same.
3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
   with various codecs and are duplicated by content and chrome browser
   tests (which is a better place for these checks)
4) Updates mediasource-config-change-mp4-* expectations to expect that
   they should run and pass on *all* platforms (previously just android)

There are still many tests that hard code the use of mp4 files. If we
later desire to see LayoutTests run without proprietary codecs, someone
can transition those tests. No one seems to mind at the moment.

It is also not a goal to make LayoutTests try all the supported codecs.
That is covered by unit/integration tests.

Due to #2 above, a handful of tests in external/wpt/media-source now fail
because they use mp4. Fixing these failures is tracked in Issue 794338.

Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
BUG: 327115,746579,787575,568704,794338

Historically, findMediaFile() helped choose the right extension based
on what the browser could play. Chromium cannot play some proprietary
formats (h264, aac, etc), so this check would choose the .ogv format
in that case.

But things have gotten crufty.
1) A long time ago we started running layout tests on builds that *do*
   include proprietary codecs
2) But we lie about that to the tests via
     media::RemoveProprietaryMediaTypesAndCodecsForTests()
   This makes debugging tests a pain because manual execution doesn't
   call this method and its easy to forget that the test wrapper does.
3) Lots of tests never bothered to call findMediaFile anway and just
   hardcoded the use of an mp4 with proprietary codecs, which worked
   because the method in #2 above only changes canPlayType responses,
   it doesn't remove the actual support for proprietary codecs.
4) findMediaFile is about to be busted anyway because it only queries the
   file mime type without supplying codec info. eg
      canPlayType("video/mp4") == "maybe" -> lets use the mp4!
   and even chromium will now "maybe" for this now that we no longer
   consider mp4 proprietary (though codecs like h264 still are!)

So this patch does the following:

1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
   maintains the existing behavior and avoids a massive rebaseline.
2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
   and manual runs now behave the same.
3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
   with various codecs and are duplicated by content and chrome browser
   tests (which is a better place for these checks)
4) Updates mediasource-config-change-mp4-* expectations to expect that
   they should run and pass on *all* platforms (previously just android)

There are still many tests that hard code the use of mp4 files. If we
later desire to see LayoutTests run without proprietary codecs, someone
can transition those tests. No one seems to mind at the moment.

It is also not a goal to make LayoutTests try all the supported codecs.
That is covered by unit/integration tests.

Due to #2 above, a handful of tests in external/wpt/media-source now fail
because they use mp4. Fixing these failures is tracked in Issue 794338.

Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
BUG: 327115,746579,787575,568704,794338
Reviewed-on: https://chromium-review.googlesource.com/807604
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523821}

Historically, findMediaFile() helped choose the right extension based
on what the browser could play. Chromium cannot play some proprietary
formats (h264, aac, etc), so this check would choose the .ogv format
in that case.

But things have gotten crufty.
1) A long time ago we started running layout tests on builds that *do*
   include proprietary codecs
2) But we lie about that to the tests via
     media::RemoveProprietaryMediaTypesAndCodecsForTests()
   This makes debugging tests a pain because manual execution doesn't
   call this method and its easy to forget that the test wrapper does.
3) Lots of tests never bothered to call findMediaFile anway and just
   hardcoded the use of an mp4 with proprietary codecs, which worked
   because the method in #2 above only changes canPlayType responses,
   it doesn't remove the actual support for proprietary codecs.
4) findMediaFile is about to be busted anyway because it only queries the
   file mime type without supplying codec info. eg
      canPlayType("video/mp4") == "maybe" -> lets use the mp4!
   and even chromium will now "maybe" for this now that we no longer
   consider mp4 proprietary (though codecs like h264 still are!)

So this patch does the following:

1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
   maintains the existing behavior and avoids a massive rebaseline.
2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
   and manual runs now behave the same.
3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
   with various codecs and are duplicated by content and chrome browser
   tests (which is a better place for these checks)
4) Updates mediasource-config-change-mp4-* expectations to expect that
   they should run and pass on *all* platforms (previously just android)

There are still many tests that hard code the use of mp4 files. If we
later desire to see LayoutTests run without proprietary codecs, someone
can transition those tests. No one seems to mind at the moment.

It is also not a goal to make LayoutTests try all the supported codecs.
That is covered by unit/integration tests.

Due to #2 above, a handful of tests in external/wpt/media-source now fail
because they use mp4. Fixing these failures is tracked in Issue 794338.

Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
BUG: 327115,746579,787575,568704,794338
Reviewed-on: https://chromium-review.googlesource.com/807604
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523821}

This reverts commit 99e6ba383f1c2963eb5f3b93c5ef243c07a8240d.

Reason for revert: Broke chromium bots that aren't in CQ and dont have proprietary codecs.

https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_Trusty/37231/layout-test-results/results.html

Will add feature detection to those mp4 tests and re-land

Original change's description:
> Stop using findMediaFile(...) in LayoutTests
>
> Historically, findMediaFile() helped choose the right extension based
> on what the browser could play. Chromium cannot play some proprietary
> formats (h264, aac, etc), so this check would choose the .ogv format
> in that case.
>
> But things have gotten crufty.
> 1) A long time ago we started running layout tests on builds that *do*
>    include proprietary codecs
> 2) But we lie about that to the tests via
>      media::RemoveProprietaryMediaTypesAndCodecsForTests()
>    This makes debugging tests a pain because manual execution doesn't
>    call this method and its easy to forget that the test wrapper does.
> 3) Lots of tests never bothered to call findMediaFile anway and just
>    hardcoded the use of an mp4 with proprietary codecs, which worked
>    because the method in #2 above only changes canPlayType responses,
>    it doesn't remove the actual support for proprietary codecs.
> 4) findMediaFile is about to be busted anyway because it only queries the
>    file mime type without supplying codec info. eg
>       canPlayType("video/mp4") == "maybe" -> lets use the mp4!
>    and even chromium will now "maybe" for this now that we no longer
>    consider mp4 proprietary (though codecs like h264 still are!)
>
> So this patch does the following:
>
> 1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
>    maintains the existing behavior and avoids a massive rebaseline.
> 2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
>    and manual runs now behave the same.
> 3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
>    with various codecs and are duplicated by content and chrome browser
>    tests (which is a better place for these checks)
> 4) Updates mediasource-config-change-mp4-* expectations to expect that
>    they should run and pass on *all* platforms (previously just android)
>
> There are still many tests that hard code the use of mp4 files. If we
> later desire to see LayoutTests run without proprietary codecs, someone
> can transition those tests. No one seems to mind at the moment.
>
> It is also not a goal to make LayoutTests try all the supported codecs.
> That is covered by unit/integration tests.
>
> Due to #2 above, a handful of tests in external/wpt/media-source now fail
> because they use mp4. Fixing these failures is tracked in Issue 794338.
>
> Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
> BUG: 327115,746579,787575,568704,794338
> Reviewed-on: https://chromium-review.googlesource.com/807604
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Reviewed-by: Peter Beverloo <peter@chromium.org>
> Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#523821}

TBR=dalecurtis@chromium.org,peter@chromium.org,chcunningham@chromium.org

Change-Id: If11dd9503cfdeeed5033ddb1fc3a22466ea05d4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/825602
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523850}

This reverts commit 99e6ba383f1c2963eb5f3b93c5ef243c07a8240d.

Reason for revert: Broke chromium bots that aren't in CQ and dont have proprietary codecs.

https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_Trusty/37231/layout-test-results/results.html

Will add feature detection to those mp4 tests and re-land

Original change's description:
> Stop using findMediaFile(...) in LayoutTests
>
> Historically, findMediaFile() helped choose the right extension based
> on what the browser could play. Chromium cannot play some proprietary
> formats (h264, aac, etc), so this check would choose the .ogv format
> in that case.
>
> But things have gotten crufty.
> 1) A long time ago we started running layout tests on builds that *do*
>    include proprietary codecs
> 2) But we lie about that to the tests via
>      media::RemoveProprietaryMediaTypesAndCodecsForTests()
>    This makes debugging tests a pain because manual execution doesn't
>    call this method and its easy to forget that the test wrapper does.
> 3) Lots of tests never bothered to call findMediaFile anway and just
>    hardcoded the use of an mp4 with proprietary codecs, which worked
>    because the method in #2 above only changes canPlayType responses,
>    it doesn't remove the actual support for proprietary codecs.
> 4) findMediaFile is about to be busted anyway because it only queries the
>    file mime type without supplying codec info. eg
>       canPlayType("video/mp4") == "maybe" -> lets use the mp4!
>    and even chromium will now "maybe" for this now that we no longer
>    consider mp4 proprietary (though codecs like h264 still are!)
>
> So this patch does the following:
>
> 1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
>    maintains the existing behavior and avoids a massive rebaseline.
> 2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
>    and manual runs now behave the same.
> 3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
>    with various codecs and are duplicated by content and chrome browser
>    tests (which is a better place for these checks)
> 4) Updates mediasource-config-change-mp4-* expectations to expect that
>    they should run and pass on *all* platforms (previously just android)
>
> There are still many tests that hard code the use of mp4 files. If we
> later desire to see LayoutTests run without proprietary codecs, someone
> can transition those tests. No one seems to mind at the moment.
>
> It is also not a goal to make LayoutTests try all the supported codecs.
> That is covered by unit/integration tests.
>
> Due to #2 above, a handful of tests in external/wpt/media-source now fail
> because they use mp4. Fixing these failures is tracked in Issue 794338.
>
> Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
> BUG: 327115,746579,787575,568704,794338
> Reviewed-on: https://chromium-review.googlesource.com/807604
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Reviewed-by: Peter Beverloo <peter@chromium.org>
> Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#523821}

TBR=dalecurtis@chromium.org,peter@chromium.org,chcunningham@chromium.org

Change-Id: If11dd9503cfdeeed5033ddb1fc3a22466ea05d4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/825602
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523850}

…mPoint"

This reverts commit dd944882a245a5117b50cb417138d92f32d931d6.

Reason for revert:
This causes WebKit Linux Trusty ASAN buildbot failure.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20ASAN/builds/8618

23:46:29.565 3877   ==1==ERROR: AddressSanitizer: use-after-poison on address 0x7ead60c0dbf0 at pc 0x00000dca937a bp 0x7ffd86b90c10 sp 0x7ffd86b90c08
23:46:29.565 3877   READ of size 8 at 0x7ead60c0dbf0 thread T0 (content_shell)
23:46:29.565 3877       #0 0xdca9379 in operator==<const blink::TreeScope, const blink::TreeScope> third_party/WebKit/Source/platform/heap/Member.h:128:27
23:46:29.565 3877       #1 0xdca9379 in blink::TreeScope::Retarget(blink::Element const&) const third_party/WebKit/Source/core/dom/TreeScope.cpp:393:0
23:46:29.565 3877       #2 0xdca8894 in blink::TreeScope::HitTestPointInternal(blink::Node*) const third_party/WebKit/Source/core/dom/TreeScope.cpp:267:10
23:46:29.565 3877       #3 0xdca8325 in HitTestPoint third_party/WebKit/Source/core/dom/TreeScope.cpp:254:10
23:46:29.566 3877       #4 0xdca8325 in blink::TreeScope::ElementFromPoint(double, double) const third_party/WebKit/Source/core/dom/TreeScope.cpp:245:0
23:46:29.566 3877       #5 0xc9353a7 in elementFromPoint third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:38:23

Original change's description:
> Fix retargeting of result in elementFromPoint and elementsFromPoint
>
> Currently elementFromPoint and elementsFromPoint are not per spec, and it may
> return null incorrectly. This change adds retargeting of the result with
> respect to the context object, and adds some tests that are similar to
> elementFromPoint tests in WebKit, but with some corrected cases:
> https://git.webkit.org/?p=WebKit-https.git;a=blob;f=LayoutTests/fast/shadow-dom/DocumentOrShadowRoot-prototype-elementFromPoint.html;h=a8dc4da2430713521b9ba77c742db10397a8e638;hb=HEAD
>
> Spec:
> https://w3c.github.io/webcomponents/spec/shadow/#extensions-to-the-documentorshadowroot-mixin
>
> Bug: 759947
> Change-Id: I6aece5e9cc826124772c6ce13c806865055b2b9b
> Reviewed-on: https://chromium-review.googlesource.com/808446
> Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Hayato Ito <hayato@chromium.org>
> Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#531139}

TBR=kochi@chromium.org,dgozman@chromium.org,hayato@chromium.org,pfeldman@chromium.org,rakina@chromium.org

Change-Id: Id62abd371d93627d3178b63ca189cecfe9ff44d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 759947
Reviewed-on: https://chromium-review.googlesource.com/880264
Reviewed-by: Takashi Sakamoto <tasak@google.com>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Commit-Position: refs/heads/master@{#531178}