I'm not sure this is a bug, given that the user has explicitly gone to that URL through their browser instead of clicking on that DPWA. 

There are three levels of showing the intent picker:
1. don't show it at all
2. show it but don't pop it open
3. show it and pop it open

Note 2. does not exist in Android and we don't have the pixels to make it available, but it is totally reasonable on desktop.

I think the intent picker should be shown when the URL can be handled by an app. That is it should be either state 2 or 3. It is inconsistent for it to only be available in some cases, and as a user it feels broken and weird that I can get to the same URL in two ways but have different actions available based on how I got there.

Whether we go to state 2 or 3 depends on how likely we think the user will be to want to open the URL in an app. If we think it is likely, we should pop the picker (state 3). This is the case where the navigation was indirect (i.e. clicked a link) and the user has not selected 'remember my choice'.

When the navigation is direct, or the user has said to use chrome and selected 'remember my choice', we should just stay in state 2.

Yes, #3 is definitely correct: it's fine to show or not show the popup based on context, but it doesn't make sense for the Omnibox button to be visible sometimes but not other times.

I agree with #3 and #4 that the intent picker should be available if the current URL could be handled by some app on the system. In general, I want to move to a model where we automatically open the picker a lot less, and show it ambiently a lot more.

I think David is now working on this. Also cc alancutter

I feel mostly OK with showing an icon on the omnibox all the times we have available apps.

The ideas of having more screen space compared to vanilla android and not weirding out the user about the conditions that allow us access apps makes sense to me, the only issue I have is this implies querying ARC (+ all the other app platforms) every time we navigate basically, that was a concern Chrome team brought up when we first started designing intent picker.

For ARC we have a Chrome-side pre-filter that could locally give us an idea of whether or not the icon should be there, deferring the task of actually querying until the user expands the bubble.

I think it would improve the user experience just wanted to put this to consideration o/

How does the pre-filter work? Does that allow us to avoid querying entire origins in the common case?

Chrome-side keeps an updated list of intent filters via ArcIntentHelperBridge, ShouldChromeHandleUrl(const GURL& url)[1] allows us to decide whether or not there is a filter/app on ARC that matches our url.

This pre-filter is a huge simplification but it is used in AppsNavigationThrottle (more specificly via ArcNavigationThrottle[2]) to quickly tell whether or not is likely ARC contains installed candidates to handle a given URL, so yup we rely in this component to later query or not for a full list of apps.

[1] https://cs.chromium.org/chromium/src/components/arc/intent_helper/arc_intent_helper_bridge.h?q=arcintenthelperbri&sq=package:chromium&g=0&l=92

[2] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/arc/intent_helper/arc_navigation_throttle.cc?type=cs&q=ShouldChromeHandleUrl&g=0&l=92