My personal opinion is that the "switch to this tab" button should *not* be present if the only available matching tab is in a PWA window. It kind of breaks the native feel of those windows, and it would likely be complex to allow focusing a PWA window in response to the switch to tab.

The fix looks straightforward: ChromeAutocompleteProviderClient::IsTabOpenWithURL()[1] needs to ignore any browser where browser->is_app() returns true. Otherwise it will search through app windows and claim they can be switched to.

+cc kbr: WDYT?

[1] https://cs.chromium.org/chromium/src/chrome/browser/autocomplete/chrome_autocomplete_provider_client.cc?type=cs&sq=package:chromium&g=0&l=396

I guess I'm either having trouble duplicating this, or don't see the issue. When I type "mail" (what I have to type to get the suggestion), I get a suggestion for the Gmail URL and a tab switch button. When I click on it, it switches to that window. This is on 73.0.3642.0.

Just so I'm on the same page: The key issue here is that when you click the button, nothing happens, right? That's pretty weird since we use the same logic to find the tab before and after. The only way I've been able to duplicate that is to close the other window or tab /after/ generating suggestions. (There was a recent bug, but we now open a new copy in this case.)

When mine switched windows, it looked exactly as we intended. If you had a window buried where the target tab was, we'd want to surface it. (Otherwise you might open a duplicate one.) This is exactly what tab switching was supposed to solve. Also, I'm would think, especially for PWAs, that you'd want only one copy. So I don't currently agree that we should disable it.

I can keep trying but if you have any suggestions for how to duplicate, I believe that I can simply fix the original issue, rather than cripple it unnecessarily.

Strange, this does appear to be working properly now. I'm not sure why this wasn't working for me yesterday - I will keep an eye out to see if it starts happening again. Thanks!