0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
GGitHub[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675)
a2d2f165创建于 2025年2月27日历史提交
文件最后提交记录最后更新时间
example
[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675) When a DOM click event is received, we need to make a decision before the end of the event loop whether to allow the browser to navigate or not. At the end of the event loop, the browser will perform the navigation if we don't prevent it. The problem occurs when the followLink signal arrives AFTER the event loop (this can happen in semantics mode when the web engine uses a debouncer to queue events and send them to the framework after some delay). This leads to a situation where we can't make a definitive decision by the end of the event loop, so this PR does the following: 1. [best case] If the followLink signal is received before the end of the event loop, we let the browser do the navigation for a full web link experience. 2. [meh case] If no followLink signal is received before the end of the event loop, we PREVENT the browser from navigating. But we keep waiting for the followLink signal. If the signal arrives a bit later, we fallback to a programmatic navigation through the launchUrl API. Fixes https://github.com/flutter/flutter/issues/162927 Fixes https://github.com/flutter/flutter/issues/1624081 年前
lib
[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675) When a DOM click event is received, we need to make a decision before the end of the event loop whether to allow the browser to navigate or not. At the end of the event loop, the browser will perform the navigation if we don't prevent it. The problem occurs when the followLink signal arrives AFTER the event loop (this can happen in semantics mode when the web engine uses a debouncer to queue events and send them to the framework after some delay). This leads to a situation where we can't make a definitive decision by the end of the event loop, so this PR does the following: 1. [best case] If the followLink signal is received before the end of the event loop, we let the browser do the navigation for a full web link experience. 2. [meh case] If no followLink signal is received before the end of the event loop, we PREVENT the browser from navigating. But we keep waiting for the followLink signal. If the signal arrives a bit later, we fallback to a programmatic navigation through the launchUrl API. Fixes https://github.com/flutter/flutter/issues/162927 Fixes https://github.com/flutter/flutter/issues/1624081 年前
test
[various] Enable avoid_print (#6842) * [various] Enable avoid_print Enables the avoid_print lint, and fixes violations (mostly by opting example files out of it). * Version bumps * Add tooling analysis option file that was accidentally omitted * Fix typo in analysis_options found by adding tool sub-options * Revert most version bumps * Fix ios_platform_images3 年前
AUTHORS
[url_launcher] Fixed missing # in links href when opening in new tab on the web (#4221) 4 年前
CHANGELOG.md
[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675) When a DOM click event is received, we need to make a decision before the end of the event loop whether to allow the browser to navigate or not. At the end of the event loop, the browser will perform the navigation if we don't prevent it. The problem occurs when the followLink signal arrives AFTER the event loop (this can happen in semantics mode when the web engine uses a debouncer to queue events and send them to the framework after some delay). This leads to a situation where we can't make a definitive decision by the end of the event loop, so this PR does the following: 1. [best case] If the followLink signal is received before the end of the event loop, we let the browser do the navigation for a full web link experience. 2. [meh case] If no followLink signal is received before the end of the event loop, we PREVENT the browser from navigating. But we keep waiting for the followLink signal. If the signal arrives a bit later, we fallback to a programmatic navigation through the launchUrl API. Fixes https://github.com/flutter/flutter/issues/162927 Fixes https://github.com/flutter/flutter/issues/1624081 年前
LICENSE
Standardize copyright year (#3737) Standardizes all first-party copyrights on a single year, as is done in flutter/flutter and flutter/engine. All code now uses 2013, which is the earliest year that was in any existing copyright notice. The script checks now enforce the exact format of first-party licenses and copyrights. Fixes flutter/flutter#784485 年前
README.md
[url_launcher] launchUrl always returns true for valid schemes on the web. (#7229) ## Description Since noopener is used to open URLs, there is no way to determine if the browser has succesfully opened a given URL ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/open#noopener)). Therefore success is now assumed for supported schemes. Fixes https://github.com/flutter/flutter/issues/139783. Implementation largely follows suggestions by @ditman written down in [a comment](https://github.com/flutter/flutter/issues/139783#issuecomment-2249198392). The only exception is that launchUrl does not returns a hard-coded true, but a canLaunch(url). That way false is returned for invalid schemes (e.g. javascript:, as is checked in [an integration test](https://github.com/Frank3K/flutter_packages/blob/0c29f9463acb09a5ad8f1ada9ff16e7b8221bf68/packages/url_launcher/url_launcher_web/example/integration_test/url_launcher_web_test.dart#L119-L122)). ## Testing ### Sample application The following application can be used to validate the fix. Note that the print is executed using the current version of url_launcher_web (2.3.1) and that it does not execute when the fix from this PR is used. main.dart ```dart import 'package:flutter/material.dart'; import 'package:url_launcher/url_launcher.dart'; final Uri _url = Uri.parse('https://flutter.dev'); void main() => runApp( const MaterialApp( home: Material( child: Center( child: ElevatedButton( onPressed: _launchUrl, child: Text('Show Flutter homepage'), ), ), ), ), ); Future<void> _launchUrl() async { if (!await launchUrl(_url)) { // ignore: avoid_print print('Failed opening link.'); } } ```1 年前
pubspec.yaml
[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675) When a DOM click event is received, we need to make a decision before the end of the event loop whether to allow the browser to navigate or not. At the end of the event loop, the browser will perform the navigation if we don't prevent it. The problem occurs when the followLink signal arrives AFTER the event loop (this can happen in semantics mode when the web engine uses a debouncer to queue events and send them to the framework after some delay). This leads to a situation where we can't make a definitive decision by the end of the event loop, so this PR does the following: 1. [best case] If the followLink signal is received before the end of the event loop, we let the browser do the navigation for a full web link experience. 2. [meh case] If no followLink signal is received before the end of the event loop, we PREVENT the browser from navigating. But we keep waiting for the followLink signal. If the signal arrives a bit later, we fallback to a programmatic navigation through the launchUrl API. Fixes https://github.com/flutter/flutter/issues/162927 Fixes https://github.com/flutter/flutter/issues/1624081 年前
README.md

url_launcher_web

The web implementation of url_launcher.

Usage

This package is endorsed, which means you can simply use url_launcher normally. This package will be automatically included in your app when you do, so you do not need to add it to your pubspec.yaml.

However, if you import this package to use any of its APIs directly, you should add it to your pubspec.yaml as usual.

Limitations on the Web platform

A launch needs to be triggered by a user action

Web browsers prevent launching URLs in a new tab/window, unless triggered by a user action (e.g. a button click).

Even if a user triggers a launch through a button click, if there is a delay due to awaiting a Future before the launch, the browser may still block it. This is because the browser might perceive the launch as not being a direct result of user interaction, particularly if the Future takes too long to complete.

In such cases, you can use the webOnlyWindowName parameter, setting it to _self, to open the URL within the current tab. Another approach is to ensure that the uri is synchronously ready.

Read more: MDN > Transient activation.

Method launchUrl always returns true for allowed schemes

The launchUrl method always returns true on the web platform for allowed schemes. This is because URLs are opened in a new window using the noopener window feature. When the noopener feature is used, the browser does not return any information that can be used to determine if the link was successfully opened.

Read more: MDN > window.open.