https://jsfiddle.net/slavasem/a8nt424s/8/
Added log to get currentTransform (becomes available with 'experimental canvas features')
Nominally, transform stays the same in both cases, actually resets to identity

Able to reproduce this issue on reported version 64.0.3282.119 using Windows 10,Mac 10.13.1 and Ubuntu 14.04 but fixed on latest canary 66.0.3335.0. Hence providing reverse bisect info.

Last Bad Build: 65.0.3325.0
First Good Build: 65.0.3326.0

You are probably looking for a change made after 530604 (known good), but no later than 530605 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/943e253fab89d016d4c5895f5d272af765a8df8f..2ea1a7e41007c09bead29157cda85f781889622e

Reviewed-on: https://chromium-review.googlesource.com/876528

Suspecting same from changelog.

@ xlai: Please confirm the bug and merge it to M-64 and M-65 if it is safe. Adding RB-Stable for M-64, Please undo if not the case.

Thanks!

I did the same check on Mac machine and also notice that the bug exists in latest Chrome Beta 
64.0.3282.119 and I also notice that the bug disappears in latest Canary
66.0.3336.0. 

However, my fix CL that you suspect is the fix (https://chromium-review.googlesource.com/876528) has already been merged to M64 (merge CL:
https://chromium.googlesource.com/chromium/src/+/9f67f6324fa0dfe4a7e5485f8bb7c1761d105ffe) and is already released in 64.0.3282.112. It is also merged to
M65 and released in 65.0.3325.31.

Therefore I am very confused by the reverse bisecting results. I don't think
my CL is the real fix for this bug; it might be someone else.

As per comment#4 re-kicked the bisect and observed below results.

In Latest stable 64.0.3283.140 issue is seen. In latest dev 65.0.3325.31 and latest canary 66.0.3336.5 issue is not seen.

Performed per-revision bisect and got same cl as comment#3 : https://chromium.googlesource.com/chromium/src/+log/943e253fab89d016d4c5895f5d272af765a8df8f..2ea1a7e41007c09bead29157cda85f781889622e

Performed chromium bisect and got cl as : https://chromium.googlesource.com/chromium/src/+log/b4adc605cf848a97561924ada89cab404ecbdab0..ad6465a706b36938273c715c402575ee0e3052c4

@xlai: Please check the bisect results.

Thanks!

Attaching screencast of issue in 64.0.3282.140 stable. And adding RB-Stable for M-64. Please remove if not the case.

Deleted: 807636.mp4 496 KB

	807636.mp4 496 KB View Download

This is super weird, because this fix CL is already merged to M64: https://chromium-review.googlesource.com/c/chromium/src/+/879360. I will look into the code itself.

I know the reason now. The RestoreCanvasMatrixClipStack is not invoked in M64 as intended.

When canvas is replacing a new 2d bridge, it does not
set CanvasResourceHost in its bridge; therefore, the ImageBuffer is 
not doing a RestoreCanvasMatrixClipStack() because it finds that the 2d bridge does
not have a CanvasResourceHost. The reason why this problem is not seen in M65/M66 is that due to code structural change, the ReplaceExistingCanvas2DBuffer has been
refactored into HTMLCanvasElement and therefore a RestoreCanvasMatrixClipStack()
will always be called even without the proper setting of CanvasResourceHost.

Hotfix CL for M64 is here: https://chromium-review.googlesource.com/c/chromium/src/+/899913
ToT CL for final fix of the evil and a unit test is here: https://chromium-review.googlesource.com/c/chromium/src/+/899962

Request Merging https://chromium-review.googlesource.com/c/chromium/src/+/899913 to M64.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Btw to TPM who's reviewing the merge request, I can reproduce this bug on my Linux machine on M64 branch and I can see the fix CL https://chromium-review.googlesource.com/c/chromium/src/+/899913 can fix the problem.

Request merging https://chromium-review.googlesource.com/c/chromium/src/+/899962 to M65 too.

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

commit 07062c952f820196c880cea5bb05158881662d45
Author: xlai <xlai@chromium.org>
Date: Fri Feb 02 21:14:31 2018

Set CanvasResourceHost when canvas replaces its canvas2d layer bridge

TBR=junov@chromium.org

Bug:  807636 ,  807427 
Change-Id: Ic5fe5abbf5deaed883c005280fd8418cf49ca9d2
Reviewed-on: https://chromium-review.googlesource.com/899962
Commit-Queue: Olivia Lai <xlai@chromium.org>
Reviewed-by: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534152}
[modify] https://crrev.com/07062c952f820196c880cea5bb05158881662d45/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp
[modify] https://crrev.com/07062c952f820196c880cea5bb05158881662d45/third_party/WebKit/Source/modules/canvas/canvas2d/CanvasRenderingContext2DTest.cpp

Can you please comment on why this is critical for M64, vs waiting until M65?

There are some changes that only landed 4 hours ago, and there is not enough bake time in Canary. 

abdulsyed@: This CL not only fixed this bug, but also another bug that affects our client's existing products. So I believe that merging for M64 is very critical. I should've marked Request-Merge for M65 in another issue. Specific to this bug, it only happens in M64 due to the different code structure between M64 and M65/66.

As discussed over chat, there are client side workarounds that xlai@ can provide. Let's target a long term fix for M65.

semenukha@realtimeboard.com: There is a cost to merge a fix to stable release; so we
will merge to M65 which is currently in its Beta.

