New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 647809 link

Starred by 5 users
Status: Fixed
Owner:
█ wkorman@chromium.org
Last visit > 30 days ago
Closed: Oct 2016
Cc:
ajha@chromium.org
wangxianzhu@chromium.org
█ hmulling@google.com
█ ranjitkan@chromium.org
lizeb@chromium.org
chrishtr@chromium.org
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Composited table cells with collapsed borders have incorrect visual rect.

Reported by jonathan...@gmail.com, Sep 16 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0

Steps to reproduce the problem:
1. Go to http://codepen.io/anon/pen/NRAaYq/ using Chrome  55.0.2862.0 canary (64-bit) on Mac
2. View the output of the codepen
3. Click on the button in the output to see the problem go away and return

What is the expected behavior?
Some of the table rows do not properly display the table cell borders. Some rows do. It seems to repeat in a pattern in my app. In the codepen example the borders just stop displaying a few rows into the table.

What went wrong?
There is something about how the overflow CSS property on one of the wrapper elements is interacting with the table. When the overflow property on the wrapper is "visible" it works fine, when it is "auto" the borders get messed up. There may be some interaction with flex styling as well.

Did this work before? Yes It works fine in the stable Chrome release 53.0.2785.116 (64-bit)

Chrome version:  55.0.2862.0 canary (64-bit)  Channel: canary
OS Version: OS X 10.11
Flash Version: Shockwave Flash 23.0.0.162
Screen Shot 2016-09-16 at 2.48.15 PM.png
249 KB View Download

Comment 1 by manoranj...@chromium.org, Sep 20 2016

Labels: Needs-Bisect

Comment 2 by shrike@chromium.org, Sep 21 2016

Components: -UI Blink
Status: Untriaged (was: Unconfirmed)
It's happening only on Retina, not on a 1x display. Does not seem to occur on my HiDPI Windows laptop.

Comment 3 by dtapu...@chromium.org, Sep 21 2016

Components: -Blink Blink>Paint

Comment 4 by schenney@chromium.org, Sep 21 2016 

Confirmed on Mac Canary. No obvious explanation and it does not reproduce on Linux with --prefer-compositing-to-lcd-text.

We'll wait on the bisect to assign this to someone.

Comment 5 by durga.behera@chromium.org, Sep 23 2016

Cc: lizeb@chromium.org
Labels: -Needs-Bisect hasbisect-per-revision M-55 ReleaseBlock-Stable OS-Windows
Owner: glebl@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on Mac 10.12(retina) and Windows 10 Laptop(dell precision m3800).

Bisect info using new bisect script on Windows 10:
==================================================
Good : 54.0.2816.0
Bad : 54.0.2817.0

https://chromium.googlesource.com/chromium/src/+log/ff04ca96a5fc31ad11fc982a1fe14677c2c6ebe9..89355878d1d8c4b3ece05d3a48070f87de4e5384

Suspect : https://codereview.chromium.org/2178223002
or 
https://codereview.chromium.org/2179783002

glebl/lizeb : Could you please take a look into this if its related to your change.

Note :Don't have a hidpi linux machine to check.
Marked this issue as Releaseblock-stable please modify if not appropriate.

Comment 6 by lizeb@chromium.org, Sep 23 2016 

My change is Android-only, and doesn't touch Blink. Probably not it.
:-)

Comment 7 by ajha@chromium.org, Sep 28 2016

Cc: ajha@chromium.org
glebl@: Could you please take a look at this and update if this is related to your change or not. Add the Needs-Bisect label back if the change is related.

Thank you!

Comment 8 by glebl@chromium.org, Sep 28 2016

Owner: ----
Status: Untriaged (was: Assigned)
just ran the bisect tool on my macbook:
$ python tools/bisect-builds.py --use-local-cache -a mac -g 403382 -b 419063 --verify-range -- --no-first-run --user-data-dir=/tmp http://codepen.io/anon/pen/NRAaYq/

You are probably looking for a change made after 411559 (known good), but no later than 411563 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3831b72130f11ebac151fd4945719f6d7489e048..f7d24bd8050b6bf21e6280f12103f0c311e18f4f

none of my changes are listed in the link above.

the suspected patch listed in comment5 is related to the Worklets feature https://drafts.css-houdini.org/worklets/ which has not been shipped yet. That's why it's very unlikely that it may affect real world websites.

