Web share api не поддерживается текущим браузером

Обновлено: 02.07.2024

I have a <WebView> in my app built using Expo and React Native.

The webview opens a page that uses the Web Share API, i.e. navigator.share(< url: 'url' >) .

However, navigator.share is not available inside the webview.

If the same page is opened within a normal browser, sharing works as expected.

To Reproduce:

Call navigator.share from inside a page opened in a webview and see that it's undefined.

Expected behavior:

navigator.share should be defined and working.

Environment:

OS: Android
OS version: 8
react-native version: "react-native": "https://github.com/expo/react-native/archive/sdk-35.0.0.tar.gz",
react-native-webview version:

The text was updated successfully, but these errors were encountered:

riteshvsharma commented May 10, 2020

I am facing the same issue with Webview on Android. It works perfectly on iOS. Any updates?

fodkastir commented Jun 8, 2020

Mohsin92 commented Jul 2, 2020

I am facing the same issue.
If in iOS working then why can't we can run in Android webview?

alpkahveci commented Jul 16, 2020

omg why does not work in android webview? It is not normal. i am opening in mobile browser, it is working perfectly but in webview app not work! (they have completely same user agent !!)

alpkahveci commented Jul 16, 2020

Guyz! I have a good news. You can do it with native and javascript. here is the solution. I hope it will work for you :)

github-actions bot commented Sep 15, 2020

Hello 👋 , this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

vjbobeldijk commented Oct 30, 2020

It's still driving me crazy 30-10-2020

simple-software-lab commented Dec 21, 2020

How do you re-open this issue? It is still a problem.

ramisalem commented Feb 25, 2021

Any updates on this?

r000bin97 commented Apr 8, 2021

Does anyone have a solution?

vjbobeldijk commented Apr 8, 2021

For my website on android chrome and iphone safari, I had the problem being stuck when opening my website from within the messenger webview. So I force open those browsers with some javascript code. Maybe you could open a new page with the navigator.share on it. But then you aren't in your own webview anymore. And I have a website, not an app. If you want that little piece of javascript, please tell.

simioni commented Sep 29, 2021

This is still a problem in late 2021. The navigator.share() method has been around since 2017, but it's still not supported in the Android WebView. This is not specific to React Native, so I don't know if there is any solution that can come from this project apart from instructions on how to do it directly from java / kotlin.

Luckily, it's easy enough to launch a share intent from native android code. All that is needed is an interface object to expose methods that can be called from javascript. @alpkahveci linked to some code that shows how to add such an interface in java.

The navigator.share() method of the Web Share API invokes the native sharing mechanism of the device to share data such as text, URLs, or files. The available share targets depend on the device, but might include the clipboard, contacts and email applications, websites, bluetooth, etc.

This method requires that the current document have the web-share permission policy and transient activation. (It must be triggered off a UI event like a button click and cannot be launched at arbitrary points by a script.) Further, the method must specify valid data that is supported for sharing by the native implementation.

The method resolves a Promise with undefined . On Windows this happens when the share popup is launched, while on Android the promise resolves once the data has successfully been passed to the share target.

Syntax

Parameters

An object containing data to share.

Properties that are unknown to the user agent are ignored; share data is only assessed on properties understood by the user agent. All properties are optional but at least one known data property must be specified.

url : A USVString representing a URL to be shared.
text : A USVString representing text to be shared.
title : A USVString representing a title to be shared.
files : An array of File objects representing files to be shared.

Return value

A Promise that resolves with undefined , or rejected with one of the Exceptions given below.

Exceptions

The Promise may be rejected with one of the following DOMException values:

The web-share permission has not been granted, or the window does not have transient activation, or a file share is being blocked due to security considerations.

The specified share data cannot be validated. Possible reasons include:

The data parameter was omitted completely or only contains properties with unknown values. Note that any properties that are not recognized by the user agent are ignored.
A URL is badly formatted.
Files are specified but the implementation does not support file sharing.
Sharing the specified data would be considered a "hostile share" by the user-agent.

The user canceled the share operation or there are no share targets available.

There was a problem starting the share target or transmitting the data.

