This is a special case of issue 803649.

Now the first column has correct clip applied. The paintings in the second column are still missing which is independent with bug 803649.

Issue 797779 has been merged into this issue.

I'm combining bug 797779 into this bug I think the root cause is the same: some multicol contents don't know they are fragmented because PaintLayer::EnclosingPaginationContainer() doesn't cross some boundaries.

Actually we don't have problem for normal svgs under multicol.

We just have problem for the following cases:
1. svg foreign object;
2. svg under svg;
3. iframes.

The problem is that the object shows only in the first column, including the bigger problem that the object won't show if it starts in a column other than the first. In other words, the problem has two levels:
1. Visibility of the object in column other than the first, regardless of fragmentation.
2. Fragmentation of the object.

I will fix 1 as the first step.

Firefox doesn't break inside of any of the above elements (as well as many other replaced elements, e.g. img), as if they have break-inside:avoid.

break-inside:avoid seems not working in Chromium for now.

Possible solutions to the fragmentation problem:
a) Support break-inside:avoid, and force it for these elements; or
b) Fix bugs in breaking these elements into fragments.

Discussed with chrishtr@ yesterday and we are inclined to a). My might just leave the work to layout_ng. mstensho@ do you have any suggestions?

I'm restoring this bug back to original "multicol SVG" because multicol iframe is very different. Fixing multicol SVG will be simple.

But we're talking about replaced content (SVG, iframes), and they kinda already have break-inside:avoid implied. Actually, in the engine, we try even harder to avoid breaking than for break-inside:avoid (because "avoid" doesn't mean "forbidden").

That said, we sometimes need to slice content like that over multiple columns, if the columns are too short. This type of content is not considered monolithic by the spec and is not supposed to be fragmented, so that rules out option b), I guess.

[1] https://www.w3.org/TR/css-break-3/#end-block

Thanks mstensho@ for the replies. Now I understand the issues.

I'm redistributing the problems between the two bugs again: this bug will be about the issue that some elements are invisible in column other than the first. Bug 797779 will be about slicing of replaced elements.

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

commit c019098bb2c71e928b711657467611defdd97826
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Thu Apr 26 00:30:41 2018

Remove fast/multicol/multicol-svg.html

It's not a valid test case. According to the spec, SVG elements are
considered monolithic and are not supposed to be fragmented. The current
"slicing" behavior will be fixed in layout_ng.

https://www.w3.org/TR/css-break-3/#end-block

Bug:  807382 
Change-Id: I3cd1c8f09341952fd981fabfe8a81d2873665a1e
Reviewed-on: https://chromium-review.googlesource.com/1028933
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553847}
[modify] https://crrev.com/c019098bb2c71e928b711657467611defdd97826/third_party/WebKit/LayoutTests/TestExpectations
[delete] https://crrev.com/cf0de43ad823e4c19e8d3eb3732b66dfea5a3e8a/third_party/WebKit/LayoutTests/fast/multicol/multicol-svg-expected.html
[delete] https://crrev.com/cf0de43ad823e4c19e8d3eb3732b66dfea5a3e8a/third_party/WebKit/LayoutTests/fast/multicol/multicol-svg.html

Actually we can display SVG starting in a column other than the first correctly, if it doesn't overflow the column in the block direction. For SVG overflowing the column in the block direction, either slicing (SPv1) or simply clipping (SPv175) is incorrect per the spec. Let's leave the issue to layout_ng to fix.