I have a question: what's the difference between css clip and clip-path with a rectangular path?

I'm raising priority because we have enabled the code on M-58 and this is a regression.

Short answer: CSS clip-path is a grouping property, CSS clip is not.

Long answer:

CSS clip applies to all DOM descendants, but does not force stacking context. i.e. it may apply to elements that don't paint into it. In some sense it shares some similarity to overflow clips, thus implemented as clip nodes.

CSS clip-path implies stacking context, and apply to the stacking context as a group, thus implemented as effect nodes.
----
As for property invalidation for masks and clip-path, I already replied on the code review, but I'll re-post here for tracking:

Property node invalidation will be needed for clip-path as well, and definitely is needed for masks. (Because masks implicitly create a clip, which is implemented by clip node.)

I think it makes sense for LayoutBox::sizeChanged() to match LayoutBox::paintedOutputOfObjectHasNoEffectRegardlessOfSize(). https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutBox.cpp?rcl=d37bf2eb3912ef5c89a512f294ee3e4b8546e653&l=2307

Adding releaseblock-stable. I think fixing it will be very easy.

After investigation, I concluded that issue won't affect normal flags, thus removing the blocker. Nevertheless it is still a problem for SPv2 and I should fix it.

It is okay for SPv1 because the implicit clip by mask and clip-path were never considered by PaintLayerClipper since the beginning, and their property nodes were not generated in SPv1 anyway. (And yes, therefore we have a filter bug that visual overflow could leak out the mask box, but it's not a new regression.)

For SPv2 there were multiple screw-ups I should fix... First I forgot to update FindObjectPropertiesNeedingUpdateScope to check for new property nodes added for mask. Second LayoutBox::paintedOutputOfObjectHasNoEffectRegardlessOfSize() should not skip mask and clip-path check on SPv2, because the implementation actually generates DrawingDisplayItems for them. Third the property nodes should be invalidated on LayoutBox::sizeChanged().

wangxianzhu@: By the way do you know why setNeedsPaintPropertyUpdate() was invoked during LayoutBox::sizeChanged()? I mean, why couldn't it be delayed until invalidation-after-layout? Actually I think it's not quite right because location change should also invalidate property nodes?

This is a good question. We chose different ways to handle paint property updates for size change and location change, because when didn't have LayoutBox::previousSize(), and paint invalidator saved previousBorderBoxSize only when it is needed by paint invalidation and that was not suitable for paint property update. Now it's possible to move the logic in LayoutBox::sizeChanged() into PaintPropertyTreeBuilder::updateForObjectLocation() because we save LayoutBox::previousSize() unconditionally. (Note that this implies a dependency of paint property update to mayNeedPaintInvalidation() because we need the latter to trigger tree walk to the object needing size/location change detection.)  pdr@ wdyt?

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

commit 666abc33c97400adfa53065f50364d8cbeadd89a
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Thu Mar 02 19:48:12 2017

Handle resize in PaintPropertyTreeBuilder::updateForObjectSizeAndLocation()

Also fix a bug exposed by the change: under-invalidation of paint
properties when scrollable contents size changes.

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

Review-Url: https://codereview.chromium.org/2729683002
Cr-Commit-Position: refs/heads/master@{#454348}

[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/frame/FrameView.h
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.cpp
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.h
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/core/paint/PaintPropertyTreeUpdateTests.cpp
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/platform/scroll/ScrollableArea.h
[modify] https://crrev.com/666abc33c97400adfa53065f50364d8cbeadd89a/third_party/WebKit/Source/platform/scroll/Scrollbar.cpp

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

commit b381061316947dbceed438908696566dc32fc44e
Author: trchen <trchen@chromium.org>
Date: Wed Mar 08 01:10:20 2017

[SPv2] Fix property node invalidation for CSS masks

When CSS masks were implemented a while back, invalidation wasn't implemented
at all. This CL is an amendment and also added under-invalidation checks.

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

Review-Url: https://codereview.chromium.org/2736463002
Cr-Commit-Position: refs/heads/master@{#455317}

[modify] https://crrev.com/b381061316947dbceed438908696566dc32fc44e/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/b381061316947dbceed438908696566dc32fc44e/third_party/WebKit/Source/core/paint/FindPropertiesNeedingUpdate.h
[modify] https://crrev.com/b381061316947dbceed438908696566dc32fc44e/third_party/WebKit/Source/core/paint/ObjectPaintProperties.h
[modify] https://crrev.com/b381061316947dbceed438908696566dc32fc44e/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.cpp
[modify] https://crrev.com/b381061316947dbceed438908696566dc32fc44e/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilderTest.cpp

Regression status was removed in Comment #8.

Oh, and I forgot to close it. :)