You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[webview_flutter] Update to standard platform interface structure #94051
The webview plugin was (IIRC) the first plugin to use a platform-interface-like concept, and clearly predates most of what is now standard practice. In particular:
The platform interface doesn't inherit from PlatformInterface
The instance is managed in the app-facing package's class, not the interface package's class, which prevents self-registration
The implementations implement rather than extend it (which would have been prevented if 1 weren't true)
Both 2 and 3 are problematic; 2 because it doesn't really allow for unendorsed implementations, and 3 because we are now in a situation where we essentially can't make any change to the platform interface—adding methods is effectively a breaking change. We can't just fix the implementation packages to extend and then change it, because nothing would prevent older versions of the implementation packages from getting a new version of the interface package and failing (unlikely though that would be).
There are two options:
Do a breaking change to the interface package, and fix it to look like other packages.
Replace the platform interface in a non-breaking way.
It's not clear to me yet whether 2 is possible because the flow is very unusual here, and involves multiple classes, at least on of which is publicly exposed through the app-facing package. (And it's not clear to me yet, not having worked extensively in this plugin, why any of that is true.) My general thought though is that we would define a new, much more standard-looking platform interface within the existing interface package, and then make a default implementation (also in that package) that implements the old interfaces as an adapter. (Because WebviewPlatform is publicly exposed in the app-facing package we'd need a breaking change there to clean that part up, but we're already planning a breaking change at the app-facing level so that's doable.)
This comment is ment as addition to @stuartmorgan's issue and hopefully gives some additional insight.
The webview_flutter_platform_interface defines multiple classes that need to be implemented (or rather extended) by the platform specific packages to tie everything together. These classes are:
WebViewPlatformController: this class defines the method channel interface and contains all methods that handle the communication between the Dart and the host platform. In the standard situations this class would inherit from the PlatformInterface;
WebViewPlatformCallbacksHandler: this class defines callbacks from the host platform (e.g. onPageFinished which is called when a page is finished loading). This class can be implemented by consumers of the plugin to be informed about the events from the WebView control. The app-facing package wraps this in an internal class and exposes the functionality through callback methods that can be registered with the WebView widget, however the whole WebViewPlatformCallbacksHandler is still publicly exposed and changes are somebody implemented it;
WebViewPlatform: this class is implemented by platform specific packages (i.e. webview_flutter_android and webview_flutter_wkwebview) to provide the correct platform view widget.
The platform interface, iOS implementation, and app-facing interface are all completed. The only tasks remaining are the Android implementation and some final improvements that I will list below.
Interface method runJavaScriptReturningResult should return an Object since iOS can return nums and bools.
Platform specific controller methods in the interface should be moved to their respective platform implmementations. (e.g. enableGestureNavigation for iOS and enableDebugging for Android.) This will also provide us a way to create an example of accessing platform specific features.
AutoMediaPlaybackPolicy is missing from the implementations. (This should be in the creation params on iOS and can be in the controller for Android).
LoadRequestParams.headers should have a default value.
JavaScriptChannelParams should be @immutable.
getScrollPosition should return an Offset and not a Point. This is opinionated, but I think Offset is more appropriate for the return value for a WebView. Point is from dart:math while Offset is from dart:ui and is exposed by the Flutter SDK.
WebResourceError should include optional isForMainFrame. - Change WebViewController -> WebController and WebViewWidget -> WebView? I've been thinking about the comments made in the interface doc and have been considering making this change. It is weird that we include Widget in the widget name. This could be a better alternative. Thoughts on this one @stuartmorgan@mvanbeusekom?
Hi guys,
do you know, when the new version will be available. I do have a problem with <input type="file"> nothing happened. flutter-team-archive/plugins#3225
Installed webview_pro, but there is an issue with choosing the camera (couldn't find meta data for provider with authority)
Can you help me? Will this issue here fix my problem? Do you habe a workaround?
@scharfenort That issue is being tracked at #27924 and the PR to fix it is blocked by this. We are actively working on this one now, but I can't give you a time frame when it will be finished.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
mvanbeusekom commentedon Nov 26, 2021
This comment is ment as addition to @stuartmorgan's issue and hopefully gives some additional insight.
The webview_flutter_platform_interface defines multiple classes that need to be implemented (or rather extended) by the platform specific packages to tie everything together. These classes are:
WebViewPlatformController: this class defines the method channel interface and contains all methods that handle the communication between the Dart and the host platform. In the standard situations this class would inherit from thePlatformInterface;WebViewPlatformCallbacksHandler: this class defines callbacks from the host platform (e.g.onPageFinishedwhich is called when a page is finished loading). This class can be implemented by consumers of the plugin to be informed about the events from the WebView control. The app-facing package wraps this in an internal class and exposes the functionality through callback methods that can be registered with theWebViewwidget, however the wholeWebViewPlatformCallbacksHandleris still publicly exposed and changes are somebody implemented it;WebViewPlatform: this class is implemented by platform specific packages (i.e. webview_flutter_android and webview_flutter_wkwebview) to provide the correct platform view widget.bparrishMines commentedon Feb 15, 2022
Design Doc for the new interface: flutter.dev/go/webview_flutter_4_interface
bparrishMines commentedon Sep 22, 2022
Update
The platform interface, iOS implementation, and app-facing interface are all completed. The only tasks remaining are the Android implementation and some final improvements that I will list below.
runJavaScriptReturningResultshould return anObjectsince iOS can returnnums andbools.enableGestureNavigationfor iOS andenableDebuggingfor Android.) This will also provide us a way to create an example of accessing platform specific features.AutoMediaPlaybackPolicyis missing from the implementations. (This should be in the creation params on iOS and can be in the controller for Android).LoadRequestParams.headersshould have a default value.JavaScriptChannelParamsshould be@immutable.getScrollPositionshould return anOffsetand not aPoint. This is opinionated, but I think Offset is more appropriate for the return value for aWebView.Pointis fromdart:mathwhileOffsetis fromdart:uiand is exposed by the Flutter SDK.WebResourceErrorshould include optionalisForMainFrame.- ChangeWebViewController->WebControllerandWebViewWidget->WebView? I've been thinking about the comments made in the interface doc and have been considering making this change. It is weird that we includeWidgetin the widget name. This could be a better alternative. Thoughts on this one @stuartmorgan @mvanbeusekom?stuartmorgan-g commentedon Sep 26, 2022
What's the motivation for this one?
WebViewControllerseems more specific and more clearly associated with the webview itself.bparrishMines commentedon Oct 4, 2022
My thoughts on changing it stemmed from creating and following a consistent pattern. e.g.
WebController->WebViewGoogleMapController->GoogleMapViewTabController -> TabBarView.
Although, I agree that
WebViewControlleris a more accurate name. And I would guess that people prefer accurate naming over consistent naming.scharfenort commentedon Oct 27, 2022
Hi guys,
do you know, when the new version will be available. I do have a problem with
<input type="file">nothing happened.flutter-team-archive/plugins#3225
Installed webview_pro, but there is an issue with choosing the camera (couldn't find meta data for provider with authority)
Can you help me? Will this issue here fix my problem? Do you habe a workaround?
bparrishMines commentedon Oct 28, 2022
@scharfenort That issue is being tracked at #27924 and the PR to fix it is blocked by this. We are actively working on this one now, but I can't give you a time frame when it will be finished.
github-actions commentedon Mar 4, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.