[webview_flutter] NavigationDecision.prevent prevents the initial page to load on IOS 13.7 #65502
Comments
|
Happened to me to. |
|
+1 |
|
I can reproduce this on the latest master navigationDelegate: (NavigationRequest _redirectRequest){
return NavigationDecision.prevent; //Blocks all internal html navigation requests.
},This was previously #30256 flutter doctor -vMinimal reproducible code sampleimport 'dart:async';
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
Completer<WebViewController> _controller = Completer<WebViewController>();
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Sample',
home: Scaffold(
appBar: AppBar(
title: Text('Sample'),
),
body: WebView(
initialUrl: 'https://flutter.dev',
javascriptMode: JavascriptMode.unrestricted,
onWebViewCreated: (WebViewController controller) {
_controller.complete(controller);
},
//This causes the issue
/*navigationDelegate: (NavigationRequest _redirectRequest) {
return NavigationDecision
.prevent; //Blocks all internal html navigation requests.
},*/
),
),
);
}
} |
markusaksli-nc
added
found in release: 1.22
|
The problem seems to be isolated to '''NavigationDecision.prevent;''' as the other NavigationDecision options work. |
TahaTesser
changed the title
TahaTesser
changed the title
|
Looks like there is a behavior difference between Android and iOS. If the desired behavior is to always load the initial page, a simple workaround is to filter out the url of the initial page. Like: That being said. I'm not sure which should be the correct behavior. My intuition is that the initial page should be considered as a navigation as well. So blocking the first page when Although fixing it on Android could be a breaking change for many users if many users are relying on this behavior for a while. Any thoughts? @bparrishMines @amirh |
|
@cyanglaz You are correct. I would agree that the behavior on Android is the outlier actually if the initial page is also a navigation. That being said I don't share that intuition and I don't think that makes sense for the most common use cases. Is there any reason you would want to treat the initial page as a navigation and have to code separate logic for it? The only use case I can imagine is if you don't want to load the initial page based on some app state logic. The only extra thing you get out of intercepting it through NavigationRequest is I won't pretend to know what the correct approach is here either, these are my thoughts. Whatever the solution here would be, none of this is in navigationDelegate or NavigationDecision docs right now. This should be mentioned since it will probably be counterintuitive to some people in either case. |
cyanglaz
changed the title
|
At the platform level, the difference lies in how loading a URL is handled. Android doesn't include calls to loadUrl when filtering, but iOS does when calling loadRequest. Setting My intuition agrees that any value set for If we decided to go this route, the change would probably look similar to: flutter/plugins#3092. @cyanglaz thoughts? |
|
@bparrishMines Yeah, I agree that we can make the iOS behavior similar to android. |
|
@cyanglaz |
jmagman
added this to Awaiting triage
in iOS Platform - first party plugin and package review
|
Any more developments on this issue please? I am experiencing the same problem, is there an alternative? |
|
I'm with the same problem, i need to use NavigationDecision to block navigate inside the WebView, although, when i use There's an alternative for my case: Define a bool variable like "_blockNavigation" and in the WebView, do like bellow.
Doing this, I can load the view and lock the navigation to another view, inside WebView. |
|
(Triage) If we use the simple_example mentioned in the plugin repo, it has the implementation as mentioned here, running which, loads the webview properly as below:
@FiresBurger Can you let us know if above is an acceptable solution ? /cc @cyanglaz for further insights. |
darshankawar
added
the
waiting for customer response
|
Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. |
|
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-triage-bot
bot
added
the
package
Steps to Reproduce
flutter create bug.main.dart
info.plist
pubspec.yaml
Create an new flutter project
Expected results:
A scaffold containing the flutter website within the body
Actual results:
scaffold with blank webview
Logs
The text was updated successfully, but these errors were encountered: