Skip to content

Conversation

@mdebbar
Copy link
Contributor

@mdebbar mdebbar commented Oct 13, 2023

This PR prepares web platform views for the multi-view world.

Depends on flutter/engine#46891
Part of #137287

@mdebbar mdebbar requested a review from ditman October 13, 2023 17:28
@github-actions github-actions bot added the framework flutter/packages/flutter repository. See also f: labels. label Oct 13, 2023
Copy link
Member

@ditman ditman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments, but in general LGTM!

(this can't land until the engine version does, though, since this is using new message argument names that are currently not understood by the engine)

Comment on lines 58 to 59
PlatformViewCreationParams params,
int viewId,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why isn't viewId part of the PlatformViewCreationParams? (This would be easy to change anyway)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PlatformViewLink and PlatformViewCreationParams are used by all platforms and I didn't want to step on their stuff. I also want to hear from @goderbauer about how other platforms are going to deal with this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to step on their stuff.

It's our stuff. We own this all together. :)

Adding the viewId to PlatformViewCreationParams sounds reasonable to me. I imagine other platforms will likely also need to know what FlutterView a PlatformView is associated with. @cbracken @loic-sharma have you thought about this in the context of your Desktop Platform view work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to note, though: A PlatformView could move from one view to another. When scrolling through this PR I didn't see anything that would update the view ID associated with the controller when this happens?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A PlatformView could move from one view to another.

Hm, that's an interesting case. In the web at least, since we'd need to move the actual DOM Content for platform_view (because each view has its own DOM shadow root), it'd be equivalent to destroying the view and recreating it from the factory elsewhere (in most cases).

I'm not sure how the framework/engine handles this case.

Copy link
Member

@cbracken cbracken Oct 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't given this much thought I terms of desktop platform views but agreed we'll likely want this for desktop as well. Thanks for cc'ing, will take a look.

@mdebbar mdebbar requested a review from goderbauer October 20, 2023 16:24
Comment on lines 58 to 59
PlatformViewCreationParams params,
int viewId,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to step on their stuff.

It's our stuff. We own this all together. :)

Adding the viewId to PlatformViewCreationParams sounds reasonable to me. I imagine other platforms will likely also need to know what FlutterView a PlatformView is associated with. @cbracken @loic-sharma have you thought about this in the context of your Desktop Platform view work.

Comment on lines 58 to 59
PlatformViewCreationParams params,
int viewId,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to note, though: A PlatformView could move from one view to another. When scrolling through this PR I didn't see anything that would update the view ID associated with the controller when this happens?

import 'package:flutter/widgets.dart';
import 'package:flutter_test/flutter_test.dart';

extension WrapperlessWidgetTester on WidgetTester {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-using-extension

(I would just define this as a helper method until we're ready to actually implement this on WidgetTester itself)

@ditman
Copy link
Member

ditman commented Oct 25, 2023

Wow, thanks for adding support for moving the flutter view!

The testing seems to be an analyzer issue:

error � Missing concrete implementation of 'PlatformViewController.moveToFlutterView' � packages/flutter/test/services/fake_platform_views.dart:47:7

'platformViewId': platformViewId,
'viewId': flutterViewId,
};
await SystemChannels.platform_views.invokeMethod<void>('moveToFlutterView', args);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
await SystemChannels.platform_views.invokeMethod<void>('moveToFlutterView', args);
await SystemChannels.platform_views.invokeMethod<void>('move', args);

👍 I'd call this move just to keep the same brevity of the create/dispose methods, but I don't have a strong opinion.

@mdebbar
Copy link
Contributor Author

mdebbar commented Oct 25, 2023

I'm still working on tests.. my latest commit broke some tests.

Here's what I think so far: in tests, platform view creation happens synchronously in PlatformViewLink.initState, while in real code, the platform view creation happens asynchronously. With my recent change, platform view creation moved from initState to build, causing the tests to fail. @goderbauer any suggestions on how to deal with this? Or ideas on how to restructure the code to avoid this issue?

Note: The reason for moving platform view creation (or controller creation, really) from initState to build is that we need View.of(context) now. Adding inherited widget dependencies isn't allowed in initState apparently (I'm hitting this error).

@ditman
Copy link
Member

ditman commented Oct 25, 2023

The reason for moving platform view creation (or controller creation, really) from initState to build is that we need View.of(context) now.

Ahhh, tricky tricky :/

Future<void> create({Size? size, Offset? position}) async {}

/// Moves the platform view to a new [FlutterView].
Future<void> moveToFlutterView(int flutterViewId) async {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we update the PlatformViewController.viewId documentation on lines 1451-1457 to clarify that identifier is for the platform view (instead of a Flutter view)?

@goderbauer
Copy link
Member

goderbauer commented Nov 1, 2023

Missed this ping last week. Apologies.

Instead of moving it from initState to build could you move it to didChangeDependencies? That one runs right after initState and again whenever the dependencies change. It's the usual place to establish dependencies that you cannot establish in initState. The reason for not being able to establish dependencies in initState is that initState doesn't run again when dependencies change while didChangeDependencies does.

@flutter-dashboard
Copy link

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@goderbauer
Copy link
Member

(triage): @mdebbar said this is still on his radar in the next few weeks.

@yjbanov
Copy link
Contributor

yjbanov commented Dec 12, 2023

Attempting to look at it from 30000 feet: Can viewId be determined by the slot created using SceneBuilder.addPlatformView? Then we don't need extra API on the platform view creation side. A platform view can start as "detached", and it would be "attached" when the framework calls FlutterView.render passing it a Scene containing the platform view ID. To move the platform view to a different FlutterView, simply call render on the new FlutterView and pass the platform view ID there. The engine can assert that the same platform view does not appear in multiple FlutterViews simultaneously.

@mdebbar
Copy link
Contributor Author

mdebbar commented Dec 15, 2023

Update: this PR may become superseded by flutter/engine#48960

auto-submit bot pushed a commit to flutter/engine that referenced this pull request Dec 21, 2023
This PR defers the injection of the contents of a Platform View into the DOM of the page, until the Platform View is really needed by a renderer.

This effectively means that a `platformView` will be injected into the DOM the first time that its `slot` is injected into the Shadow DOM of the Flutter web app.

This makes passing a `(flutter)ViewId` parameter from the framework unnecessary, even in a multi-view app.

The only cases in which this change might be breaking is those where an app tries to locate the just-created Platform View by looking into the DOM from the [`onPlatformViewCreated` callback](https://api.flutter.dev/flutter/widgets/HtmlElementView/onPlatformViewCreated.html). In those cases, [a fix like this](flutter/packages#5660) is needed (use the **only [documented way](https://api.flutter.dev/flutter/dart-ui_web/PlatformViewRegistry/getViewById.html)** to obtain the Platform View contents from its `viewId`)

## Issues

Fixes flutter/flutter#137287
Closes flutter/flutter#136548

[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
@mdebbar mdebbar deleted the pv_view_id branch January 12, 2024 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants