@harryterkelsen can this result in the opposite effect where too much is put on top of the platform view? and won't it make the platform view no longer able to receive events?

A while back I experimented with a PR that cut holes out of the canvas with a clear operation when their layer was rendered instead of paint operations and then placed the views behind the canvas. Maybe that could be a useful strategy here so that whatever is on top of that last one that should be behind gets erased and you don't get reverse artifacts.

On that subject,If now it is going to be possible to end up with views below the canvas (which I always thought was probably the better default as it has zero problems with overlay groups at the cost of disabling a few things that aren't usually used with overlay groups), it could maybe be useful to support that general concept for HtmlElementView to support this to allow users to control what happens with the platform views. Right now isVisible is a little confusing and misleading because it doesn't actually make anything invisible, it just puts it always on top of the canvas. It would probably make more sense to have:

enum HtmlElementViewPosition {
   above,
   below,
   alwaysOnTop /// replacement for isVisible, which is a lie
}

HtmlElementView.fromTagName(String tagName, position = HtmlElementViewPosition.below);

And then you wouldn't burn platform layers by default, and you could use one of the other options when you need the element to be clickable

@jezell isVisible is supposed to just be a hint for when the platform view is actually invisible. In those cases we can safely elide an overlay for that platform view. I am also thinking of adding a flag for isOpaque for platform views (which would function similarly to alwaysOnTop) and allow optimizing for the cases where a platform view intersects with a Skia picture but completely obscures it.

@harryterkelsen I get what it's supposed to be, I also get what it actually is :). While it may supposed to be something you use when stuff is invisible, it doesn't make anything invisible, so it's confusing. If it was alwaysOnTop, it would say exactly what it actually does and would also be more clear that you can use this to avoid creating platform layers. This came up for us recently using the HtmlElementView to embed iframes that we want invisible because they are only used for cross domain communication. Because it says isVisible, everyone expected the iframes wouldn't be displayed, but of course that's not what it does, it just renders them on top.

When this change gets merged, the engine will have three places it can put a view relative to the other canvases:

on top
between
beneath

While all three are valid places you might want to put them, one of them is misnamed as isInvisible, and one of them randomly happens only if you run out of platform views because the engine is trying to be smart and introduces undesirable side effects when it happens, so it's not clear it totally solves the problem.

I think it would probably be better if all of these options were surfaced directly by the HtmlElementView. If beneath was the default, it has less side effects than other two options (if only a couple of lines of code are added for the clear op during the rendering). Then, if you manually opted into between and ran out of layers it could work more like the overflow indicators, where instead of rendering the platform view at all, it renders a shape with an error indicating that you've run out of platform layers.

The problem right now is that this continual desire to insert the views between everything as the default keeps causing unpredictable behavior because it's a fundamentally problematic default. There is no real perfect solution to the problem, but the least problematic default would be something other than putting them between. None of these overlay group issues would be a big deal if they were something you opted into instead of being forced upon you by a problematic default.

@jezell I tried to capture your feature request (and we've been thinking about similar ideas that are documented in the issue too) here: flutter/flutter#145360

I think this change should still go in. We're essentially choosing the least bad option for the case where we already know that we ran out of overlays and will render incorrectly. We're trying to minimize the damage. Seems like the strategy @harryterkelsen picked would be best for the common case, no?

@yjbanov I agree it's better than the current behavior until flutter/flutter#145360 lands