Please add affected OSs.

This was observed on Linux and Windows. Assuming it is not OS-specific.

xlai@,
Could you please take a look into it as it is marked as stable blocker.
Thanks..!

Sorry i was working on a different P1 issue; will start looking into this today.

The image is correctly flipped in Chrome 64.0.3282.119. But it is not flipped in 65.0.3325.31. I will do a bisect first.

The reason is again the early creation of CanvasResourceProvider when Canvas2DLayerBridge is created in canvas; I introduced it in https://chromium.googlesource.com/chromium/src/+/d02bb8346f13117d4a81d1124a3aeeaaed83ae99 as I thought this should be the correct way of making 2d and webgl consistent--that they create CanvasResourceProvider at one single function in HTMLCanvasElement. 

But this is problematic because I now realize that the early creation of CanvasResourceProvider changes the code paths in many instances (not only this bug; there are also other bugs coming in to me because of this CL).

In this particular example, originally, the bigger canvas will not create a resource provider until the smaller canvas
tries to perform a drawImage() from it and calls GetSourceImageForCanvas(). The smaller canvas passes in its
AccelerationHint (which is "prefer not accelerated") into GetSourceImageForCanvas(). The bigger canvas will then create
an unaccelerated resource provider based on this AccelerationHint and then do a snapshot. 

But after I introduce the early creation of CanvasResourceProvider, the bigger canvas will create an accelerated resource
provider on its own when fillRect() is called. Then, when the smaller canvas tries to do GetSourceImageForCanvas(), it can only obtain a snapshot from an existing accelerated resource provider. The smaller canvas then calls 
HTMLCanvasElement::WillDrawImageTo2DContext to promote its unaccelerated resource provider to accelerated mode.

Another difference is that originally the bigger canvas was operating on RecordPaintCanvas for fillRect, but after the refactoring CL, it will
operate on SkiaPaintCanvas (inside CanvasResourceProvider) for fillRect. These are two different subclasses of PaintCanvas and I'm sure
that causes some behavior change too.

Wait a minute. I think this early creation of CanvasResourceProvider is not the final fix. 

It actually exposes a different existing bug--that is, when an unaccelerated canvas tries to drawImage from an accelerated canvas (that already has CanvasResourceProvider created), it will ignore the existing transformation. Note that in this case, the small canvas will get promoted to accelerated 2d
and a new Canvas2DLayerBridge will get created. Probably this is the part that
gets it wrong.

I just created a more complex test example:
  https://jsfiddle.net/53fhq5w6/

Inside this test example,  this particular command "ctxc.drawImage(a, 0, 0, 512, 512);" will trigger both canvas 'a' and canvas
'c' to create accelerated CanvasResourceProvider. Then when the small canvas b tried to do drawImage with transformation, it
will see an upright image, which is wrong.
Commenting out "ctxc.drawImage(a, 0, 0, 512, 512);" then you will see the small canvas correct.

This bug exists even in stable  64.0.3282.119, showing that it is not because of a regression of my CL.

--------------------------------------------------------------------------------

My suggestion to resolve this issue:
1. First, I want to quickly do a partial revert about the eager creation of CanvasResourceProvider, to merge it to M65 so that we do not affect user experience on existing things. 
2. I want to resolve this existing bug carefully (and slowly as well) in a separate issue.

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

commit d507be380ff2dbbea2c5c2581d07c3d803221d41
Author: xlai <xlai@chromium.org>
Date: Thu Feb 01 21:33:58 2018

No eager creation of CanvasResourceProvider when canvas 2d bridge is created

This is a partial revert of the big refactoring CL
https://chromium-review.googlesource.com/c/chromium/src/+/864630. That CL
made the creation of CanvasResourceProvider for canvas 2d earlier at the point
of time when Canvas2DLayerBridge is created; this changed the code paths of
some instances and should not belong to a refactoring CL that is not intended
to change behavior.


Bug:  806066 
Change-Id: I00493338f6bda4a9ea17ee01db2dcab29223398c
Reviewed-on: https://chromium-review.googlesource.com/896084
Reviewed-by: Justin Novosad <junov@chromium.org>
Commit-Queue: Olivia Lai <xlai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533820}
[modify] https://crrev.com/d507be380ff2dbbea2c5c2581d07c3d803221d41/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp
[modify] https://crrev.com/d507be380ff2dbbea2c5c2581d07c3d803221d41/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.h
[modify] https://crrev.com/d507be380ff2dbbea2c5c2581d07c3d803221d41/third_party/WebKit/Source/modules/canvas/canvas2d/CanvasRenderingContext2DTest.cpp

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/+/6f11f88a57aea0b829ee167cd355b6948711f132

commit 6f11f88a57aea0b829ee167cd355b6948711f132
Author: xlai <xlai@chromium.org>
Date: Mon Feb 05 15:46:54 2018

No eager creation of CanvasResourceProvider when canvas 2d bridge is created

This is a partial revert of the big refactoring CL
https://chromium-review.googlesource.com/c/chromium/src/+/864630. That CL
made the creation of CanvasResourceProvider for canvas 2d earlier at the point
of time when Canvas2DLayerBridge is created; this changed the code paths of
some instances and should not belong to a refactoring CL that is not intended
to change behavior.

Bug:  806066 
Change-Id: I00493338f6bda4a9ea17ee01db2dcab29223398c
Reviewed-on: https://chromium-review.googlesource.com/896084
Reviewed-by: Justin Novosad <junov@chromium.org>
Commit-Queue: Olivia Lai <xlai@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533820}
Reviewed-on: https://chromium-review.googlesource.com/900453
Reviewed-by: Olivia Lai <xlai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#298}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/6f11f88a57aea0b829ee167cd355b6948711f132/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp
[modify] https://crrev.com/6f11f88a57aea0b829ee167cd355b6948711f132/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.h
[modify] https://crrev.com/6f11f88a57aea0b829ee167cd355b6948711f132/third_party/WebKit/Source/modules/canvas/canvas2d/CanvasRenderingContext2DTest.cpp

Android:  Image flipped as per expected behavior.
Verified on 65.0.3325.53 and 66.0.3341.0