-
Notifications
You must be signed in to change notification settings - Fork 3.3k
[webview_flutter] Adds platform implementations for onHttpError callback #3695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[webview_flutter] Adds platform implementations for onHttpError callback #3695
Conversation
We should make sure #3675 gets the baseline file updates and then lands, and then this has that merged in, before this lands, so that we can better see what the baseline changes here are and if any new warnings are being introduced. This doesn't have to block initial review, but I'm flagging it now so that we don't forget. |
#3675 has been merged, so this PR will need to pull from main and handle the Android lint warnings. |
c550592
to
d62dfc3
Compare
d62dfc3
to
7a6086a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with last few nits
packages/webview_flutter/webview_flutter_wkwebview/ios/Classes/FWFDataConverters.h
Outdated
Show resolved
Hide resolved
packages/webview_flutter/webview_flutter_wkwebview/ios/Classes/FWFDataConverters.h
Outdated
Show resolved
Hide resolved
packages/webview_flutter/webview_flutter_wkwebview/ios/Classes/FWFDataConverters.h
Outdated
Show resolved
Hide resolved
packages/webview_flutter/webview_flutter_wkwebview/CHANGELOG.md
Outdated
Show resolved
Hide resolved
7a6086a
to
59b12f2
Compare
}), | ||
) | ||
..loadRequest( | ||
LoadRequestParams(uri: Uri.parse('https://www.google.com')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be primaryUrl
, not an actual site. Using real sites in integration tests makes tests much more prone to flake.
..loadRequest( | ||
LoadRequestParams( | ||
uri: Uri.parse( | ||
'https://www.google.nl', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
primaryUrl
FlutterError *error) { | ||
NSAssert(!error, @"%@", error); | ||
decisionHandler( | ||
FWFNativeWKNavigationResponsePolicyFromEnumData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has the some problem as the code discussed recently in the permission callback PR; it will unconditionally call the callback with an invalid value if Apple ever adds a new enum value. @bparrishMines Are you going to mass-fix this in a fast follow? I'm concerned about replicating a pattern that we know is dangerous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fixed now with #3812.
This also only affects enums that we receive from Objective-C. The Dart code shouldn't be able to return an enum the native side doesn't recognize.
) { | ||
if (weakThis.target?._onHttpError != null) { | ||
weakThis.target!._onHttpError!( | ||
HttpResponseError(statusCode: response.statusCode)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused; how is this callback intended to work in practice? You are throwing away the request object before it gets to the client, which means they will have absolutely no way of knowing whether the error is coming from a navigation (and if so to where) or a resource on the page (and if so, what). I'm not clear on what non-trivial use case a client could satisfy without having the request.
Am I missing something here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @bparrishMines who reviewed the overall PR, since it's core to the overall design. (It looks like the main PR only had one review before sub-parts started landing? Ideally that should have been two.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartmorgan It makes sense to include the request in the HttpResponseError object. Is it better to create a platform specific implementation for HttpResponseError and include the request in there, like AndroidWebResourceError, or include it in the HttpResponseError object itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it seems core to using this correctly, I would include it in the base object; it could be nullable in case there are implementations or cases where it's not available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartmorgan Sorry about that. I've been reviewing all of the WebView PRs as the owner of both the Android and iOS implementation, so I assumed it was fine to be the only approval for the aggregate PR. I'll start getting secondary reviews for those as well.
I agree with creating adding a request object to HttpResponseError
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually looks like Android and iOS have a request object and a response object.
Android:
https://developer.android.com/reference/android/webkit/WebResourceRequest
https://developer.android.com/reference/android/webkit/WebResourceResponse
iOS:
https://developer.apple.com/documentation/foundation/nsurlrequest?language=objc
https://developer.apple.com/documentation/foundation/nshttpurlresponse
In their respective methods,
https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455643-webview?language=objc
https://developer.android.com/reference/android/webkit/WebViewClient#onReceivedHttpError(android.webkit.WebView,%20android.webkit.WebResourceRequest,%20android.webkit.WebResourceResponse)
Android provides the request and response and iOS provides the response. I think we could add a nullable LoadRequestParams
to HttpResponseError
AND a new nullable WebResourceResponse
field.
@stuartmorgan @bparrishMines I've added a new PR #4025 which adds the request to the HttpResponseError object. |
Update from triage: the response object PR, which is blocking this, is still in progress. |
Update from triage: still waiting for #4025, then this can proceed. |
This is blocked on #4025 which is currently in review. |
Update from triage: #5790 has been created as a copy of the blocking PR, to work on unblocking this. |
Update from triage: the blocker has been landed, so this is ready to be updated. |
Closing in favor of the PR cross-linked just above, as this one isn't editable by the Flutter team. |
…plementations for onHttpError (#6149) Copy of #3695 since it doesn't contain permission to edit from contributors. Part of flutter/flutter#39502 Full PR #3278
…plementations for onHttpError (#6149) Copy of flutter/packages#3695 since it doesn't contain permission to edit from contributors. Part of flutter/flutter#39502 Full PR flutter/packages#3278
Reference #3278
Pre-launch Checklist
dart format
.)[shared_preferences]
pubspec.yaml
with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.md
to add a description of the change, following repository CHANGELOG style.///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.