Comment 9 by schenney@chromium.org, Sep 28 2016

Owner: wkorman@chromium.org
Status: Assigned (was: Untriaged)
wkorman, the only potential cause in the revision range from comment #8 is re-enabling the rtree patch. Any chance that's it?

Comment 10 by wkorman@chromium.org, Sep 28 2016 

Possible, I am building on my Retina MacBook Pro currently to investigate, will follow up.

Comment 11 by wkorman@chromium.org, Oct 4 2016 

Reduced test case attached. If browser window is sized so that the full table does not fit horizontally (right edge hidden), the border of the bottom row is not correctly painted.
index.html
437 bytes View Download

Comment 12 by ajha@chromium.org, Oct 10 2016 

Friendly ping to get an update on this from wkorman@.

Comment 13 by wkorman@chromium.org, Oct 12 2016 

Brief update, have been looking at this. Confirmed that http://crrev.com/2225563002 introduced the issue. Previous reduced test case may be over-reduced, attached is an alternate version. Changing overflow from 'auto' to 'visible' fixes issue as noted by original reporter. Don't have cause yet, will update further.
index.html
864 bytes View Download

Comment 14 by wkorman@chromium.org, Oct 12 2016 

Can repro on Linux with --enable-prefer-compositing-to-lcd-text. With the attached yet-further-edited test case, and an 800x600 window, 'c' and 'f' borders are invisible, and parts of 'b' and 'e' as well; the parts of 'b'/'e' that aren't visible are exactly at the right boundary of the second horizontal tile; and 'c'/'f' are totally invisible.

It's not cc::DrawingDisplayItem quickReject at fault. Perhaps something re: scroll adjustment.

current display item list: [{index: 0, client: "0x74affa18258 LayoutBlockFlow DIV", type: "ScrollPaintPhaseChildBlockBackgrounds", currentOffset: [0,0], cacheIsValid: false, visualRect: [0,0 784x239]},
{index: 1, client: "0x74affa40630 LayoutTableCell (relative positioned) TD id='f' class='cell cell--2xl'", type: "DrawingTableCollapsedBorderTopRightBottomLeft", rect: [555.000000,202.000000 279.000000x22.000000], cacheIsValid: true, visualRect: [0,0 279x22]},
{index: 2, client: "0x74affa404f8 LayoutTableCell (relative positioned) TD id='e' class='cell cell--2xl'", type: "DrawingTableCollapsedBorderTopRightBottomLeft", rect: [277.000000,202.000000 279.000000x22.000000], cacheIsValid: true, visualRect: [0,0 279x22]},
{index: 3, client: "0x74affa403c0 LayoutTableCell (relative positioned) TD id='d' class='cell cell--2xl'", type: "DrawingTableCollapsedBorderTopRightBottom", rect: [0.000000,202.000000 278.000000x22.000000], cacheIsValid: true, visualRect: [0,0 278x22]},
{index: 4, client: "0x74affa40288 LayoutTableCell (relative positioned) TD id='c' class='cell cell--2xl'", type: "DrawingTableCollapsedBorderRightBottomLeft", rect: [555.000000,0.000000 279.000000x203.000000], cacheIsValid: true, visualRect: [0,0 279x203]},
{index: 5, client: "0x74affa40150 LayoutTableCell (relative positioned) TD id='b' class='cell cell--2xl'", type: "DrawingTableCollapsedBorderRightBottomLeft", rect: [277.000000,0.000000 279.000000x203.000000], cacheIsValid: true, visualRect: [0,0 279x203]},
{index: 6, client: "0x74affa40018 LayoutTableCell (relative positioned) TD id='a' class='cell'", type: "DrawingTableCollapsedBorderRightBottom", rect: [0.000000,0.000000 278.000000x203.000000], cacheIsValid: true, visualRect: [0,0 278x203]},
{index: 7, client: "0x74affa18258 LayoutBlockFlow DIV", type: "EndScrollPaintPhaseChildBlockBackgrounds", cacheIsValid: false, visualRect: [0,0 784x239]}]
table2.html
737 bytes View Download

Comment 15 by wkorman@chromium.org, Oct 12 2016 

Hacking rtree to ignore visual rect fixes issue. We see a cc raster rtree query that fails to match the border drawing display items, as:

[1:3:1012/144349:2343273656072:ERROR:rtree.cc(97)] RTree::Search [query=509,-1 326x226, root.bounds=0,0 279x203, intersects=0].

