third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html - Issue 1676933004: Table cell background painting

Unified Diff: third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html

Issue 1676933004: Table cell background painting (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: LayoutTableCol::clippedOverflowRectForPaintInvalidation fix Created 4 years, 9 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

Index: third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html

diff --git a/third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html b/third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html

index b3fbc11f958dd9c8c363b3a0c766d11adb00cf00..7dff12ba6f08922f6c4a6ba06be2cea02a02f23c 100644

--- a/third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html

+++ b/third_party/WebKit/LayoutTests/fast/repaint/table-col-background.html

@@ -10,6 +10,7 @@

</script>

</head>

+ <div style="height:100px"></div>

Xianzhu 2016/03/14 20:40:18 Normally we don't change existing tests, but add n

atotic1 2016/03/15 16:50:48 I've scheduled a try job, and it failed as expecte

Xianzhu 2016/03/15 17:24:39 Please rebaseline expectations and upload again an

Please rebaseline expectations and upload again and optionally try (which can save time for landing the CL because commit-queue will skip green bots). What I suggested are mainly for ease of review and CL development. For reviewer, it's easier to see expectation diffs from try results. For developer, it's easier to know what tests will fail with the change without running all layout tests on all platforms by himself/herself. For a small number of tests, you can either try first then rebaseline, or upload rebaselined expectation directly. I believe most reviewers would be happen with either way. For the latter way, if there are pixel rebaselines, you'd better tell reviewers what changed. For a large number of layout tests needing rebaselined, it's always better to upload the change without rebaselined expectations first, run try bots, analyze the result, rebaseline tests if the failures are expected [1], upload again and try. Reviewers can see the expectation diffs from the previous try result (normally you need to tell reviewer where to see the results). [1] You have two ways to rebaseline tests 1. run-webkit-tests --reset-results <tests>. Suits: small number of tests; the tests produce the same results on all platforms (or expectation changes on other platforms are know) 2. Mark tests 'NeedsRebaseline' in TestExpectations. Suits: otherwise. A rebaseline bot will rebaseline the tests on all platforms for you after the CL is landed. For this method, you should run try job first and tell reviewer, or tell the reviewer what will change.

<table>

<tr>

« no previous file with comments | « no previous file | third_party/WebKit/Source/core/layout/LayoutTableCol.cpp » ('j') | third_party/WebKit/Source/core/layout/LayoutTableCol.cpp » ('J')