frolovkirill7@ Thanks for the issue.

Tested the issue on Windows 10 on the reported version 66.0.3359.139 and the latest Canary 68.0.3417.2 by following the below steps.

1. Launched Chrome and opened many tabs.
2. Tried closing a tab by clicking on the x button, which is not on the foreground and can observe that the tab is closed without coming to the foreground.
3. Closed a tab by ending the process in the task manager and the tab is closed without coming to the foreground.
Attached is the screen cast for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Thanks..

Deleted: 838855.mp4 1.5 MB

	838855.mp4 1.5 MB View Download

1.Launched Chrome and opened many tabs.
2.I tried to kill active tab process.
3.The browser window unminimized

Thank you for providing more feedback. Adding the requester to the cc list.

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

frolovkirill7@ Thanks for the update.

Tested this issue on Windows 10 on latest Stable 66.0.3359.139 as per comment #4.

1. Launched Chrome and opened many tabs.
2. Tried killing a active tab by ending a process in Task Manager, Aw Snap is displayed on the page.
The same behavior is observed on M65 builds.
Attached is the screen cast for reference.

Request you to provide the exact details of the issue you are seeing, which will help us in further triaging.
Also provide a screen cast of the steps followed to reproduce the issue.

Thanks..

Deleted: 838855-M66.mp4 1.8 MB

	838855-M66.mp4 1.8 MB View Download

Screencast attached to comment 1.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce this issue on Windows 10 and Ubuntu 14.04 on the latest Canary 68.0.3424.0 and latest Stable 66.0.3359.139 as per the original comment.
Issue is not observed on Mac OS 10.12.6
Attached are the screen casts of Good and Bad behaviors.

Bisect Information:
===================
Good Build: 66.0.3344.0 (Revision - 535592)
Bad Build : 66.0.3345.0 (Revision - 536026)

Unable to execute the per-revision bisect script as all builds are crashing. Hence below is the Changelog URL by executing the Chromium bisect:

https://chromium.googlesource.com/chromium/src/+log/cf3e96da896ecf7715f85d5c71283f4ab53db112..a60e495ea2084539e350f51125843dc207868d58

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/910716

dmazzoni@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove the same if this is not applicable.

Thanks

Deleted: 838855-good.mp4 690 KB

	838855-good.mp4 690 KB View Download

Deleted: 838855-bad.mp4 448 KB

	838855-bad.mp4 448 KB View Download

Punting this to M67.

To clarify, is the behavior change that the window with the sad tab comes to the foreground?

This is a side effect of an intentional change. The goal was to put keyboard focus into the sad tab when it appears, so that users with a screen reader or who prefer keyboard navigation have a good experience.

I think we should maybe tweak it so that we only put focus there if the window was already active. In the case where the Task Manager was active and the window containing the tab was behind it, we should do nothing.

I'll accept this and will fix it, but I don't think this needs to be a release blocker.

Removing some labels. Not a release blocker but will target M68 with a fix.

Fix out for review: https://chromium-review.googlesource.com/c/chromium/src/+/1073494

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

commit 0778cbc504f75db4521f284c784340888c2469b5
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Tue May 29 16:24:53 2018

Only focus the sad tab view if its widget is already active.

In crrev.com/c/910716, I made it so that a button on the sad tab view
takes focus when the sad tab appears, which improves accessibility.
This had the side effect of activating the window if it was previously
in the background. Fix this by only focusing the view in the sad tab
if its widget is already active.

Bug:  838855 
Change-Id: Ia70279fd010a03c5185e6c4b9f1c85168fce899a
Reviewed-on: https://chromium-review.googlesource.com/1073494
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562455}
[modify] https://crrev.com/0778cbc504f75db4521f284c784340888c2469b5/chrome/browser/ui/views/sad_tab_view.cc

Able to reproduce this issue on Windows 10 and Ubuntu 14.04 on the reported version 66.0.3359.139 and the issue is fixed on the latest Canary 69.0.3445.0 as per comment #9.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 838855-M69-CL.mp4 1013 KB

	838855-M69-CL.mp4 1013 KB View Download

 Issue 851280  has been merged into this issue.