The validating is going through glBlitFrameBuffer, while the passthrough is going through glBlitFramebufferANGLE.

From Geoff:
Ok, my guess here is that both command buffers are exposing ES2, the validating command buffer asks for a backing GL context of the highest version while the passthrough one will ask for an ES2 context.  This causes the gl bindings to load different entry points.

If this is the case, we may need to update the validating command decoder to dis-allow these conversions and interpolation enums for ES2 contexts.  When ANGLE only supports ES2 (on top of D3D9 for example), the command decoder's validation will be incorrect and generate unexpected errors.

 Issue 810252  has been merged into this issue.

According to this issue, It seems that add validations for ES2 context in command buffer is better than register an new blitFramebufferES2 API, querying feature info and call this API if context is OpenGL ES2((https://chromium-review.googlesource.com/c/chromium/src/+/905873)). This API will call corresponds OpenGL ES 2.0 API or fail this blitFramebuffer call if no extension supported. 
Am I right ?

Hi Geoff,
Actually, the root cause of this is pass through command buffer use an extension to support share groups with contexts of multiple versions(https://bugs.chromium.org/p/angleproject/issues/detail?id=1639&can=2&q=1639&colspec=ID%20Type%20Status%20Priority%20Feature%20Owner%20Summary) and pass through command buffer could create different contexts. But command buffer seems remain to use global share context group, so they're all created in OpenGL ES 3.0.

Would it possible for command buffer also use this extension to support share groups? and based on it, command buffer may also could created different versions of OpenGL ES contexts. (BTW, I tried created different version of OpenGL ES contexts for command buffer but it fails WebGL2 Conformance tests and contexts failed to created because of some share context group settings https://chromium-review.googlesource.com/c/chromium/src/+/896943)

It may be possible to do but would require more work than the linked CL, several of the manager objects (TextureManager, QueryManager, ProgramManager, etc) don't expect that the context version can vary within the share group and may initialize state based on the first context seen.

Fixing this particular bug is much more simple, we need to update the validation GLES2DecoderImpl::DoBlitFramebufferCHROMIUM to match that of ANGLE's extension GL_ANGLE_framebuffer_blit when ES2 contexts are exposed and add some tests in gl_tests.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".