Comment 16 by wkorman@chromium.org, Oct 13 2016 

Yet simpler test case.
table2.html
420 bytes View Download

Comment 17 by wkorman@chromium.org, Oct 13 2016 

Table compositing logic is an area requiring research for me to get up to speed. Notes:

Borders painted in TableCellPainter via GraphicsContext with borderRect (557,0 280x21).

'c' portion of graphics layer tree below. gdb tracing appears to confirm that borders are painted into the first layer. Seems odd that visual rects for text are positioned at (0,0) and paint properly whereas borders are similar and do not.

Not yet sure where x=509 comes from for the rtree query in c#15. Spent time tracing tile related logic that produces rects that lead in to the rtree query, need to spend more time looking at how we produce web picture layers from GraphicsLayer.

    {
      "this": "0x3ee89fd9a410",
      "name": "LayoutTableCell (relative positioned) TD id='c'",
      "position": [565, 8],
      "bounds": [279, 20],
      "drawsContent": true,
      "client": "0x3ee89fca2810",
      "compositingReasons": [
        "Scroll parent is not an ancestor",
        "Might overlap other composited content",
        "Layer was separately composited because it could not be squashed."
      ],
      "squashingDisallowedReasons": [
        "Cannot be squashed because this layer has a different clipping container than the squashing layer"
      ]
    },
    {
      "this": "0x3ee89fd9b410",
      "name": "Ancestor Clipping Layer",
      "position": [566, 8],
      "bounds": [226, 20],
      "shouldFlattenTransform": false,
      "client": "0x3ee89fca2910",
      "compositingReasons": [
        "Secondary layer, applies a clip due to a sibling in the compositing tree"
      ],
      "squashingDisallowedReasons": []
    },
    {
      "this": "0x3ee89fd9a610",
      "name": "LayoutBlockFlow (positioned) \u003Cpseudo:before\u003E",
      "position": [1, 1],
      "contentsOpaque": true,
      "drawsContent": true,
      "client": "0x3ee89fca2910",
      "compositingReasons": [
        "Scroll parent is not an ancestor",
        "Might overlap other composited content",
        "Layer was separately composited because it could not be squashed."
      ],
      "squashingDisallowedReasons": [
        "Cannot be squashed because this layer has a different clipping container than the squashing layer"
      ]
    }

Comment 18 by ananthak@google.com, Oct 18 2016

Labels: -hasbisect-per-revision

Comment 19 by wkorman@chromium.org, Oct 18 2016

Cc: wangxianzhu@chromium.org chrishtr@chromium.org
Discussed with chrishtr@ today. Notes:
- collapsed borders are painted by the Table, calling into TableSection -> TableCell classes, but painted in this case to the root graphics layer where the table itself is painted
- the table cells (text) themselves are painted to their individual layers
- the visual rect for the border drawings is thus wrong -- it's at (0,0) as if it's painted within the cell's composited layer, but it should be at top-left of the border rect (~555-ish w/ sample data in above comments, likely, basically, what the cull rect reports).

Rough summary of fix approaches in consideration:
- (something like) change painting of borders and other aspects of table painting to be in the same space as the main table painting, use offsetFromLayoutObject to correct rects for table cell layers
- use cache skipper or similar to allow painting the borders with the main table's graphics layer as display item client, and thus with the correct visual rect. would be less performant as we'd draw borders every time.
- rework painting of cell borders to be painted by the individual cell (but likely to be complex/time consuming to implement) see for reference atotic@ work in  http://crbug.com/125336#c15 

Complexity due to known technical debt in table implementation.

Comment 20 by wkorman@chromium.org, Oct 18 2016 

Correction: cache skipper option would probably use the table (or row?) as the display item client to get the right visual rect. Above are just rough notes to sketch theory.

Comment 21 by wangxianzhu@chromium.org, Oct 18 2016 

One quick resolution of the problem is to paint all collapsed borders as one display item of the table, if the performance degradation is acceptable for PerformanceTests/Paint tests.

 Bug 125336  is unrelated. It is about incorrect background size and origin of cell background.

The previous efforts on collapsed borders were also not towards cell-painted collapsed borders, but to reduce the number of passes and/or painting operations of collapsed borders. Actually cell-painted collasped borders will increase the number of painting operations by 1 to 3 times (each border is painted by each side adjacent cell, and may be painted by each corner adjacent cell).

