Tested the issue in Android and could reproduce the issue. Observed the browser closes and navigating back to home screen.

Steps Followed:
1. Launched Chrome .
2. Navigated to https://news.ycombinator.com/item?id=16073022
3. Clicked on the docs.google.com there
4. Observed the browser closes and navigating back to home screen.

Chrome versions tested:
63.0.3239.111, 65.0.3317.0

OS
Android 7.0.0

Android Devices
Samsung J7

Considering this issue as Non-Regression issue as observing same behavior since M58.

Please navigate to below link for and video & log's --
go/chrome-androidlogs/800944

Thanks!!

@mariakhomenko -- looks like something wonky going on with external navigation delegate and the play store?

@tedchoc, the play store is red herring in that video. The browser just goes to whatever's in the back stack.

I don't generally think this is a bug. It's a feature request. The docs URL from ycombinator is opened in a new tab. Our back press logic first tries to move back in-tab navigation (there's none since it's a new tab) and then it just does the Android app "back" which brings us back to home screen.

I think we already keep track of parent tab ids, so we could in theory close the tab and bring the launcher tab to foreground, but it's not something that's been implemented.

The last bit is what we normally do.  If you long press "open in background" a tab, switch to that tab and hit back, you're brought back to the parent tab.

The same happens if you go to a site (news.google.com in desktop mode) that opens links in new tabs.  Click on a link, you're switched to a new tab, back brings you back to the parent tab.

To me, something is broken in this chain to sever the parent tab relationship.

Yup, the back button works differently (tab closes, you stay in Chrome) if you click on any other link on that page (e.g. on the username).

Ah, I missed the launch type check code in handleBackPressed. I'll take a closer look.

Ok, so here's what's happening.

The URL on the page is a docs URL, so it gets dispatched to docs app, assuming it's installed. The doc app for whatever reason decides to display the URL in the browser and in turn sends a VIEW intent with the same URL to Chrome. Since that's just an incoming intent into Chrome there is no link between the originating tab and the new opened tab. Hitting back takes us to homescreen since docs is finished.

This scenario actually looks better with Herb enabled because then Docs opens an herb and hitting back will move back in the stack to Chrome.

There's nothing to do here because we cannot control what happens to a URL we send to docs and it should generally be something we hit rarely.

I agree this is a won't fix.  I think we could likely special case this by retaining the parent tab ID if we don't get an onStop call (since we'd be remaining visible to the user and likely associated with the original tab), but I feel that is more code for a use case that is so bespoke that is likely to cause more code confusion that it is worth.