Thanks for the report.. 

@jingyang.crystal-- Could you please provide us the sample test file /url/jsfiddle demonstrating the issue for better traiging purpose and possible help us with th expected result screenshot.

Thanks!

please check this url https://jsfiddle.net/crystalyang/oqkrb2xq/ 

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

minimised test case with computed style info: https://jsfiddle.net/oqkrb2xq/2/

able to repro on TOT and chrome stable 60.0.3112.101 on Linux.

the computed style of the offending section shows the correct value for -webkit-box-reflect, so probably not a css issue. rerouting to paint.

Able to reproduce the issue on windows 7 , ubuntu 14.04 and mac os 10.122.6 using chrome M60 #60.0.3112.133 and M62 #62.0.3198.0 .

This is a regression issue broken in M60.

Using the  bisect providing the bisect results,
Good build: 60.0.3096.0 (Revision: 470759).
Bad build: 60.0.3098.0 (Revision: 471507).

You are probably looking for a change made after 471365 (known good), but no later than 471389 (first known bad).

CHANGELOG URL:

  https://chromium.googlesource.com/chromium/src/+log/43f24f8751ec2d4d056623977fb49adc6dce18ae..e2642266f1c0a106aa68d95bc9900cdd78cd5237

From the CL above, unable to find the suspect ,

@could someone from dv help us in assigning it to the concern owner.

Thanks!

Nothing is obvious in the bisect. I'll try again.

I get https://chromium.googlesource.com/chromium/src/+log/8c71696aec54efa672bbcc4f4fae36ce5dbea791..f6c17fed3694e3d76683cdb3ac652803f5aa3c47, or 471379 last known good to 471393 first known bad.

That overlaps the already given range with 471380 - 471389.

It is very hard to see what might be to blame, apart from maybe https://chromium.googlesource.com/chromium/src/+/ad2bef1e6dd219c8b8e1fbe58b86a896550634c9 revealing a problem that was always there. I'll investigate that possibility.

It's only broken in the compositor path - transform(0, 0) works, transform3d(0, 0, 0) does not. Nevertheless, maybe it was the Skia roll?

https://skia.googlesource.com/skia.git/+log/07454223d68c..d45afc036484

There is no Skia roll in my bisect, and I've verified that twice. The Skia roll also does not seem to have anything that would cause this. And it's not quirks mode or anything like that.

I have no idea. We probably need to debug from scratch looking at the code that changed in the bisect.

Try a manual bisect down to a revision with a local git repo?

Yeah, I suppose that's the only way. More fun with git.

Observation 1: It's only broken if the reflection has a gradient.

The offending change. Now to see what about that change broke things.

https://chromium.googlesource.com/chromium/src/+/b06d81fdf9fc3a85fe95aa3ef9cd1d7de09758c8

And the patch can't easily be reverted.

The offending change is "Compile Skia encoders", so I take it webkit-box-reflect is implemented by encoding? (and it truly gets broken later, when we use Skia encoders more generally?)

Adding liyuqian@, who took over encoding from msarett@

Is that PNG encoding or JPEG encoding? One way to find out is try reverting https://codereview.chromium.org/2944633002/ which will stop using Skia's PNG encoder.

I don't see how the reflect functionality uses image encoding at all. It is implemented using a filter, as far as I know. In the broken case it would be using a filter on the GPU side.

My current guess is that it's a name resolution conflict or some kind of build order issue. Maybe tracing can tell us what is being called.

I believe I've figured this out, here goes:

There's an intersection between the box-reflect code-path and image encoding in that the former uses an SkImageSource (see BuildBoxReflectFilter in SkiaImageFilterBuilder.cpp) as part of the filter chain. The filter chain is flattened/serialized (for passing between processes) which results in the SkImageSource being encoded to PNG.
In the blamed commit, the Skia PNG encoder is enabled. Before that the PNG "encoder" was just a stub return failure, meaning that the data would be serialized in raw form. With SK_HAS_PNG_LIBRARY defined data instead end up being actually encoded as PNG. So far so good.
However, on the deserializating side, went awry since SkImageGenerator_none.cpp is built (for all targets/OSs) the decoding step failed, producing an empty SkImage. Empty SkImages does not make for very interesting masks.
Hooking up/building SkImageGenerator_skia.cpp (and dependencies) instead seems to restore the mask contents. CL coming up.

Thanks for figuring this out! I'm sorry for breaking it with my Skia PNG encoding CL. Should it be caught by some unit tests in the future?

AFAICT, there is (at least) a layout test that would exercise this - I suspect it actually doesn't because of differences between the test runner and the real pipeline though =/.
IMHO, the actual culprit is probably the skia/-vs-third_party/skia build configuration. I don't know how that is usually tested (skia/*/*_unittest* appear to be tests for thing implemented in skia/.)

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

commit f5eb27c2b897f206b275fd862e874b64159cc15e
Author: Fredrik Söderquist <fs@opera.com>
Date: Fri Sep 15 22:16:06 2017

Enable Skia's SkImageGenerator implementation

The SkImageGenerator_none.cpp implementation of
SkImageGenerator::MakeFromEncodedImpl always produce empty output.

Bug:  758459 
Change-Id: I0745e28c7c9f4aa09efbe0f0de7c88faab87f868
Reviewed-on: https://chromium-review.googlesource.com/668408
Reviewed-by: Leon Scroggins <scroggo@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#502401}
[modify] https://crrev.com/f5eb27c2b897f206b275fd862e874b64159cc15e/skia/BUILD.gn