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}

This CL fixes a :has() invalidation bug when the following conditions
are met:

1. A style rule uses a :has() pseudo class. The :has() test result is
   affected by the anchor element's relationship to its sibling
   element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
   didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
   match the anchor element.
   (e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
   the anchor element. (e.g. 'target.remove();')

For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.

To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.

Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.

To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.

Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <blee@igalia.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198137}

This CL fixes a :has() invalidation bug when the following conditions
are met:

1. A style rule uses a :has() pseudo class. The :has() test result is
   affected by the anchor element's relationship to its sibling
   element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
   didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
   match the anchor element.
   (e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
   the anchor element. (e.g. 'target.remove();')

For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.

To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.

Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.

To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.

Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <blee@igalia.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198137}

This CL fixes a :has() invalidation bug when the following conditions
are met:

1. A style rule uses a :has() pseudo class. The :has() test result is
   affected by the anchor element's relationship to its sibling
   element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
   didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
   match the anchor element.
   (e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
   the anchor element. (e.g. 'target.remove();')

For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.

To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.

Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition web-platform-tests#2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.

To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.

Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <blee@igalia.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198137}

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1291538}

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1291538}

Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use
the shadow tree of web-exposed shadow root, instead of using
light DOM elements of the host.

Bug #2: aRange could possibly create mCrossShadowBoundaryRange
first (due to boundaries are in different tree), and later
moves the boundaries to the same tree. When this happens, we
should remove mCrossShadowBoundaryRange and use the default
range to represent it.

Differential Revision: https://phabricator.services.mozilla.com/D207608

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783
gecko-commit: 515d309fa9735aafa20ea7286a07ca4be1370059
gecko-reviewers: jjaschke, smaug, dom-core

Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use
the shadow tree of web-exposed shadow root, instead of using
light DOM elements of the host.

Bug #2: aRange could possibly create mCrossShadowBoundaryRange
first (due to boundaries are in different tree), and later
moves the boundaries to the same tree. When this happens, we
should remove mCrossShadowBoundaryRange and use the default
range to represent it.

Differential Revision: https://phabricator.services.mozilla.com/D207608

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783
gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f
gecko-reviewers: jjaschke, smaug, dom-core

Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use
the shadow tree of web-exposed shadow root, instead of using
light DOM elements of the host.

Bug #2: aRange could possibly create mCrossShadowBoundaryRange
first (due to boundaries are in different tree), and later
moves the boundaries to the same tree. When this happens, we
should remove mCrossShadowBoundaryRange and use the default
range to represent it.

Differential Revision: https://phabricator.services.mozilla.com/D207608

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783
gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f
gecko-reviewers: jjaschke, smaug, dom-core

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    #3 blink::LayoutBoxModelObject::PaddingTop()
    #4 blink::LayoutBoxModelObject::PaddingOutsets()
    #5 blink::BoxPainterBase::PaintFillLayer()
    #6 blink::BoxPainterBase::PaintFillLayers()
    #7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    #3 blink::LayoutBoxModelObject::PaddingTop()
    #4 blink::LayoutBoxModelObject::PaddingOutsets()
    #5 blink::BoxPainterBase::PaintFillLayer()
    #6 blink::BoxPainterBase::PaintFillLayers()
    #7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    #3 blink::LayoutBoxModelObject::PaddingTop()
    #4 blink::LayoutBoxModelObject::PaddingOutsets()
    #5 blink::BoxPainterBase::PaintFillLayer()
    #6 blink::BoxPainterBase::PaintFillLayers()
    #7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}

See https://drafts.csswg.org/css-pseudo-4/#first-text-line

1. For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.

2. Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do #1 if it establishes an
inline formatting context. Otherwise, do #2.

In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".

There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".

This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.

The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.

This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.

Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69

See https://drafts.csswg.org/css-pseudo-4/#first-text-line

1. For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.

2. Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do #1 if it establishes an
inline formatting context. Otherwise, do #2.

In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".

There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".

This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.

The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.

This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.

Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1373765}

See https://drafts.csswg.org/css-pseudo-4/#first-text-line

1. For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.

2. Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do #1 if it establishes an
inline formatting context. Otherwise, do #2.

In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".

There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".

This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.

The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.

This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.

Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1373765}

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482
Reviewed-by: Yifan Luo <lyf@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1385522}

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482
Reviewed-by: Yifan Luo <lyf@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1385522}

This patch teaches the network service's `URLLoader` how to evaluate the
SRI-valid subset of HTTP Message Signatures, blocking mismatched
responses once headers are received and processed.

This check is implemented behind a new feature flag, which is disabled
by default. End-to-end tests live in web platform tests under
//web_tests/virtual/sri-message-signatures that enables the flag.

This is part of a chain of CLs implementing this feature (#2 from
https://wicg.github.io/signature-based-sri/#overview):

1.  [Parsing] https://crrev.com/c/6020612
2.  [Validation 1] https://crrev.com/c/6030571
3.  [Validation 2] https://crrev.com/c/6032589
4.  [Enforcement] https://crrev.com/c/6038714 [You are here]

    `url_loader.cc` are the only meaningful changes in behavior
    reported as undercovered. These are tested through the WPT
    included in this CL.

Bug: 379534943
Low-Coverage-Reason: COVERAGE_UNDERREPORTED The changes to
Change-Id: I6ece80da25ed4329a6f976c2c74c639c2799b856
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038714
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389294}

This patch teaches the network service's `URLLoader` how to evaluate the
SRI-valid subset of HTTP Message Signatures, blocking mismatched
responses once headers are received and processed.

This check is implemented behind a new feature flag, which is disabled
by default. End-to-end tests live in web platform tests under
//web_tests/virtual/sri-message-signatures that enables the flag.

This is part of a chain of CLs implementing this feature (#2 from
https://wicg.github.io/signature-based-sri/#overview):

1.  [Parsing] https://crrev.com/c/6020612
2.  [Validation 1] https://crrev.com/c/6030571
3.  [Validation 2] https://crrev.com/c/6032589
4.  [Enforcement] https://crrev.com/c/6038714 [You are here]

    `url_loader.cc` are the only meaningful changes in behavior
    reported as undercovered. These are tested through the WPT
    included in this CL.

Bug: 379534943
Low-Coverage-Reason: COVERAGE_UNDERREPORTED The changes to
Change-Id: I6ece80da25ed4329a6f976c2c74c639c2799b856
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038714
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389294}