The previous efforts failed because of
- failure of "corner" cases [1],
- failure of reducing number of passes and/or painting operations,
- or other regressions.

[1] "Corner" cases are really about correct painting of corners, according to https://www.w3.org/TR/REC-CSS2/tables.html#border-conflict-resolution. Will add examples.

Comment 22 by wkorman@chromium.org, Oct 18 2016

Summary: Composited table cells with collapsed borders have incorrect visual rect. (was: table cell borders are not rendered correctly)
More notes from discussion:

- explore making m_collapsedBorderValues in TableCell the DisplayItemClient for collapsed border drawings to provide visual rect. Will need a pointer to table (make sure no lifetime issues) to get the table's visual rect. Use the new DisplayItemClient only when table cell is composited or SPv2 is on. Override LayoutTableCell::invalidateDisplayItemClients() to also invalidate the collapsed border values DisplayItemClient.

- wangxianzhu@ notes we have an underinvalidation bug where the collapsed border of a cell that's composited does not get invalidated properly. I'll file this separately for consideration.  http://crbug.com/657074

Comment 23 by wkorman@chromium.org, Oct 18 2016

Cc: hmulling@google.com
http://crbug.com/656148 is potentially related though it appears to also exhibit selection highlight and not-border-specific invalidation issues. I am looking at that case more closely now.

Comment 24 by wkorman@chromium.org, Oct 18 2016 

Issue 656148 has been merged into this issue.

Comment 25 by wkorman@chromium.org, Oct 19 2016 

Adding initial work on test to demonstrate composited collapsed table background painting. Can't upload to change https://codereview.chromium.org/2432663002/ in work as 'git cl upload' is down  http://crbug.com/657216 .
composited-collapsed-table-background.html
569 bytes View Download

Comment 26 by wkorman@chromium.org, Oct 19 2016 

