When embedding a FlutterView onto a custom element, e.g. in multi-view mode, the app may have two sources of scrolling:

1. Flutter scrolls some content inside itself.
2. The host page scrolls its content, and one piece of content may be a FlutterView.

Case 1 seems to work well. However, case 2 does not work when the mouse cursor or finger (i.e. pointer) is on top of the FlutterView. When this happens the web engine calls preventDefault, which prevents browser scrolling. Somehow the engine needs to know when not to call preventDefault, but that information lives in the framework.

Demo: in the sample below, see that when the pointer is on top of the blue area the page is able to scroll, but if the pointer moved to the yellow area the scrolling no longer happens.

A couple of potential fixes:

• Change PointerDataPacketCallback to return some value to the engine that provides information about whether the pointer should be forwarded to the platform for handling.
• As part of rendering the frame, perhaps in the Scene graph, annotate regions with information about how certain pointer events should be handled.

My gut feeling tells me that the first option is better. For one, it is simpler and less invasive. But also, the logic that determines what to do with a pointer may depend on many things - kind, device, location, pressure - and the second option would have to pre-declare all this information even if a tiny subset of it is applicable.

This may require a collaboration between the framework and the web teams, but I'm assigning it to the framework team first to get guidance on what option would be the most idiomatic and work well across platforms.