Examples

The example below shows a button click invoking the Web Share API to share MDN's URL. This is taken from our Web share test (see the source code).

The HTML just creates a button to trigger the share, and a paragraph in which to display the result of the test.

JavaScript

Result

Click the button to launch the share dialog on your platform. Text will appear below the button to indicate whether the share was successful or provide an error code.

Open with Desktop
View raw
Copy raw contents Copy raw contents Loading

Copy raw contents

Web Share API Explained

Written: 2016-05-30, Updated: 2017-07-04

Web Share is a proposed web API to enable a site to share data (text, URLs, images, etc) to an arbitrary destination of the user's choice. It could be a system service, a native app or another website. The goal is to enable web developers to build a generic "share" button that the user can click to trigger a system share dialog.

This is a product of the Ballista project, which aims to explore website-to-website and website-to-native interoperability.

, the formal draft spec. , for platform-specific matters.

Here's how a user could share a link from a website to a native app of their choice, on a site using Web Share. These mocks look a bit like Android, but we're designing with general desktop and mobile operating systems in mind.

User is browsing a website containing a gallery of photos. User clicks a "share" link (denoted by the generic share icon) for a specific photo. The website calls navigator.share (see code) with a custom title, text and/or URL (in the common case, just share a URL pointing at the selected photo).
A modal picker dialog is shown to the user, with a set of native applications and system actions (e.g., "Gmail", "Facebook", "Copy to clipboard"). On Android, this is the system intent picker, but the implementation may differ between browsers and operating systems. The user picks "Gmail".
The Gmail native app opens, and is pre-populated with the title, text and URL.

To let the user share the current page's URL with an app or website of their choosing, just attach this JavaScript code to a "share" button.

Developers should be aware that not all user agents will provide navigator.share (sometimes intentionally; for instance, a browser may not provide it when running on a platform that has no share support). Feature detection can be used to avoid showing a non-functioning button on a web page:

Frequently Asked Questions

Why is this needed?

We want to give users a way to quickly get content they find on the web (primarily URLs, but also other text and image data) into their favourite apps and services (social networking, text messaging, note taking).

Share buttons to specific web services (e.g., Facebook and Twitter buttons).
Share buttons built into the browser UI. Many browsers, especially on mobile, have a "share" button that sends the current page URL to a native app of the user's choice.

The site author is not able to present the share button in-line (requiring the user to go into a browser menu to activate).
Only the current page URL can be shared, rather than specific pieces of content.
The browser UI may not always be available, e.g., when a web app has been installed as a standalone/fullscreen app.

So we'd like to build an API that solves all of these problems by giving website authors a way to directly share arbitrary content to an app of the user's choosing.

How can a web app receive a share from another page?

We definitely want to let web apps receive shares, not just send them. To keep the discussion focused, we've split that functionality out into a separate proposal, the Web Share Target API.

How is this different from other web intents / sharing systems?

There have been several past attempts at doing this, notably Web Intents and Mozilla's Web Activities, both of which are no longer being developed.

We'd ultimately like to tackle the problems that those projects were trying to solve (building a generic intents system for the web), but for now, we are just focusing on the Share use case, and we think this focus will help avoid the scope creep and over-generalized UI of those past attempts.

We also intend to interoperate with native apps right away, which solves the bootstrapping problem of needing to wait for web developers to write share targets before the Share API can be useful.

Why can't sites just use Android intent: URLs?

On Android, web pages can have special links to intent:// URLs, which are currently supported on Chrome and Firefox. Clicking such a URL fires an Android intent. The intent can be targeted at a specific app (by its Android package name) or be untargeted (showing the app picker UI).

Sites can use this right now to implement a generic share button, but there are a number of issues:

It only works on Android.
For security reasons, the intent is forced to have the BROWSABLE category (which means it can only be received by Android apps that are happy to receive intents from the web; in practice, there are very few such apps).
It only lets users choose native apps (not websites).

We think the web deserves a standardized API for this.

Why not standardize Android intent: URLs?

Android intent: URLs are too powerful and specific to Android. They can target a specific Android app (by its Java package name), have any action (not just SEND ), and use Android-specific terminology and syntax.

