Unable to reproduce the issue on Mac-10.12.2, Windows-7 and Linux Ubuntu-14.04 using Chrome stable version 57.0.2987.98 & canary 59.0.3037.0 and reported version 56.0.2924.87 with the steps mentioned in comment#0.
galambalazs@ Please find the attached screen cast and let us know if anything missed here to reproduce the issue.

Thanks..

Deleted: 700124.mov 3.3 MB

700124.mov 3.3 MB Download

I just loaded the attached extension again on an empty profile and can definitely reproduce on both:

Version 57.0.2987.98 (64-bit)
Version 59.0.3037.0 (Official Build) canary (64-bit)

Mac-10.12.2

(same on windows)

Can this be because of the 64 bit build being different?

Thank you for providing more feedback. Adding requester "sureshkumari@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

I just saw that you used 64 bit in the video too (just not mentioned in the comment).

Here is my screencast.

It has been reported by other users so it's definitely not just on my machine. And I can reproduce 100% of the time.

Deleted: FocusBug.mov 8.8 MB

FocusBug.mov 8.8 MB Download

I can see why you couldn't reproduce!


You opened index.html as a file:///....


This is supposed to be loaded as an Extension (that's why I called it New Tab bug)

chrome://extensions/ & Load Unpacked Extension

Then you will see the focusing bug.

Able to reproduce on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome stable M57-57.0.2987.98.

Bisect Information:
=====================
Good build: 55.0.2841.0
Bad Build : 55.0.2843.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/5d6411a1a10652b1a3d9ced8d744f7e427918805..d8f0aefde00132b06bd97cb17555f2ec89a0c203

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2285883002

nasko@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Yes, this does indeed look like behavior difference with Isolate Extensions. Assigning to alexmos@ for further follow up.

I think the root cause is that during commit of a document, we always call WebContentsImpl::FocusLocationBarByDefault(), which returns true for the new tab page, then focus the omnibox if the result was true. It is not conditional on whether it is a subframe or not, which is why it will always focus the omnibox. 

If my analysis is correct, it might be useful to restrict the focus behavior of the omnibox to only the commit of the main frame, not for subframes.

Nice find.  In theory that could be a bug in the NTP even without extensions or out-of-process iframes, right?  It would be tough to hit in practice, but if the most visited tiles were slow to commit, you could tab around the NTP (shifting keyboard focus) and then have focus jump to the omnibox when the tile iframes commit.

Nevermind about affecting the old NTP-- Nasko points out that the FocusLocationBarByDefault call only happens on cross-process navigations, so it is a new issue with out-of-process iframes on the NTP.

I've confirmed that not calling FocusLocationBarByDefault for subframe commits fixes this.  The fix seems to be easy; I'll now work on a test for this.

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

commit 5e8b5e6aebcb564897e311ae4f4397eed3555457
Author: alexmos <alexmos@chromium.org>
Date: Wed Mar 15 21:52:47 2017

Don't focus the omnibox when a subframe navigates on NTP.

This fixes a bug where an NTP replacement page from an extension was
losing focus to the omnibox when a subframe on that page committed a
navigation.  So if the user was typing into an <input> on the NTP
replacement page while a subframe navigated, the focus was
disruptively shifted to the omnibox in the middle of typing.

This matters only in OOPIF modes, as focusing of the omnibox was done
in RenderFrameHostManager::CommitPending, which is only used for
cross-process commits.

BUG= 700124 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/5e8b5e6aebcb564897e311ae4f4397eed3555457/chrome/browser/extensions/extension_override_apitest.cc
[modify] https://crrev.com/5e8b5e6aebcb564897e311ae4f4397eed3555457/content/browser/frame_host/render_frame_host_manager.cc

Thanks for the fix, Alex!  Do you think this is a safe thing to merge to M58?  (I imagine it's not severe enough to go to M57.)

#14: I think so, as the fix is very short and straightforward.  I'll request a merge if things look good in tomorrow's canary.

Just verified that this is fixed on Win canary 59.0.3044.0, which has my fix from r457222.  Requesting merge to M58 given that the fix is low-risk.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

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

commit ac6993fe1faea8121d6584815eaae580921bcbc7
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Fri Mar 17 18:14:30 2017

Don't focus the omnibox when a subframe navigates on NTP (Merge to M58)

This fixes a bug where an NTP replacement page from an extension was
losing focus to the omnibox when a subframe on that page committed a
navigation.  So if the user was typing into an <input> on the NTP
replacement page while a subframe navigated, the focus was
disruptively shifted to the omnibox in the middle of typing.

This matters only in OOPIF modes, as focusing of the omnibox was done
in RenderFrameHostManager::CommitPending, which is only used for
cross-process commits.

BUG= 700124 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2748103005
Cr-Commit-Position: refs/heads/master@{#457222}
(cherry picked from commit 5e8b5e6aebcb564897e311ae4f4397eed3555457)

Review-Url: https://codereview.chromium.org/2754363002 .
Cr-Commit-Position: refs/branch-heads/3029@{#270}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/ac6993fe1faea8121d6584815eaae580921bcbc7/chrome/browser/extensions/extension_override_apitest.cc
[modify] https://crrev.com/ac6993fe1faea8121d6584815eaae580921bcbc7/content/browser/frame_host/render_frame_host_manager.cc

Verified the fix on Mac 10.12.3, Win-10 and Ubuntu 14.04 using Chrome beta version #58.0.3029.33 as per the comment #0 and #6.

Observed that loading an iframe did not cause the New Tab to lose focus. Hence, the fix is working as expected.

Attaching the screencast for reference

Adding the verified labels.

Thanks...!!

Deleted: 700124.mp4 1006 KB

	700124.mp4 1006 KB View Download

Chrome team rules.
Thanks for the quick turnaround time.

- Blaze