[web] Add PointerInterceptor widget

[ditman]

This PR adds the (web) PointerInterceptor widget, to address issues like: flutter/flutter#54027.

The widget can be used simply as a wrapper of any widget that is overlaid on top of a platform view, so it can handle clicks "as expected".

More info about usage and testing in the corresponding READMEs!

The example app is deployed here running on top of flutter master: https://dit-mouse-boundary.web.app

[ditman]

In an offline discussion, this has been suggested to be renamed pointer_interceptor; I'll get that done. (Done)

[ditman]

I think I've addressed all of @yjbanov's comments. I also migrated the package to Null-Safety by bumping its lower SDK version (and some minimal changes to the code).

Attempting to migrate tests now (but I don't think this'll work)

[ditman]

Reverted null safety because of:

Checking that web_pointer_interceptor can be published.
Package validation found the following potential issues:
* Packages with an SDK constraint on a pre-release of the Dart SDK should themselves be published as a pre-release version. If this package needs Dart version 2.12.0-0, consider publishing the package as a pre-release instead.
  See https://dart.dev/tools/pub/publishing#publishing-prereleases For more information on pre-releases.
* This package is opting into null-safety, but a dependency or file is not.
  
  package:sky_engine is not opted into null safety in its pubspec.yaml:
    ╷
  8 │   sdk: '>=1.11.0 <3.0.0'
    │        ^^^^^^^^^^^^^^^^^
    ╵

[ditman]

I'll tweak this after pushing, when the images live in the repo.

[yjbanov]

[yjbanov]

Should the AppBar or its contents be wrapped in PointerInterceptor? The content in the body can be rendered under the appbar and if it contains iframes, consume pointer events.

[ditman]

Yes, you're right, and that'd also cover the Drawer open button, I'm going to give that a shot!

[ditman]

Oooops, not for now:

The argument type 'PointerInterceptor' can't be assigned to the parameter type 'PreferredSizeWidget'.

The contents should be wrappable (individually)

[RandalSchwartz]

It's not clear how this differs from AbsorbPointer or IgnorePointer. Wouldn't this functionality be better in those classes?
Or if it needs platform-specific code, hide it behind a conditional import?

[ditman]

Wouldn't this functionality be better in those classes? Or if it needs platform-specific code, hide it behind a conditional import?

@RandalSchwartz I've double-checked the documentation and it seems that this doesn't fit well with neither Ignore/AbsorbPointer.

The issue, in web, is that any flutter element that you overlay on top of an HtmlElementView will behave as if it was wrapped in IgnorePointer: clicks won't land on them, but will go through to the underlying view (there's an example here, the pink webview will get the clicks that you do on the left button. The right button is wrapped in PointerInterceptor and will work as expected).

This happens because in the browser, it seems that the HtmlElementView is handling (and consuming) the mouse events before Flutter's glass-pane is able to handle them (and decide whether to use Ignore/AbsorbPointer or anything else!).

In this case, the PointerInterceptor is just adding an empty HtmlElementView under the wrapped child that prevents the underlying HtmlElementView from seeing any events in that covered region, allowing Flutter to handle the event of the child.

I'm not 100% sure that this would mesh well with either Absorb/IgnorePointer. WDYT?

I also added something similar to the above in the README of the PointerInterceptor, do you think it needs further elaboration? More details can be added there.