Apple's submission #2

darobin · 2012-12-20T15:19:52Z

No description provided.

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 [email protected],[email protected],[email protected] # 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 <[email protected]> Reviewed-by: Peter Beverloo <[email protected]> Commit-Queue: Chrome Cunningham <[email protected]> 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 <[email protected]> > Reviewed-by: Peter Beverloo <[email protected]> > Commit-Queue: Chrome Cunningham <[email protected]> > Cr-Commit-Position: refs/heads/master@{#523821} [email protected],[email protected],[email protected] 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 <[email protected]> Commit-Queue: Chrome Cunningham <[email protected]> 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 <[email protected]> > Reviewed-by: Dmitry Gozman <[email protected]> > Reviewed-by: Hayato Ito <[email protected]> > Reviewed-by: Takayoshi Kochi <[email protected]> > Cr-Commit-Position: refs/heads/master@{#531139} [email protected],[email protected],[email protected],[email protected],[email protected] 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 <[email protected]> Commit-Queue: Takashi Sakamoto <[email protected]> Cr-Commit-Position: refs/heads/master@{#531178}

pytest uses: def cm_to_px(cm): return round(cm * 96 / 2.54) js uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. This is what this PR does. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0 The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333....

[pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. This is what this PR does. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0 The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333....

[pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333....

…each time of the loop There are 2 possible scenarios which are not handled by the method. 1. Moving content node to new `<blockquote>` has already been moved to outside of the editing host. 2. There is no container to insert new `<blockquote>`, e.g., in an inline editing host. In the case #1, we should ignore the ex-child node. In the case #2, we should abort it. Note that Chrome inserts `<blockquote>` even if there is no proper container. However, such behavior is disagreed in interop-2023. Therefore, it's okay just to abort it for now. Depends on D180781 Differential Revision: https://phabricator.services.mozilla.com/D180782 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1756237 gecko-commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23 gecko-reviewers: m_kato

…40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d91.

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

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 <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> 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 <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> 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 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <[email protected]> Reviewed-by: Steve Kobes <[email protected]> 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

@page

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

@page

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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711}

@page

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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711}

installed Apple's submission

136109c

Ms2ger added a commit that referenced this pull request Dec 22, 2012

Merge pull request #2 from w3c/submission/Apple

f86a0f8

Apple's submission

Ms2ger merged commit f86a0f8 into master Dec 22, 2012

odinho added a commit that referenced this pull request Apr 4, 2013

Merge pull request #2 from Yaffle/patch-1

a2c707f

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

dontcallmedom added a commit that referenced this pull request Sep 23, 2013

Merge pull request #2 from pjckcs/dap-proximity

4bbc503

Update tests for DAP proximity events

fsasaki added a commit that referenced this pull request Sep 25, 2013

Merge pull request #2 from finnle/patch-2

7f65793

Update storagesize6xml.xml

AFBarstow mentioned this pull request Jan 3, 2014

second-argument-null.html worker test is incorrect #491

Closed

Ms2ger deleted the submission/Apple branch January 24, 2014 17:57

foolip referenced this pull request in foolip/wpt Feb 23, 2014

Merge pull request #2 from foolip/tpl2tc

5942d9c

Make tpl2tc.py actually generate the checked-in files

bzbarsky mentioned this pull request Nov 20, 2015

Test current Realm (still to be defined in more detail) #1381

Merged

jimsch pushed a commit that referenced this pull request May 26, 2016

Merge pull request #2 from w3c/master

f99441f

Update from W3C master

jimsch pushed a commit that referenced this pull request Jul 6, 2016

Merge pull request #2 from w3c/master

5976245

Catch up to W3C master

alancutter pushed a commit to alancutter/web-platform-tests that referenced this pull request Jul 15, 2016

Merge pull request web-platform-tests#2 from suzyh/suzyh-upstream-pla…

517e7cb

…y-state Upstream negative-playback-rate.html, positive-playback-rate.html from Blink

chromium-wpt-export-bot added a commit that referenced this pull request Apr 5, 2017

Merge pull request #5375 from w3c/chromium-export-8a1c41840a

fd56200

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

jgraham pushed a commit that referenced this pull request Apr 13, 2017

Merge pull request #2 from w3c/jgraham/media_constants

91b164f

Add mime type:extension mapping for media types.

jgraham added a commit that referenced this pull request Apr 13, 2017

Merge pull request #2 from w3c/jgraham/sourcefile_pickle

0282a0f

Fix pickling of SourceFile objects

jgraham pushed a commit that referenced this pull request Apr 13, 2017

Merge pull request #2 from jugglinmike/send_raw_request

97fcf19

bert-github added a commit that referenced this pull request Nov 7, 2017

Merge pull request #2 from w3c/master

4fbaa47

Sync with upstream

AutomatedTester referenced this pull request in AutomatedTester/web-platform-tests Dec 1, 2017

Change attr.a to attr.ib

5ce5e48

Closes #2

chromium-wpt-export-bot mentioned this pull request Dec 13, 2017

Stop using findMediaFile(...) in LayoutTests #8672

Merged

chromium-wpt-export-bot mentioned this pull request Dec 13, 2017

Revert "Stop using findMediaFile(...) in LayoutTests" #8679

Merged

chromium-wpt-export-bot mentioned this pull request Jan 23, 2018

Revert "Fix retargeting of result in elementFromPoint and elementsFromPoint" #9132

Merged

thiagowfx mentioned this pull request Jun 12, 2023

[wdspec] browsingContext.print: fix rounding error in page.py test #40504

Merged

moz-wptsync-bot mentioned this pull request Jun 15, 2023

[Gecko Bug 1756237] Make HTMLEditor::HandleHTMLIndentAroundRanges validate DOM tree in each time of the loop #40565

Merged

chromium-wpt-export-bot mentioned this pull request Sep 18, 2023

Fix :has() invalidation bug when removing anchor element's siblings #42012

Merged

bkardell mentioned this pull request Nov 28, 2023

Add tests for ::first-letter and ::first-line with MathML #43334

Merged

chromium-wpt-export-bot mentioned this pull request Apr 19, 2024

Fall back to main thread if scroll hit test is affected by rounded corners #45797

Merged

moz-wptsync-bot mentioned this pull request May 7, 2024

[Gecko Bug 1891783] Fix two more bugs in ShadowDOM Selection #46139

Merged

chromium-wpt-export-bot mentioned this pull request May 14, 2024

Get border/padding from fragment when painting background. #46252

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Apple's submission #2

Apple's submission #2

darobin commented Dec 20, 2012

Apple's submission #2

Apple's submission #2

Conversation

darobin commented Dec 20, 2012