It seems like links clicks handled via onclick attribute works for tel: protocol (although this is a workaround until this gets fixed):

onclick="window.location.href='tel:+390269016034';return false;"

+owen - this looks like another issue with the CCT link capturing.

We really need to work out who is owning this stuff. I think this fix is straightforward so I'll take a quick look, but we can't keep looking at this in SYD.

I'm fairly confident this is fixed in https://chromium-review.googlesource.com/c/chromium/src/+/844956, which has not yet reached Canary. The fix took a while to land because one of the reviewers was OOO.

jeffy/gilbertoc, can you please check back on this when the next Android Canary is released as to whether this issue is addressed?

Thanks for wrangling this Dom. Will ensure we get a transition plan sorted for this stuff ASAP.

jeffy@: ping - I think this should be fixed in the latest Chrome Canary (and possibly in Dev too). Can we verify so this bug can be updated?

Going to call this fixed, reopen if still an issue.

Apologies if I should instead open a new bug, but I'm seeing this as of today in Android Pie, Chrome 68.0.3440.91, on a PWA installed to the home screen.
For the mailto: link, I get a "blank" screen exactly as show on the original post.

The solution of window.location.href = "mailto:..." seems to fix it for the Android PWA, but on Windows, I want this to open in a new window (via window.open(..., '_blank') ); 

I will try to detect whether I'm in the Android installed-PWA and behave accordingly, for a workaround

#12: Why do you want these links to open in a new window on Windows? In Chrome at least, these sorts of links shouldn't actually navigate the page on desktop - they should pop up a dialog to get you to launch the appropriate app (since Chrome can't handle them it shouldn't navigate).

On my Windows (10,) Chrome does handle the mailto: link - it opens a gmail tab. With window.open and _blank target, that works as expected. If I set the window.location.href, however, then it navigates away from my app.

This is how gmail has been auto-configured for me, for quite a while (back to XP.) I don't think it's unusual. (Only recently did Win10 try to "suggest" I use their mail application.)

Thanks for your help!

Deleted: Capture.PNG 6.4 KB

	Capture.PNG 6.4 KB View Download

Ah, you have Chrome set up as the mailto: handler. That would explain the behaviour there. I wonder if this was actually fixed at all or if it was still broken when I previously closed it.... I'll reopen for now.

Do you have a test site handy? Otherwise I can whip one together but it would be good to directly use what you have to make sure I'm seeing the right thing.

Thanks for taking a look! Sorry that I don't have a public site handy to repro at this second, a brief description:

* PWA (based on Angular 6) installed to the home screen through Chrome on Android (versions stated above)
* Simple mailto: link with some escaped subject and body data
  * window.open(link, "_blank) opens the weird blank screen, as seen by the original filer
  * window.location.href = link works perfectly as stated, on Android, but isn't ideal on Windows for reason above

(It does seem like this might not have been fixed originally.) Thanks again for your help! 

I'll try and follow this up next week, thanks for the extra details here.

Sorry for the delay here. I've finally got around to getting some time to dig.

I think the issue is that on Android, it's actually Chrome's job to figure out how to handle mailto. But the code that handles window.open unconditionally opens a CCT if it doesn't find a specialized handler, resulting in the broken behaviour.

A simple fix (hopefully) is to prevent opening any non HTTP(S) URL in a custom tab. Working on that now.

So this is fairly diabolical. What's happening currently is that from the installed WebAPK:

1. we open the mailto link in a CCT
2. during the loading process, we go through the ExternalNavigationHandler#shouldOverrideUrlLoadingInternal()

Which is the same pathway as for opening when not in the standalone WebAPK and just opening in a browser tab. However, in the WebAPK case, we launch the CCT via a Custom Tabs intent, which is recorded as a flag during shouldOverrideUrlLoadingInternal and means that we early-exit without launching the external app since we think the intent is intended for Chrome.....

So part 1 of the fix is to mark that the incoming intent isn't from an external source ("FROM_API") when Chrome launches it. I don't think there are bad implications from that, but I'll need to get input from Custom Tabs experts on that...

But that isn't sufficient, because the user gesture used for window.open() is then lost when the intent is translated to a navigation, which also trips up opening the external protocol. So we also need to plumb a user gesture through.

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

commit b63b45e4c49bf9af674e09d9bd362a1a10ee6bff
Author: Dominick Ng <dominickn@chromium.org>
Date: Fri Oct 26 01:39:22 2018

Ensure Custom Tab intents opened by WebAPKs are treated like link navigations.

On Android, Chrome is responsible for handling external protocols and
determining if an external activity should be launched. When an
installed WebAPK opens a Chrome Custom Tab for an out of scope link, the
external protocol handling code was not being triggered for links like
mailto: and tel:, resulting in a broken CCT launch to the mailto: link
containing a blank page. This issue was caused by two reasons:

1. The navigation type for the Custom Tab intent was set to
   PageTransition.FROM_API, indicating it came from an external intent.
   This would trigger a code path that explicitly avoided launching an
   external program.
2. Once (1) was addressed, the lack of a user gesture on the resulting
   navigation created by the intent also blocked external program
   launch.

This CL fixes both issues by introducing a new Custom Tab extra indicating
whether a Custom Tab intent came from a WebAPK. When this extra is
present, we do not set the FROM_API transition type, and we add a user
gesture on the resulting new tab navigation. This essentially passes on
the user gesture that must have been present to create the new tab in
the first place, mimicking the behaviour that should be present when
not in a standalone window.

BUG=792990

Change-Id: Ifad590228b10fa7a09c1c34611124957ba857ac1
Reviewed-on: https://chromium-review.googlesource.com/c/1270204
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: Peter Conn <peconn@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602970}
[modify] https://crrev.com/b63b45e4c49bf9af674e09d9bd362a1a10ee6bff/chrome/android/java/src/org/chromium/chrome/browser/LaunchIntentDispatcher.java
[modify] https://crrev.com/b63b45e4c49bf9af674e09d9bd362a1a10ee6bff/chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabActivity.java
[modify] https://crrev.com/b63b45e4c49bf9af674e09d9bd362a1a10ee6bff/chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabIntentDataProvider.java
[modify] https://crrev.com/b63b45e4c49bf9af674e09d9bd362a1a10ee6bff/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappTabDelegate.java

I think this is addressed now that #21 has stuck. It will be out in M72.