Tested the issue on Mac OS 10.12.5 retina using chrome latest stable M60 #60.0.3112.90 and issue is not reproduced with steps mentioned in comment 30.

Attached screencast for reference.

@ rachel-- Could you please check in latest chrome stable in fresh chrome profile without any extensions and flags enabled and update us with your observations.
And also confirm us if we have missed any steps in reproducing the issue.

Thanks!

Deleted: 750489.mp4 1.5 MB

	750489.mp4 1.5 MB View Download

No, you didn't actually repeat the steps correctly. I'll go into detail about that in a moment FWIW but it probably doesn't matter as I can't reproduce the problem now either, on #60.0.3112.90 even with the same profile & extensions as I used when I originally reported it, but also with a new blank profile. (note the original report was using #60.0.3112.78 - is it rational to expect something like that to change on such a minor version bump that I didn't even notice it being installed?)

It's possible this problem has come and gone over time in the past too. It's the sort of thing one only tends to notice when it breaks. So now I think of it it wasn't happening all this morning while I was catching up on Twitter and I didn't notice until just now trying to specifically test for it.

Anyway, FWIW, your steps to reproduce in the screencast were wrong as follows:

1. You inserted a step between my steps 4 and 5: You presumably clicked on the dock icon (not shown) to open a fresh window. Then closed that from the tab's close button, then tried to open the html file. I already reported that opening a fresh window by clicking on the dock or splat-N was working fine, the problem was only when the last time the window was closed it had a tab with an actual loaded web page ("New Tab" doesn't count); I think what you did was clear the *previous* preserved state of the last closed window, that would have shown the problem.

2. My step 5 was to invoke a *URL* from an external application. I never tested opening a HTML file on the filesystem, so I don't know if that ever exhibited the problem. My test was to click on a URL to a website that was presented as a link in another application. It happened that that application in my case was Tweetbot but I doubted that was relevant. What might have been relevant is the potential difference between the implied "open -a 'Google Chrome' <filename-note-not-file:url>" that I think would be equivalent to your opening the file from the Finder and "open <http:url>", equivalent to opening a HTTP/HTTPS URL from another application - where Chrome is the default browser.

My guess is that point 2 above was *probably* sufficiently equivalent to have been a valid test, but point 1 definitely would have invalidated the test and presented a false-negative. I suppose seeing as the original bug has gone into hiding anyway we'll never know! :-} We love Heisenbugs don't we...

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks for your update.

As per comment #3, Seems to be issue is not reproducible on latest stable M60 #60.0.3112.90.

@rachel-- Could you please confirm us if we can close this issue.

Thanks!

Confirmed.

(Bet it comes back though! ;-))

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

As per comment #6, closing this issue . Please feel free to raise a new issue , if any issues faced in latest chrome channels.

Thanks!