Update:
- http://crrev.com/2432663002 is in the CQ to fix missing collapsed borders
- wangxianzhu@ is exploring http://crrev.com/2430313004 as a larger fix for same with perf benefits (and different tradeoffs)
- I will look at separate change for the background painting bug (c#23 - 25 with test case in c#25). May break into separate bug.
- wangxianzhu@ believes we've had the darker borders where we overpaint collapsed borders with opacity for a while. I'll look for existing bug or file new.
Project Member

Comment 27 by bugdroid1@chromium.org, Oct 20 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1bb139a99a8e140b56c3583cd5d133581a5ed906

commit 1bb139a99a8e140b56c3583cd5d133581a5ed906
Author: wkorman <wkorman@chromium.org>
Date: Thu Oct 20 07:58:50 2016

Use table as display item client for painting composited collapsed table cell borders.

BUG= 647809 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2432663002
Cr-Commit-Position: refs/heads/master@{#426428}

[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/paint/tables/composited-collapsed-table-borders.html
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.txt
[modify] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/Source/core/layout/LayoutTableCell.cpp
[modify] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/Source/core/layout/LayoutTableCell.h
[modify] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/Source/core/paint/TableCellPainter.cpp
[modify] https://crrev.com/1bb139a99a8e140b56c3583cd5d133581a5ed906/third_party/WebKit/Source/core/paint/TableCellPainter.h

Comment 28 by ranjitkan@chromium.org, Oct 24 2016

Cc: ranjitkan@chromium.org
Labels: -Type-Bug TE-Verified-56.0.2899.0 TE-Verified-M56 Type-Bug-Regression
Rechecked this issue on Windows 10, MAC 10.11.6, Ubuntu 14.04 (With Flag enabled --enable-prefer-compositing-to-lcd-text) for chrome version 56.0.2899.0. Fix is working as intended. Table borders are displayed properly. Attached a screenshot for the same.

Adding TE-Verified labels, Can we have the CL merged to M55.?

Thanks.!
Table_border.png
56.3 KB View Download

Comment 29 by wkorman@chromium.org, Oct 24 2016

Labels: Merge-Request-55
Requesting merge of https://chromiumcodereview.appspot.com/2432663002 to M55, fix was verified in c#28.

Comment 30 by dimu@chromium.org, Oct 24 2016

Labels: -Merge-Request-55 Merge-Approved-55 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M55 (branch: 2883)
Project Member

Comment 31 by bugdroid1@chromium.org, Oct 24 2016

Labels: -merge-approved-55 merge-merged-2883
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b6347287f6be2408d1fb0167a153f1ab2f355e9

commit 6b6347287f6be2408d1fb0167a153f1ab2f355e9
Author: Walter Korman <wkorman@chromium.org>
Date: Mon Oct 24 20:47:13 2016

Use table as display item client for painting composited collapsed table cell borders.

BUG= 647809 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2432663002
Cr-Commit-Position: refs/heads/master@{#426428}
(cherry picked from commit 1bb139a99a8e140b56c3583cd5d133581a5ed906)

Review URL: https://codereview.chromium.org/2443393002 .

Cr-Commit-Position: refs/branch-heads/2883@{#258}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/paint/tables/composited-collapsed-table-borders.html
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.txt
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.h
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.h
Project Member

Comment 32 by bugdroid1@chromium.org, Oct 24 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b6347287f6be2408d1fb0167a153f1ab2f355e9

commit 6b6347287f6be2408d1fb0167a153f1ab2f355e9
Author: Walter Korman <wkorman@chromium.org>
Date: Mon Oct 24 20:47:13 2016

Use table as display item client for painting composited collapsed table cell borders.

BUG= 647809 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2432663002
Cr-Commit-Position: refs/heads/master@{#426428}
(cherry picked from commit 1bb139a99a8e140b56c3583cd5d133581a5ed906)

Review URL: https://codereview.chromium.org/2443393002 .

Cr-Commit-Position: refs/branch-heads/2883@{#258}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/paint/tables/composited-collapsed-table-borders.html
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.txt
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.h
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.h

Comment 33 by wkorman@chromium.org, Oct 24 2016

Status: Fixed (was: Assigned)
Follow-up on c#26:

-  http://crbug.com/626748  tracks at least two known cases of under-invalidation of collapsed borders
-  http://crbug.com/548903  appears to track over-painting of collapsed borders with opacity and notes this is a non-regression issue seen since M30
- Filed  http://crbug.com/658874  to track the sometimes missing painting of composited collapsed table cell backgrounds. **NOTE** this one may warrant M-55 ReleaseBlock-Stable, I have not yet validated that the issue was not present in M53.

Marking this bug as fixed, but expecting wangxianzhu@ to continue exploring his alternate work in http://crrev.com/2430313004.

Comment 34 by ranjitkan@chromium.org, Oct 26 2016

Labels: TE-Verified-M55 TE-Verified-55.0.2883.28
Rechecked this issue on Windows 10, MAC 10.11.6, Ubuntu 14.04 (With Flag enabled --enable-prefer-compositing-to-lcd-text) for chrome version 55.0.2883.28. Merge of the fix is working as intended. Table borders are displayed properly. Attached a screenshot for the same.

Adding TE-Verified labels.

Thanks.!
Screen Shot 2016-10-26 at 4.04.51 PM.png
252 KB View Download
Project Member

Comment 35 by bugdroid1@chromium.org, Oct 27 2016

Labels: merge-merged-2840
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b6347287f6be2408d1fb0167a153f1ab2f355e9

commit 6b6347287f6be2408d1fb0167a153f1ab2f355e9
Author: Walter Korman <wkorman@chromium.org>
Date: Mon Oct 24 20:47:13 2016

Use table as display item client for painting composited collapsed table cell borders.

BUG= 647809 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2432663002
Cr-Commit-Position: refs/heads/master@{#426428}
(cherry picked from commit 1bb139a99a8e140b56c3583cd5d133581a5ed906)

Review URL: https://codereview.chromium.org/2443393002 .

Cr-Commit-Position: refs/branch-heads/2883@{#258}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/paint/tables/composited-collapsed-table-borders.html
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/linux/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/mac/paint/tables/composited-collapsed-table-borders-expected.txt
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.png
[add] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/LayoutTests/platform/win/paint/tables/composited-collapsed-table-borders-expected.txt
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/layout/LayoutTableCell.h
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.cpp
[modify] https://crrev.com/6b6347287f6be2408d1fb0167a153f1ab2f355e9/third_party/WebKit/Source/core/paint/TableCellPainter.h

Comment 36 by dimu@google.com, Nov 4 2016

Labels: -merge-merged-2840
[Automated comment] removing mislabelled merge-merged-2840
►

Sign in to add a comment