Standardizing this would require at least some changes to the syntax and additional restrictions, as well as removal of the BROWSABLE restriction, so we'd have to change the name. Given that we'll be making incompatible changes, we may as well design a new API from scratch.

Why not make a share URI scheme (like mailto:) instead of a JavaScript API?

This is largely sound and has a couple of advantages over the DOM API:

The link can be placed declaratively on the page, with no need for a JavaScript click event handler.
A page could register to receive shares via the registerProtocolHandler API without the need for a new Share Target API.

but this has a few practical concerns:

Sharing the page's own URL (a very common case) would require some scripting to inject the page URL into the href attribute.
There is no API to determine whether share is supported on the user's system.
There is no promise or callback to signal the success or failure of the share action.

as well as the theoretical issue (shared with mailto: and intent: ) that URIs are supposed to identify resources, not specify actions (See RFC 3986 § 1.2.2 Separating Identification from Interaction). This would be a bit of an abuse of the URI concept (albeit with precedent). See detailed discussion here.

Whether to do this as an alternative to a DOM API should be part of the discussion around this proposal.

Web apps can use the same system-provided share capabilities as platform-specific apps.

With the Web Share API, web apps are able to use the same system-provided share capabilities as platform-specific apps. The Web Share API makes it possible for web apps to share links, text, and files to other apps installed on the device in the same way as platform-specific apps.

Sharing is only half of the magic. Web apps can also be share targets, meaning they can receive data, links, text, and files from platform-specific or web apps. See the Receive shared data post for details on how to register your app as a share target.

System-level share target picker with an installed PWA as an option.

Web share has the following capabilities and limitations:

To share links and text, use the share() method, which is a promise-based method with a required properties object. To keep the browser from throwing a TypeError , the object must contain at least one of the following properties: title , text , url or files . You can, for example, share text without a URL or vice versa. Allowing all three members expands the flexibility of use cases. Imagine if after running the code below, the user chose an email application as the target. The title parameter might become the email subject, the text , the message body, and the files, the attachments.

If your site has multiple URLs for the same content, share the page's canonical URL instead of the current URL. Instead of sharing document.location.href , you would check for a canonical URL <meta> tag in the page's <head> and share that. This will provide a better experience to the user. Not only does it avoid redirects, but it also ensures that a shared URL serves the correct user experience for a particular client. For example, if a friend shares a mobile URL and you look at it on a desktop computer, you should see a desktop version:

To share files, first test for and call navigator.canShare() . Then include an array of files in the call to navigator.share() :

Notice that the sample handles feature detection by testing for navigator.canShare() rather than for navigator.share() . The data object passed to canShare() only supports the files property. Image, video, audio, and text files can be shared. (See Permitted File Extensions in Chromium.) More file types may be added in the future.

Santa Tracker share button.

Santa Tracker, an open-source project, is a holiday tradition at Google. Every December, you can celebrate the season with games and educational experiences.

In 2016, the Santa Tracker team used the Web Share API on Android. This API was a perfect fit for mobile. In previous years, the team removed share buttons on mobile because space is at a premium, and they couldn't justify having several share targets.

But with the Web Share API, they were able to present one button, saving precious pixels. They also found that users shared with Web Share around 20% more than users without the API enabled. Head to Santa Tracker to see Web Share in action.

Browser support for the Web Share API is nuanced, and it's recommended that you use feature detection (as described in the earlier code samples) instead of assuming that a particular method is supported.

As of early 2021, using the API to share title, text, and URL is supported by:

Safari 12 or later on macOS and iOS.
Chrome 75 or later on Android, and 89 or later on Chrome OS and Windows.

Using the API to share files is supported by:

Safari 15 or later on macOS and iOS.
Chrome 75 or later on Android, and 89 or later on Chrome OS and Windows.

(Most Chromium-based browsers, like Edge, have the same support for this feature as the corresponding version of Chrome.)

Are you planning to use the Web Share API? Your public support helps the Chromium team prioritize features and shows other browser vendors how critical it is to support them.

Читайте также: