Fix missing finalizeFrame barriers in WebGL animations

third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp

Index: third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
diff --git a/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp b/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
index ce4019c173a0769176bb9d07578c481753834b77..fe856ad9ed7dc149b5db86bacfad9fe9f7d15183 100644
--- a/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
+++ b/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
@@ -166,6 +166,7 @@ void CanvasRenderingContext::didProcessTask() {
   // The end of a script task that drew content to the canvas is the point
   // at which the current frame may be considered complete.
   canvas()->finalizeFrame();
+  finalizeFrame();

[Ken Russell (switch to Gerrit), 2017/02/18 00:08:01]

Why is this being added here instead of inside HTMLCanvasElement::finalizeFrame?
It seems oddly placed.

[Justin Novosad, 2017/02/21 18:06:21]

Because not all rendering contexts have an HTMLCanvasElement.  They may have an
OffscreenCanvas.

[Ken Russell (switch to Gerrit), 2017/02/21 19:23:10]

Ah right. Thanks.

[xlai (Olivia), 2017/02/21 19:56:56]

What would be the scenarios when finalizeFrame() is called for OffscreenCanvas?
Do you think it's ready to add an extra test for OffscreenCanvas in this CL or
there needs to be more refactoring
in the code (probably follow-up CLs) that handles those scenarios?

 }
 
 CanvasRenderingContext::ContextType CanvasRenderingContext::contextTypeFromId(