-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apple's submission #2
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
odinho
added a commit
that referenced
this pull request
Apr 4, 2013
Update format-utf-8.htm, everything but UTF-8 should be disallowed.
dontcallmedom
added a commit
that referenced
this pull request
Sep 23, 2013
Update tests for DAP proximity events
foolip
referenced
this pull request
in foolip/wpt
Feb 23, 2014
Make tpl2tc.py actually generate the checked-in files
alancutter
pushed a commit
to alancutter/web-platform-tests
that referenced
this pull request
Jul 15, 2016
…y-state Upstream negative-playback-rate.html, positive-playback-rate.html from Blink
jugglinmike
referenced
this pull request
in bocoup/wpt
Mar 31, 2017
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` |
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 5, 2017
…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}
chromium-wpt-export-bot
added a commit
that referenced
this pull request
Apr 5, 2017
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
Add mime type:extension mapping for media types.
jgraham
added a commit
that referenced
this pull request
Apr 13, 2017
Fix pickling of SourceFile objects
jgraham
pushed a commit
that referenced
this pull request
Apr 13, 2017
AutomatedTester
referenced
this pull request
in AutomatedTester/web-platform-tests
Dec 1, 2017
Closes #2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Dec 13, 2017
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Dec 13, 2017
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Dec 13, 2017
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Dec 13, 2017
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Dec 13, 2017
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Jan 23, 2018
…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}
thiagowfx
added a commit
that referenced
this pull request
Jun 12, 2023
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....
thiagowfx
added a commit
that referenced
this pull request
Jun 12, 2023
[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....
thiagowfx
added a commit
that referenced
this pull request
Jun 12, 2023
[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....
thiagowfx
added a commit
that referenced
this pull request
Jun 13, 2023
[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....
moz-wptsync-bot
pushed a commit
that referenced
this pull request
Jun 15, 2023
…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
moz-wptsync-bot
pushed a commit
that referenced
this pull request
Jun 16, 2023
…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
DanielRyanSmith
pushed a commit
that referenced
this pull request
Jun 16, 2023
…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.
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Sep 18, 2023
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Sep 18, 2023
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Sep 19, 2023
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Sep 19, 2023
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}
Lightning00Blade
pushed a commit
to Lightning00Blade/wpt
that referenced
this pull request
Dec 11, 2023
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 19, 2024
…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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 22, 2024
…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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 23, 2024
…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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 23, 2024
…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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Apr 23, 2024
…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}
moz-wptsync-bot
pushed a commit
that referenced
this pull request
May 7, 2024
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
moz-wptsync-bot
pushed a commit
that referenced
this pull request
May 13, 2024
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
moz-wptsync-bot
pushed a commit
that referenced
this pull request
May 14, 2024
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
May 14, 2024
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
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
May 14, 2024
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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
May 14, 2024
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}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.