This is regression issue, broken in ‘M 58’ and will soon update other info :
Good build:58.0.2988.0
Bad build: 58.0.2989.0

Note issue is not seen on Linux and Window OS.

Deleted: Actual_video.mov 2.3 MB

Actual_video.mov 2.3 MB Download

Deleted: Expected_video.mov 2.8 MB

Expected_video.mov 2.8 MB Download

Note : The above issue is reproducible on latest canary chrome version : 58.0.2990.0.Below is the Bisect info.

CL :
https://skia.googlesource.com/skia.git/+/d2eb581ebc8f8009e80cccccd74d5b341ef5bd5b


Suspecting: d2eb581ebc8f8009e80cccccd74d5b341ef5bd5b from above CL

@caryclark: Could you please help to reassign if your change is not the cause for this change.

adding RB label as this is recent regression, please change if required

The output is clipped and translated, so it doesn't appear to be related to my change, which at most could change the clip's shape but not its matrix. Nonetheless, I'll do my best to investigate.

I didn't know that pathops where used by canvas. If that is the case, it's curious that this only happens on the Mac. There's nothing platform specific in pathops, and I imagine that this would also be true for how canvas constructs clips.

Juno, is it possible that the canvas element is calling pathops to construct the clip in this case? If so, could you help me isolate the paths that trigger this error? Calling SkPath::dumpHex() on the Op() inputs should be enough.

I haven't built Chrome on a Mac before, so it may take a while for me to debug this.

I'm reverting my change for an unrelated reason -- a nice side effect is that it will verify that it is responsible for this breakage

The sign-in page has changed (See attachment). This will make the bug harder to investigate, unless alternate repro steps can be found.

@mnikam: Were you on a mac with a retina display? If that is the case, perhaps that is the source of the problem, in which case it may be possible to repro on other platforms with --force-device-scale-factor=2

Ok, so it seems that clients on the google corporate network are presented a new future version of the login page.  You need to be on an off-corp device to see the current version of the sign-in page.  I deleted the attachment in #6 because it showed an unreleased version of the sign-in page.

This bug is probably unrelated to canvas: The pictogram itself is drawn inside a canvas, but the clipping is done in CSS.  The parent element of the canvas is a div with class="circle-mask", which uses "border-radius: 50%" to produce a circular mask.  The border-radius CSS property is used for creating rectangles with rounded corners.  Setting the border radius to 50% (of the size of the rect)  gives an ellipse that is the result of joining four 90 degree arcs, one for each corner.

I think the code that handles this is here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp

Or possibly in some other related class.
+schenney for further guidance.

I can reproduce it on non-corp 58.0.2990.0. It looks different to the screen shot given, but overall the effects is the same: the image is offset due to a clip in the wrong place.

To repro, use a Mac laptop on guest network.

Test team, please bisect this again. We think the original bisect was incorrect.

Actually... sounds like this may be Skia after all.

The Skia issue is not the cause. It has been reverted and I checked with and without the patch and got the same broken result. So we do need another bisect please.

Ran the bisect on three different Non-Corp machines for finding the Culprit.
Noticed two different suspects

CL1# https://chromium.googlesource.com/chromium/src/+log/2bcbc12230b01813e2cc5efb02f10a8da79f88ce..209094f6afac678695e7061b0e02e3dc21eb7ebe
CL2# https://chromium.googlesource.com/chromium/src/+log/209094f6afac678695e7061b0e02e3dc21eb7ebe..677c0342b556d3dd7a5387ffba13cc0079439ad7

As per Comment# 12, not suspecting CL2.

From CL1 assigning to the concern owner.
Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/209094f6afac678695e7061b0e02e3dc21eb7ebe

chrishtr -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Cc'ing trchen@ as the reviewer of the CL for more inputs on this.

CL#2 has Skia roll with 52 commits.

We have seen similar  Issue 684753  &  Issue 684829  &  Issue 687302  in the same manual regression range.

Cc'ing 	ethannicholas@ as well for inputs if the change could be related to this as well. 

It is not r445275, as that is behind a runtime flag.

I can reproduce at ToT on Mac non-corp.

Now manually bisecting.

Update: it was definitely something in the Skia roll that caused this bug.
Continuing to manually bisect within that roll.

This CL was caused by the following Skia commit:

commit de4d301881e7fd084f1f0b359ec6f9b2bf8bd4c5
Author: Ethan Nicholas <ethannicholas@google.com>
Date:   Thu Jan 19 16:58:02 2017 -0500

    Replaced all calls to fragmentPosition() with sk_FragCoord
    
    BUG=skia:
    
    Change-Id: I179576e148ea6caf6e1c40f0a216421898bcb35d
    Reviewed-on: https://skia-review.googlesource.com/5941
    Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
    Reviewed-by: Brian Salomon <bsalomon@google.com>

It appears it was since fixed, as Canary 58.0.3005.2 does not have the bug but an earlier dev version of 58 does.

Ethan, could you please verify that you know what the fix was and that the fix is complete? Then the bug can
be closed.

Sorry, forgot to mark this one fixed.

Could you please post the CL which you think fixed this bug, for completeness?

It was https://skia-review.googlesource.com/7887 which is a revert of the offending change

Issue 687857 has been merged into this issue.

https://bugs.chromium.org/p/chromium/issues/detail?id=687857 - I'm still seeing this issue on Galaxy S7 / 58.0.3019.0 

Issue 683825 has been merged into this issue.