In current implementation, chromium will create OpenGL ES 2.0 context for WebGL 1.0 and OpenGL ES 3.0 context for WebGL 2.0 when enable pass through command buffer but it always creates OpenGL ES 3.0 context when command buffer works. This may cause different behaviour.

For example,  issue 804628 , a WebGL 1.0 sample of WebVR. WebVR called blitFramebuffer in chromium to transfer canvas contents and when enable pass through command buffer, chromium created OpenGL ES 2.0 context and it called API provided by ANGLE_framebuffer_blit extension. This extension reports INVALID_OPERATION error when mask includes COLOR_BUFFER_BIT and the source
and destination color format to not match. So this WebVR sample fails(GL_RGB and GL_RGBA). But when command buffer works, chromium created OpenGL ES 3.0 context and it called API provided by OpenGL ES 3.0 core feature that releases the restriction about color formats. So the WebVR samples could work properly.

I don't know whether it needs to fix. If it needs, I have two proposals, 
1. Querying feature info and add validations in command buffer for blitFramebuffer extensions.

2. Like this CL(https://chromium-review.googlesource.com/c/chromium/src/+/905873), register an new blitFramebufferES2 API, querying feature info and call this API if context is OpenGL ES2. This API will call corresponds OpenGL ES 2.0 API or fail this blitFramebuffer call if no extension supported. But it seems it may fail some share context operation on mac.