If you can point to or create a specific reproduction case for us (APK to install and server) then we can more quickly investigate (bisect to find what change broke this after Chrome 50).

Maria, do you remember what change went in to cause this?  Intended?

We actually never redirect to apps based on response -- we only redirect to apps based on request data (before the request actually occurs). The visible behaviour change may be due to our changes to the download system. Min, can you comment on that?

Looks like a user gesture related issue.
When clicking a link to start Chrome, how the user gesture is passed into Chrome?  If not, we don't allow an external app to be invoked.

Can you try clicking a link inside Chrome, to see if step 4 is executed?

Hi,

I will have to take product manager's opinion if the app and the server can
be shared as this is an enterprise app and it belongs to Nokia.

I will revert back to you.

Thanks
Subijay

I am attaching simple apk file which simulates same behavior like our bootstrap does. It will start activity (just a dummy window on device) once URL with special mediaType got clicked.

I also deployed sample servlet on our demo server (accessible via internet) http://195.207.5.235:8088/webapp_war/test. 

once you install that application (note it does not have default activity, so no app icon will be visible on device) and in browser just enter URL which I mention.
in firefox it will ask which application to start with that URL (TestActivity is the name of that demo app). click on that icon and the dummy dialog window will open.

From chrome55 it will just download without promting.

Deleted: app-debug.apk 1.8 MB

app-debug.apk 1.8 MB Download

Hi, 
Any updates on this please? Were you able to reproduce the condition?

Hi,

We had a very similar issue in our company as well, where deep links were all of a sudden "not happenning" in the WebView, starting from Chromium v55. It seems like I've found the root cause of the issue, and the solution as well, I hope this may help you in some way, as our use case is not exactly the same.

Check out the documentation of the android WebSettings, especially about the mixed content mode: https://developer.android.com/reference/android/webkit/WebSettings.html#setMixedContentMode(int)

The documentation states that up until KitKat, the WebSettings defaults to MIXED_CONTENT_ALWAYS_ALLOW, but beginning with Lollipop, the default setting is MIXED_CONTENT_NEVER_ALLOW. I am not exactly sure, but I think that custom schemes are blocked with MIXED_CONTENT_NEVER_ALLOW. Both of your mentioned test devices are running Marshmallow, so it should default to MIXED_CONTENT_NEVER_ALLOW.

I think what happened is, the WebView never actually used these settings, and it only started to work as documented with Chromium v55, hence the break of functionality. The solution is fairly simple, at least this worked for us:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    WebSettings webSettings = webView.getSettings();
    webSettings.setMixedContentMode(WebSettings.MIXED_CONTENT_COMPATIBILITY_MODE);
}

While I understand that you don't use in app WebView, but the Chrome app, investigating the mixed content mode might help.

Actually I don't think our app has issue due to WebSettings,
the link in chrome is accessible and user can hit and access the HTTP URL, 
the only issue is that Chrome somehow downloads the content and do not check for apps that are listening to some specific mimetype and does not allow external app activities to be triggered.

I did some tests with different android chrome versions (in emulator):
here are the results:
chrome 53.0.2785.135 - worked ok.
chrome 55.0.2883.91 - does not work
chrome 57.0.2987.19 (known as Chrome Beta) - does not work

so it seems that something definitely was changed in the Chrome 55 version.