I've tested this on multiple devices including those running the Android System WebView app (version 61) and was able to reproduce the same errors.

please mycall android 7.0

We don't implement this API in WebView. It shouldn't get as far as throwing an internal error from the missing mojo interface: the entire API should simply be disabled in webview so that it can be feature-detected as unsupported.

Tim, want to take this?

We need to add this to the list of apis that we should look at implementing in future, also.

What's the best way to detect whether this feature is actually implemented? 
Currently we are using presence of `navigator.share` to detect this feature which creates bugs (e.g. https://github.com/ampproject/amphtml/issues/11473) for us in WebView and Custom Tabs where this does not work.

We need to fix this bug so that feature detection will work properly.

Thanks. Could we temporarily try/catch a dummy "navigator.share" call in addition to checking presence of `navigator.share`? Do you foresee any potential issues with this approach?

Not sure if there's any way to do that which will trigger an error here but not do anything you don't want on a useragent which does implement this API, and you probably can't rely on any details of how it fails because this is an accident of implementation.

Got it. Thanks for the explanation. 

Hi again, Is there any ETA for the fix? Any change to prioritize some quick fix? (e.g. no exporting navigator.share until it is implemented)?

Yes, removing navigator.share is how we will resolve this bug, per comment 3. (we're unlikely to implement this API any time soon and it would require Android OS changes to expose application controls).

mgiuca: FYI here, this feature probably should have been flagged off for webview :/ Not sure why we didn't catch this in the interface list layout test..

Looks like it is broken in both Custom Chrome Tabs and WebViews. Any chance it can be implemented in CCT sooner than WebView? 

Essentially I am proposing:

P0: remove navigator.share in broken cases right away
P1: Implement navigator.share in CCT
P3: Implement navigator.share in CustomTabs

I'd expect it to work as normal in CCT since that's just Chrome; if that's broken you should probably file a separate bug with a repro case.

#11 It works for me in a CCT on Chrome 61 (tested in a CCT within Hangouts).

+sammc: Any idea how we can make the API not show up in Navigator if the Mojo service is unavailable? As far as I know, we only attempt to connect to the Mojo service when it is called (otherwise it would require us to make Mojo connection on all APIs when the page loads). So we would need some other way to hard-code whether to expose the API or not. Is WebView a different build of Chromium, or does it use the same binary?

I don't know why the interface listing test isn't catching this. This is the global interface expected list for Android WebView, right?

https://cs.chromium.org/chromium/src/android_webview/tools/system_webview_shell/test/data/webexposed/global-interface-listing-expected.txt

That file does not list "share" in the Navigator interface.

Hi, all.
AFAIK Facebook's app loads urls in CCT. If yes, it's not working.
I'm attaching a video showing this behavior, after this I opened the same URL in Chrome, then clicked the share button and it works nicely.

I hope it helps.

Deleted: WhatsApp Video 2017-10-04 at 16.52.08.mp4 5.4 MB

	WhatsApp Video 2017-10-04 at 16.52.08.mp4 5.4 MB View Download

No, Facebook does not use CCT; that's a WebView inside the facebook app.

Ok, thanks.

CCT is working fine, then. (just tested in Gmail APP)

CL to fix: https://chromium-review.googlesource.com/c/chromium/src/+/704415

I will be on leave shortly so sammc@ to take over.

 Issue 773121  has been merged into this issue.

Tim, it'd be good if you can figure out why the interface listing test didn't catch this, separately to the change to disable the API.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba6a9d8235a14e6d41d8736597cb4cc6b0dcf7ba

commit ba6a9d8235a14e6d41d8736597cb4cc6b0dcf7ba
Author: Sam McNally <sammc@chromium.org>
Date: Tue Oct 10 23:44:46 2017

Only expose navigator.share in Chrome (not content).

This avoids exposing the method in clients of content that do not have a
Web Share Mojo service.

Cloned from https://crrev.com/c/704415 by mgiuca@chromium.org.

Bug: 765923
Change-Id: I4db2b06a26f6c929ed4b2875ba2ff6c64cd84799
Reviewed-on: https://chromium-review.googlesource.com/708114
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Sam McNally <sammc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507824}
[modify] https://crrev.com/ba6a9d8235a14e6d41d8736597cb4cc6b0dcf7ba/chrome/renderer/chrome_content_renderer_client.cc
[modify] https://crrev.com/ba6a9d8235a14e6d41d8736597cb4cc6b0dcf7ba/chrome/renderer/chrome_content_renderer_client.h
[modify] https://crrev.com/ba6a9d8235a14e6d41d8736597cb4cc6b0dcf7ba/content/child/runtime_features.cc

Hi, all.
Don't you think this bug is a priority 1?
There are more and more publishers adopting web share API that doesn't work on WebView.

Thanks

It's difficult to solve this generally. WebView probably shouldn't just trigger an Android intent automatically, but send a signal to the embedding app. Alternatively, maybe it should just trigger an intent, but this will be difficult to get working since the implementation is in Chrome (not content).

If refactoring is required to move that code from Chrome to content, I think that's reasonable, but I'm not an expert on WebView so I don't know what would be required to make it work, or what the correct behaviour should be.

Assigning back to Tim to triage and decide what the behaviour should be.

We should figure out why the interface test didn't catch this before we shipped it in the nonworking state. Tim?

I don't think it's acceptable to directly trigger an intent without app control here; we don't do that in any other case.

Right, I'll have a look..

Thanks for taking care to not expose this api for WebView. Sounds like we might indeed need a callback in WebView to properly support this in apps..

We don't really escalate this type of regression automatically. Normally speaking it's up to the developer of the new feature to verify that it is working/not working in WebView and notify the WebView team of any issues before launch. I think the intent to ship template also covers that.

Now that the Web Share API not exposed, I've added it to our not-exposed list for WebView, which will ensure it's not exposed going forward. There is a patch [1], pending landing..

Additionally, if there is a switch to disable the web share api I think that would be generally preferable. We disable a number of API for WebView using command line switches [2]

[1]
https://chromium-review.googlesource.com/c/chromium/src/+/776716

[2] https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?type=cs&q=kDisableRemotePlaybackAPI&sq=package:chromium&l=58-165

Isn't there a test which verifies that interfaces aren't added, though?

Yes there is, but we switched it to non-failing some time ago, due to high number of rebases and high load for the sheriffs.. I might revisit it to see if we can improve there..

I thought the idea was that we would be monitoring this and would make sure that we'd reconciled any failures before a release went out, though :)

If we aren't watching it then the test is pointless; we need this to notify us so we can follow up.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/77572d340128d8b8ee002c4d35a1f67b94a91064

commit 77572d340128d8b8ee002c4d35a1f67b94a91064
Author: Tim Volodine <timvolodine@chromium.org>
Date: Mon Nov 20 12:43:38 2017

[Android WebView] Update not exposed listing for navigator.share

Web Share API is currently not supported by Android WebView and
hence should not be exposed.

This patch makes sure this is the case, and will be verified
automatically by the Android WebView bots on the waterfall.

BUG=765923
NOTRY=true

Change-Id: I1c8d2f078c6b8ebe136c64cd0763645008e44b4e
Reviewed-on: https://chromium-review.googlesource.com/776716
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Tim Volodine <timvolodine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517803}
[modify] https://crrev.com/77572d340128d8b8ee002c4d35a1f67b94a91064/android_webview/tools/system_webview_shell/test/data/webexposed/not-webview-exposed.txt

torne@:
Yes, the test does log the new exposed interfaces, most of which are OK (not webview specific) and can go through without any issues. I agree it would be good to have a notification mechanism for this.. maybe send an email or expose some webpage where the interfaces can be 'approved'..

Can you create a bug to set up some process/monitoring to make sure we keep up with this?

created crbug.com/787868: Set up monitoring/approval process for the newly exposed interfaces in Webview

I have tested this (via https://s.codepen.io/aghassemi/debug/BVoRRN ) using WebViewTest app on Android and seems to be fixed in Chrome 66 (or prior). 

Could someone from Chromium reverify and close the issue please. Thank you.