Note this does not repro in Chrome 68 or 69 on Eve or in Chrome 70.0.3517.0 canary on Windows.

wfurr@: just to confirm, the "shadow" is a normal (non-lowLatency) WebGL 
canvas, correct ...?

+ frkoenig@ 

(Also - the bug doesn't repro on my scarlet (rockchip)).

Yes, Keep is using a bog-standard WebGL2 canvas with MSAA enabled and no other options.

Looks like it might only repro in Chrome 70 canary on ChromeOS and Intel GPU.

wfurr@ I tried to diagnose it further but couldn't, could you do a quick
try with lowLatency disabled throughout, to see if it's a WebGL flip issue
or a lowLatency issue? (To confirm, it works ok on Eve M68).

You can also try http://webgl-ink.firebaseapp.com, which does not use the lowLatency option. On 70.0.3519.3 canary eve, you can actually see that the clear occurs in a different place from the input. This app was written >6mo ago, so it's not doing anything complicated :-)

Could it be that we are using a WebGL canvas on top of another, and then
the y-flip is applied -wrongly- twice?

There's only one canvas on the page.  It's that the glScissor coordinates aren't being flipped the same way as VBOs or triangles.

--> Assigning to frkoenig@ to investigate, maybe we forgot to look at 
|opengl_flip_y_extension_| [1] somewhere in DrawginBuffer ...?

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.cc?type=cs&sq=package:chromium&g=0&l=184

In https://bugs.chromium.org/p/chromium/issues/detail?id=680851#c28 a user identifies that as an inverted rendering culprit, could be related.

https://bugs.chromium.org/p/chromium/issues/detail?id=680851&desc=2#c28

@frkoenig any updates on this?

I haven't made much progress.  I was looking into the issue that @wfurr linked as an inverted rendering, hoping it would be related.  I haven't been able to solve that one yet.

The clipping is clipping the correct area.  The clear is what is failing.  A quick test to show this:
        gl.viewport(0, 0, gl.viewportWidth, gl.viewportHeight);
        gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
        gl.enable(gl.SCISSOR_TEST);
        gl.scissor(0, 0, 1500, 500);
        gl.clearColor(1.0, 0.0, 0.0, 1.0);
        gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
The desired outcome is the lower part of the screen will be red.  But instead the upper part is red.

When mesa was changed to handle the flipping internally there were checks that needed to be converted to the new logic.  In particular, rb->Name == 0 is used to denote that it is a system framebuffer instead of a user framebuffer.  This is checked on the renderbuffer, not the framebuffer.  It is the framebuffer that has the FlipY flag on it.

Some of these checks slipped through.  The fix needs to be done in mesa.  In particular, the change needs to be made to |do_single_blorp_clear| to correctly handle the case noted here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/1c18404375e77fb6ae0973be95aa4ac112cd7ab5

commit 1c18404375e77fb6ae0973be95aa4ac112cd7ab5
Author: Fritz Koenig <frkoenig@google.com>
Date: Sat Aug 25 14:31:19 2018

media-libs/mesa: GL_MESA_framebuffer_flip_y orientation checks

Also check rb->Name when applying FlipY.

BUG= chromium:872845 
TEST=webgl render in browser

Change-Id: Id5336a27ffbe0c56b3cec78886c0459e104c292b
Reviewed-on: https://chromium-review.googlesource.com/1185968
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Fritz Koenig <frkoenig@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>

[add] https://crrev.com/1c18404375e77fb6ae0973be95aa4ac112cd7ab5/media-libs/mesa/files/18.3-i965-Replace-checks-for-rb-Name-with-FlipY.patch
[modify] https://crrev.com/1c18404375e77fb6ae0973be95aa4ac112cd7ab5/media-libs/mesa/mesa-9999.ebuild
[modify] https://crrev.com/1c18404375e77fb6ae0973be95aa4ac112cd7ab5/media-libs/mesa/mesa-18.2_pre1.ebuild
[rename] https://crrev.com/1c18404375e77fb6ae0973be95aa4ac112cd7ab5/media-libs/mesa/mesa-18.2_pre1-r14.ebuild

#18 landed in 11004.0.0