mariakhomenko@ may be a better person to answer this, but we want to bypass intent pickers as much as possible for better user experience. Having specialized handlers (i.e. apps with host filters) means that the app is handling the URL in a more dedicated way, so we try to distinguish such apps from generalized apps (e.g. browser). I believe that this is an undocumented rule of thumb for us. Do you have any concern regarding the difference in behaviors?

My concern is that I want to use the autoverify flag for Android M to avoid asking the user which app to open. With this inconsistent behavior, sometimes the app is automatically launched and sometimes it just continues browsing.

<intent-filter android:autoVerify="true">

With the autoverify flag, native browser would always open my app (if the app handles it).
Without the autoverify flag, native browser would always ask the user which app to open (if the app handles it).
As you can see, in both cases, native browser is consistent.

Thanks.

I think the current behaviour is more sensible from the user perspective.

The key here is that as a user I either want to use your app or I want to use the browser. I don't think it matters how I arrived at a particular link.

So in step 3, the user specifically said that they wanted to use the browser rather than the application. This is why in step 4, we don't show the choice again. After all the user just picked a moment ago to use the browser -- it would not be a great experience to show the dialog to the user repeatedly.

Number 7 behaves differently because the user hasn't been presented the choice dialog previously -- they did not have an opportunity to choose the app. Hence this is the first point at which the dialog is presented.

IMO, even though this is not consistent with some other browser implementations, this makes sense in terms of the end user experience.

Thanks for your comments, however, I insist, if you use deeplink with Android M's Digital Asset Link (intent filter with the autoVerify attribute) to avoid intent picker, then you will definetely see this is inconsistent. 

With this feature enabled, on step 3 it will automatically open the app, on step 7 it will also automatically open the app. 
However if you manually write the address www.mycompany.com (which is handled) it will not automatically open the app, it will open the webpage, what is more, if you click on a handled link there it will not automatically open the app either.
If you manually write the address of an url not handled and then click on a handled link it will automatically open the app.

My suggestion is the following: 
If the user writes the address of a handled or unhandled link, then open it in the browser, then if the user clicks any link in the webpage of a handled or unhandled link, then continue in the browser.

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

commit 439f0a8bc8a1a597e8cf5fbe2595760017cd366f
Author: mariakhomenko <mariakhomenko@chromium.org>
Date: Tue Jun 14 01:48:13 2016

Adds support for attaching a market referrer.

Given an intent:// URL, if the application cannot be found and we
redirect the user to Play Market, set the referrer string in the market
URL to the value of market_referrer extra specified in the original
intent.

BUG=603999

Review-Url: https://codereview.chromium.org/2061493002
Cr-Commit-Position: refs/heads/master@{#399637}

[modify] https://crrev.com/439f0a8bc8a1a597e8cf5fbe2595760017cd366f/chrome/android/java/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandler.java
[modify] https://crrev.com/439f0a8bc8a1a597e8cf5fbe2595760017cd366f/chrome/android/javatests/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandlerTest.java

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

commit 439f0a8bc8a1a597e8cf5fbe2595760017cd366f
Author: mariakhomenko <mariakhomenko@chromium.org>
Date: Tue Jun 14 01:48:13 2016

Adds support for attaching a market referrer.

Given an intent:// URL, if the application cannot be found and we
redirect the user to Play Market, set the referrer string in the market
URL to the value of market_referrer extra specified in the original
intent.

BUG=603999

Review-Url: https://codereview.chromium.org/2061493002
Cr-Commit-Position: refs/heads/master@{#399637}

[modify] https://crrev.com/439f0a8bc8a1a597e8cf5fbe2595760017cd366f/chrome/android/java/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandler.java
[modify] https://crrev.com/439f0a8bc8a1a597e8cf5fbe2595760017cd366f/chrome/android/javatests/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandlerTest.java

Sorry, but this change isn't fixing this issue. I accidentally attached the wrong bug number to it.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot