Tested the issue in Android and able to reproduce the issue. Similar behavior is observed since Chrome #60.0.3072.0

Steps Followed:
1. Launched the Chrome Browser.
2. Open the sample HTML file attached in the original comment.
3. Observed that only 8 canvases are displayed. At the same time in Chrome desktop browser 12 canvases are displayed.

Chrome versions tested:
60.0.3072.0, 65.0.3325.109(Stable), 67.0.3365.0(Canary)

OS:
Android 8.1

Android Devices:
Pixel XL, Pixel

This seems to be a Non-Regression issue as same behavior is seen since M60.  Untriaged for further input's on this issue.

Please navigate to below link for log's and screen cast--
go/chrome-androidlogs/820082

Note: 
1. This issue is not observed in Desktop.
2. Similar issue is observed on FireFox mobile version, it displays only 3 canvases for the sample HTML file provided.

Thanks!

I am pretty sure this is by design, but perhaps it could be revisited.  Assigning to the WebGL team for follow-up.

Possible workaroud:
Use a single canvas that is not attached to the DOM to do all the WebGL rendering. In the document, use a bunch of placeholder canvases with 2d contexts that will receive the images rendered by your single WebGL context.  To transfer a rendered frame to a placeholder canvas use the 2d context's drawImage method.
To streamline the rendering you may want to create the 2D contexts with the {alpha: false} option if that is appropriate. Also, set the globalCompositeOperation to 'copy' on the 2d contexts. That way you don't need to clear the canvas before the drawImage call.

This limit was intentionally put in place by kainino@, reducing Android's max canvas limit to 8 (desktop has a limit of 16) to reduce the occurrence of out-of-memory errors.

Patch: https://chromium.googlesource.com/chromium/src/+/75ee3cee8e33bd1bcf4fb335b20acc04991448e8

Bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=699606

I don't think it's a limit we're in a position to lift at this point, so I would recommend looking for alternative solutions for pages that need multiple canvases. junov@'s suggestion is a good one. I've also had positive results using multiple static 2D canvases and a single "live" WebGL canvas element which gets swapped into the position of a 2D canvas on mouseover, making the various gallery images only update when hovered. (Shadertoy-style https://www.shadertoy.com/browse)

Thanks for the background.  I appreciate the need to impose resource limits here, but limiting the canvas count seems like an ineffective way to do that.  I could create a single canvas that could consume significantly more (hopefully not unbounded) GPU memory than the twelve in the reproducer.

Perhaps this bug should be changed to a feature request to support a more sophisticated resource limit?

And thank you both for the work-around suggestions.  I'll play around with them to see what I can come up with.

It would be more complex to implement a more advanced heuristic (e.g. limiting the total amount of memory allocated for canvases). However we should consider it - the original bug was maybe a little too targeted at that particular conformance test - and perhaps it would be better to limit the max framebuffer size instead.

I seem to remember we may have added canvas size limits in the time since I added this restriction. I'm not sure about that.

It's not easy. Making the context count unlimited and properly recovering from the out-of-memory errors that can be caused by this is all tied up in CLs like https://chromium-review.googlesource.com/724723 which I'm stuck on right now and haven't had a chance to get back to. If anyone wants to pick these up that would be welcome.

I'm going to block this issue on that one too, for now.