As a temporary workaround to this problem in Chrome 64, you could do this:
1. type "chrome://flags" in a Chrome tab and enter.
2. Among the list of Chrome flags, find "Accelerated 2D Canvas", disable this flag.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Pls merge your change to M65 branch 3325 before 2:00 PM PT tomorrow, Monday (02/25/18) so we can pick it up for last dev release on Tuesday. Thank you.

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

commit 160b0172e48798827282c024d0e61c8abbf5edaa
Author: xlai <xlai@chromium.org>
Date: Sun Feb 04 22:36:47 2018

Set CanvasResourceHost when canvas replaces its canvas2d layer bridge


Bug:  807636 ,  807427 
Change-Id: Ic5fe5abbf5deaed883c005280fd8418cf49ca9d2
Reviewed-on: https://chromium-review.googlesource.com/899962
Commit-Queue: Olivia Lai <xlai@chromium.org>
Reviewed-by: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534152}
Reviewed-on: https://chromium-review.googlesource.com/900455
Reviewed-by: Olivia Lai <xlai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#285}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/160b0172e48798827282c024d0e61c8abbf5edaa/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp

Just to put in a third party developer perspective:

We run a canvas based image editing app for sports teams, and we are starting to be inundated with support tickets on graphical oddities from this group of Hardware Acceleration issues. We are not going to promote the chrome://flags or beta channel solution to our clientele, as the best case scenario is that they disable hardware acceleration (dropping our app framerate through the floor) and never turn it back on.

Unless we can find a code level solution, our intent shortly will be to put forward a "Chrome 64 breaks our application, please use another browser" message to our clients, until such a time 65 goes stable.

We had 2 workarounds to choose:
- limit first canvas to 65k pixels in size, so it stays SW
- save the first canvas as base64, then put it into image, and use it instead of that canvas

Verified the fix on M65 65.0.3325.51 on MAc 10.13.3,Windows 10 and Ubuntu 14.04 and fix is working as intended. i.e; Canvas 2 and 4 are same now. Attaching screenshot for reference.

AS the fix is working as intended adding Verified labels.

Thanks!

Deleted: 807636.png 17.4 KB

	807636.png 17.4 KB View Download

This bug affect all the canvas based applications out on the internet.

Please backport to 64 or just revert all the changes of the CL changes to 64 and publish a fix. If the improvement are coming from 65 is fine, but lot of people out uses chrome we cannot keep them broken till 65 is stable.

I agree with andreabo. Gratix we are a marketing company and our business depends heavily on a 3rd party library https://github.com/websanova/wScratchPad to run scratchcards for leadgen campaigns.

Since last tuesday, we are affected in a major way since we are 80% mobile and most users use Chrome on Android.

I agree with the Chromium people that they should aim for a stable long-term solution in M65 but it's not a reason to not push a quick fix into M64 ASAP!

Please  semenu...@realtimeboard.com could you publish here some snippet code for your 2 workarounds?

Thanks

Chris

I've just rewritten my fiddle a bit: https://jsfiddle.net/slavasem/a8nt424s/9/
Last several lines represent the second workaround: put corrupted canvas' content into the image and use it instead of canvas

Thanks for the fix. Can you please confirm how safe this patch is overall? Are there any chances of it introducing new regressions in M64? 

abdulsyed@: This is the two-line-code patch that I intend to merge to M64 https://chromium-review.googlesource.com/c/chromium/src/+/899913; I've discussed with my team member junov@ and both of us feel that this is a safe merge. I will verify it on local Mac/Linux machine before landing.

Approving it for M64: branch:3282. Confirmed with xlai@ over chat, and this has been tested in Mac/Linux. And confirmed this is a safe merge. 

We will need a postmortem for this issue.

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

commit 68f180c2597177c389641868a36c8c4e5208aa3e
Author: xlai <xlai@chromium.org>
Date: Tue Feb 06 18:05:24 2018

Set CanvasResourceHost when canvas replaces its canvas2d layer bridge

This CL is a hotfix to M64 branch based on
https://chromium-review.googlesource.com/c/chromium/src/+/899962. Due to code
structural change between M64 and M66, it is a bit different from the original
CL.

Bug:  807636 ,  807427 
Change-Id: I7f5826187e3deef2ceaeee796dc7fdf3baf71717
Reviewed-on: https://chromium-review.googlesource.com/899913
Reviewed-by: Justin Novosad <junov@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#652}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/68f180c2597177c389641868a36c8c4e5208aa3e/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp

Is there an ETA for when this will land in M64?

Our lead developer has clocked 11 hours since Sunday night and is actively working on a patch for this issue in our software. We'd like to determine if we should keep pressing forward or wait for the update to land. 

Thanks!

Thanks Ryan for raising the issue. We just landed the patch for this, and we are planning an update in the next week. We can update this bug once the release with the fix goes out. Hope this helps!

abdulsyed@ yes definitely! Thank you and the Chromium team for your attentiveness to this issue. I'm sure there's a number of us who are very eager for this update. 

Also, M66 behaves wonderfully and seems much more performant than M64 in the context of our application. 

If it can helps i alleviate all the problems i have in my app setting the minimum canvas dimension i ever create to 512x512.
Bumping up memory requirements for sure but at least avoiding the bug most of the time

I'm marking this as fixed because the fix CL is already waiting in the next update of Chrome 64. But I'll continue verifying it after the update is released.

Verified the fix on M65 64.0.3282.167 on Mac 10.13.3,Windows 10 and Ubuntu 14.04 and fix is working as intended. i.e; Canvas 2 and 4 are same now. Attaching screenshot for reference.

AS the fix is working as intended adding Verified labels.

Thanks!

Deleted: 807636.png 15.8 KB

	807636.png 15.8 KB View Download

 Issue 810346  has been merged into this issue.