[web] De-singletonize MouseCursor for multi-view

[mdebbar]

MouseCursor is a singleton that works by accessing flutterViewEmbedder directly. After this PR, MouseCursor becomes a non-singleton that takes a FlutterView and controls the mouse cursor for said view.

Part of flutter/flutter#134443

[ditman]

Minor nits to simplify this a little bit.

[ditman]

I like this interface here, but I don't think it needs to extends ui.FlutterView. In the class hierarchy, IIRC, EngineFlutterWindow already extends ui.FlutterView (through ui.SingletonFlutterWindow)

Also, I think this should be abstract interface class EngineFlutterView, if we can use that feature of Dart.

[mdebbar]

My thought here was that EngineFlutterView will become the base for all window and non-window views. Other non-window views will directly extend EngineFlutterView since they don't need ui.SingletonFlutterWindow.

So the hierarchy becomes:

                         ui.FlutterView
               (dart:ui interface across platforms)
                                |
                                |
                       EngineFlutterView (new)
           (web-specific additions to the interface)
                /                               \
               /                                 \
     NonWindowFlutterView (future)          EngineFlutterWindow
(non-sintleton, non-window views)        (legacy singleton window)

Also, I think this should be abstract interface class EngineFlutterView, if we can use that feature of Dart.

We can! We already use it in platform_location.dart :)

[ditman]

Ahhh, I gotcha. The advantage of the current version:

ui.View -> ui.Window -> WebWindow implements WebOnlyAccessors

Is that we're only extending the base classes defined by the core of the engine. In my mind that means that if there's an upcoming change in the base structure of classes in package:ui, it should be easier for ui to do changes to the base class, and for us to adapt to those changes?

(Of course, it depends on the changes, so our class extensions might not matter too much!)

[ditman]

The only problem I can imagine with this is that if the element gets detached/deleted from the DOM, and then a system cursor event message comes, this might attempt to operate on a null instance. Since this is speculation and not a bug that we've seen so far, I say we don't worry about it for now.

[mdebbar]

That's not a problem at all! The element is non-nullable and cannot become null. Yes, it can be detached/removed from the DOM tree, but it is still a valid element. In fact, in cursor_test.dart, we are using detached elements to test MouseCursor.

[ditman]

I think that the class that represents all views in the Flutter Web Engine is EngineFlutterWindow (that's the type that was used to define the implicitView, for example), right?

[mdebbar]

EngineFlutterWindow is a misnomer. It should be called EngineSingletonFlutterWindow (it actually extends ui.SingletonFlutterWindow). Views in the multi-view world shouldn't inherit from this singleton class. They should inherit directly from ui.FlutterView (and implement EngineFlutterView to satisfy all the web-specific needs).

[mdebbar]

Here's a follow up PR to rename this class to make it clear that it's a singleton: #45981

[auto-submit]

auto label is removed for flutter/engine/45295, due to - The status or check suite Linux linux_android_debug_engine has failed. Please fix the issues identified (or deflake) before re-applying this label.