[web] Adds allowPlatformDefault for wheel signals.

[ditman]

Adds a function to each 'wheel' DataPacket sent to the framework so it can signal whether to allowPlatformDefault or not.

The current default is to always preventDefault on browser events that get sent to the framework.

This PR enables the framework to call a method on the DataPackets to allowPlatformDefault: true, if the framework won't handle the Signal (signals are handled synchronously on the framework).

This lets the engine "wait" for the framework to decide whether to preventDefault on a wheel event or not.

Issues

• Needed for: [web:multi-view] cannot scroll page when cursor lands on a FlutterView flutter#139263

Tests

• Added unit tests for the feature in the engine repo, veryfing whether the event has had its defaultPrevented or not.
• Manually tested in a demo app (see below)

Demo

• https://dit-multiview-scroll.web.app

Previous approaches

1. Add a handled bool property to PointerDataPacket that the framework can write to (brittle)
2. Modifications to the PlatformDispatcher so the framework can acknowledgePointerData with a PointerDataResponse (fffffatttt change)
3. acknowledge function in PointerDataPacket

Important

• Related: [web] Notify engine of handled PointerScrollEvents. flutter#145500

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[ditman]

I changed this so it doesn't exposea a mutable property, instead it allows the framework to call a new PlatformDispatcher method. PTAL @yjbanov @goderbauer

[mdebbar]

Here's a slightly different approach that I tried a few months ago: mdebbar@51ec1ee

It basically adds a handledCallback method to PointerData, and the framework can directly invoke the callback to indicate that it has handled the pointer event. The callback is a closure that has access to the browser event and can call preventDefault (or any other methods) on it.

This avoids adding a new method to the PlatformDispatcher singleton.

[ditman]

I like not having to add new methods to the Platform Dispatcher, not going to lie :)

[ditman]

This is the simplest I can come up with that could be removed/noop'd without much drama.

[ditman]

(PTAL @yjbanov @goderbauer @mdebbar)

[ditman]

Adding tests.

[ditman]

This is finally ready to go, PTAL @mdebbar @goderbauer (optionally, @yjbanov)!

[goderbauer]

I can live with this dart:ui API. :)

Leaving reviewing the web implementation to others.

[goderbauer]

LGTM for lib/ui

[kevmoo]

We can inline a function type here without creating a one-off typedef. Is this a guideline or something?

[ditman]

We can inline a function type here without creating a one-off typedef. Is this a guideline or something?

@kevmoo I went back and forth on this (I originally had this as an inline function type). The Style guide for Flutter repo that @goderbauer linked says this:

Prefer using typedefs to declare callbacks. Typedefs benefit from having documentation on the type itself and make it easier to read and find common callsites for the signature.

I don't have strong feelings about it (but when we were bikeshedding in parameter name, it was a chore to rename it in several, unconnected parts, and that's when I ended up adding the typedef... it's also nice to be able to add some dartdoc to the typedef).