This is a regression issue broken in 'M-52' and below is the manual regression and Narrow bisect info:
Good build : 52.0.2723.0
Bad build : 52.0.2724.0

Narrow bisect info:
https://chromium.googlesource.com/chromium/src/+log/56e75ae988eae1ac44cd1eb7082addd4208707cf..e3062350ed9cb39c0ac9a0a08e49c516f002bdc2?pretty=fuller&n=50

Suspecting : r391356 from Narrow bisect

@pfeldman : Could you please help to reassign if your change is not the cause for this change.

Deleted: Actual_video.mp4 722 KB

Actual_video.mp4 722 KB Download

Deleted: Expected_video.mp4 554 KB

Expected_video.mp4 554 KB Download

Deleted: Actual_screenshot.png 214 KB

	Actual_screenshot.png 214 KB View Download

Deleted: Expected_screenshot.png 195 KB

	Expected_screenshot.png 195 KB View Download

Marking the above issue as RB-Stable as this is a recent regression.

Thank you!

This looks related to my search field changes.  I'll self-assign and look into it.

Unable to reproduce on 52.0.2724.0 for Mac or Linux.

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

commit afe5fb69c6324250594694f76e87b2de824e49e2
Author: luoe <luoe@chromium.org>
Date: Tue May 10 00:30:36 2016

DevTools: blur previous element when focus changes

BUG= 609013 

Review-Url: https://codereview.chromium.org/1950343003
Cr-Commit-Position: refs/heads/master@{#392489}

[modify] https://crrev.com/afe5fb69c6324250594694f76e87b2de824e49e2/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js

Changes committed.  For now, the intended behavior is to blur the search field after resize, so that no element has focus.

CL was reverted because changes introduced a new bug https://bugs.chromium.org/p/chromium/issues/detail?id=611803

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

commit 09713de62a12f9245c2e54f5fab88eadb1c63dfd
Author: luoe <luoe@chromium.org>
Date: Sun May 15 19:28:59 2016

Revert of DevTools: blur previous element when focus changes (patchset #2 id:20001 of https://codereview.chromium.org/1950343003/ )

Reason for revert:
This patchset breaks the ability to hide the color picker popover in some cases.  See https://bugs.chromium.org/p/chromium/issues/detail?id=611803

Reverting will break the original bug, affecting focus in the full text search drawer.

Original issue's description:
> DevTools: blur previous element when focus changes
>
> BUG= 609013 
>
> Committed: https://crrev.com/afe5fb69c6324250594694f76e87b2de824e49e2
> Cr-Commit-Position: refs/heads/master@{#392489}

TBR=lushnikov@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 609013 

Review-Url: https://codereview.chromium.org/1976283002
Cr-Commit-Position: refs/heads/master@{#393775}

[modify] https://crrev.com/09713de62a12f9245c2e54f5fab88eadb1c63dfd/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js

This focus issue no longer occurs after the revert of 607431

Both are related issues that will be fixed when 607431 is fixed.

Sorry, I made a mistake in marking this as a duplicate, when this ticket is not the same as 607431.  Both had similar names!

The intended behavior, as stated originally, is for cursor focus to remain in the search field after resize.

Issue is still reproducible on the latest M-52(52.0.2743.0) on Linux Ubuntu 14.04.

luoe@: Could you please take a look at this issue.

Yup, CL in review
https://codereview.chromium.org/2002803002/

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

commit 8a6c91ecf6b62e973e5b9cd4fb6e41735f1e9b1f
Author: luoe <luoe@chromium.org>
Date: Mon May 23 23:08:03 2016

DevTools: allow focus to be restored to the drawer after resize

BUG= 609013 

Review-Url: https://codereview.chromium.org/2002803002
Cr-Commit-Position: refs/heads/master@{#395449}

[modify] https://crrev.com/8a6c91ecf6b62e973e5b9cd4fb6e41735f1e9b1f/third_party/WebKit/Source/devtools/front_end/sources/AdvancedSearchView.js
[modify] https://crrev.com/8a6c91ecf6b62e973e5b9cd4fb6e41735f1e9b1f/third_party/WebKit/Source/devtools/front_end/ui/Drawer.js
[modify] https://crrev.com/8a6c91ecf6b62e973e5b9cd4fb6e41735f1e9b1f/third_party/WebKit/Source/devtools/front_end/ui/InspectorView.js

The above issue is still reproducible on latest canary chrome version : 53.0.2747.0.Please refer the attached video for your reference.

Deleted: Actual_video_canary_53.0.2747.0.mp4 1.0 MB

Actual_video_canary_53.0.2747.0.mp4 1.0 MB Download

You are correct, mnikam.  I didn't realize that this issue still occurs when Device Mode is open as well as the currently open DevTools panel is one without default focus (e.g. Element, Network).  The CL in #12 only fixed certain cases when Device Mode was not open.

The issue when Device Mode is open is actually not a regression.  This behavior is also reproducible on Linux 50.0.2661.102.

I will continue working out solution.

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

commit d436b82c55a2d1d5ad217b59afd2744e1aa6fa77
Author: luoe <luoe@chromium.org>
Date: Tue May 31 22:35:11 2016

DevTools: rework focus logic

Summary of changes:
- We actually have 3 places where GlassPanes are instantiated [Dialogs, Options
in Toolbar, DraggingElements (e.g. Colorpicker)]
- DefaultFocusedViewStack is not necessary and is removed.  Previously, it was
only used by Dialogs anyways.  Dialogs are the only GlassPanes that will save
the previously focused element and call .focus() when the dialog closes
- Showing a different tab (switching to a drawer panel) will now focus on the
new tab, if no previous focus was set
- DeviceMode's toolbar previously depended on .setSelectionRange() to keep focus
in its size input field while resizing.  Now, dragging the splitter won't steal
focus at all, so DeviceMode doesn't need to force focus on itself
- When using the Command Menu to open a panel/file, it will close the GlassPane
first (which may call .focus() on the previous element) before calling .show()
on the new panel/file, so that the new panel/file gets the final focus

BUG= 604427 ,  609013 ,  612397 

Review-Url: https://codereview.chromium.org/2016963002
Cr-Commit-Position: refs/heads/master@{#396955}

[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui/Dialog.js
[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui/Drawer.js
[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui/InspectorView.js
[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui/ShortcutRegistry.js
[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js
[modify] https://crrev.com/d436b82c55a2d1d5ad217b59afd2744e1aa6fa77/third_party/WebKit/Source/devtools/front_end/ui_lazy/FilteredListWidget.js

The latest change should fix the issue.  Please verify if needed.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-52; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-52 label, otherwise remove Merge-TBD label. Thanks.

[Bulk edit]

Our blockerbot script was offline; it was recently brought back online, and thus labeled many old issues (including this one) erroneously.  Removing Merge-TBD label since all milestones for this issue are already completed; no further work should be done.