Unable to reproduce the issue on reported chrome version #69.0.3497.100 and latest canary #71.0.3569.0 using Mac OS 10.13.6 by following below steps.

Steps:
=====
1.Launched chrome.
2.Opened a Google document.
3.Clicked on empty space in chrome menu.
4.Pressed "Cmd+F", observed the custom search got opened.
5.Closed it with "ESC" button.
6.Pressed "Cmd+F" again, observed the custom search got opened.

Attached screencast for reference.
@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here. Request you to retry this issue with a fresh profile without any extensions and apps, reset all the flags to default and let us know if the issue still persists.

Thanks.!

Deleted: 891224.mp4 644 KB

	891224.mp4 644 KB View Download

I can perfectly reproduce it using a fresh profile with no extensions, and flags all reset to the default. I guess that Swarnasree Mukkala used some weird version of Chrome. Maybe it was Chrome OS? I see Chrome 69 with a pre-69 UI. What's the platform?

Oh, and if it's hard to find the spot to click, just click on the card itself in the top bar. It's very easy. But first make sure that you don't have whatever switch caused you to go back to the Chrome 68 UI.

I'm attaching a screencast. It was taken on Chrome 69.0.3497.100 (Official Build) (64-bit), on MacOS 10.12.6 (16G1510). As you can see, in our case, it's using the modernized UI, which is most probably responsible for this mess.

Deleted: chromium-focus-bug.mov 873 KB

	chromium-focus-bug.mov 873 KB View Download

I tested this on Mac on Chrome 9.0.3497.81. I don't seem to see the issue. I tried clicking on empty space in bookmark bar or the tab itself and cmd+f still opens the custom search box. Only when I click in the url bar and url is selected is when cmd+f opens the chrome search box which is intended. I'll still wait for someone from QA team as well to see whether they can repro the issue or not.

Let's take Google Docs out of the equation here and try the following: open the console and run:

 monitorEvents(window, 'keydown');

For every Cmd+F click you should see the following sequence:

 keydown KeyboardEvent {isTrusted: true, key: "Meta", code: "MetaLeft", location: 1, ctrlKey: false, …}
 VM45:1 keydown KeyboardEvent {isTrusted: true, key: "f", code: "KeyF", location: 0, ctrlKey: false, …}

However, if you click the tab header, these events don't appear. Only after you dismiss the dialog and repeat the keystrokes, they can be "seen" by the window object.

The way it affects us is that we are developing a Chrome extension, and a part of its logic relies on handling keyboard shortcuts after the extension icon has been clicked on the toolbar. It used to work, but now it doesn't, at least on our Macs.

Another way to reproduce the problem is observe the keyboard shortucts in GMail: the j/k navigation stops working whenever you click on the tab bar or on any extension icon.

But you are losing focus when you click some where outside of the page as it is indicated by focusout event and as a result you are not going to get any further key events. Maybe what you are requesting is when the page is out of focus ctrl+F should bring up Chrome search in the page?

No. What I request is that when a user clicks an extension action icon, the window should not lose focus. It used to work this way; the new Chrome shell (>=69) changed it. I don't really care about clicking the tab bar or anything else, but we came to conclusion that this is basically the same bug.

So yes, indeed, we are losing focus, but this is exactly what this bug is about.

I verified that in Linux, both Chrome and Firefox behaves the way bartosz@ mentioned: clicking on the empty space on the top bar or even switching tabs doesn't cause lost focus in the content.

Minimal repro:
data:text/html,<input onfocus="console.log('f')" onblur="console.log('b')"></input>

bartosz@shopspring.com: could you please check if this produces 'b' in your case?

Yes, it produces "b".

Can someone from testing team bisect this bug:
Basically the claim is that sometime after 69 this bug happened.

1. You need to load https://output.jsbin.com/waxamiz
2. Open dev tools and observe
3. click in the text box and observe the "f" being printed
4. click in an empty space in the tab bar say near url bar (but not inside)

5. Observe "b" being printed in the console.

The claim is that "b" wouldn't be printed before for some version before 69.

Tested the issue on reported chrome version 69.0.3497.100 and on the latest canary 72.0.3617.0 using Mac 10.14.1 with the test steps mentioned in comment#13 

Our Observations:
-----------------
* When clicked on text box "f" is printed in console
* When Clicked on empty space "b" is printed.

The above mentioned behaviour is seen on reported version, latest canary and on 68.0.3440.134(Checked this version as it is mentioned that "b" wouldn't be printed before for some version before 69). 
Apart from the above said versions, we have also tested it on M60(60.0.3112.0) - both 'f & b' are printed respectively. Attaching the screen shot for reference.

@nzolghadr: Please have a look at the screen shot and let us know if anything is missed from our end.

Thanks!

OK, let me rephrase it, since I see many people get confused: CLICK ON THE TAB TITLE. NOT on the empty space inside the web page itself. It's logical that if you clicked on the empty space within the web page, you would see "b", since that's how an input box loses focus by definition. The behavior that changed (and I tested it again with a legacy build of Chrome 68 a minute ago) is when you click the TAB TITLE or the area where the extension action buttons appear (including the extension action buttons themselves). That's what began to steal focus from the web page and gets into the way of our extension's workflow. We don't complain about losing focus to other elements of a webpage.

(To clarify: the original report said about an "empty space" empty space IN BOOKMARK BAR/CHROME MENU.)

vamshi.kommuri@ did you click on the empty space in the tab bar or in the page while testing?

I've confirmed that in M70 on Mac we no longer blur when clicking in the Browser UI area (e.g. tab title bar) whereas we did in M68.

Is this causing an issue though? Both Safari and Firefox behave the same way and it makes sense, at least as a platform convention, that clicking on unfocusable UI elements wouldn't steal focus.

QA team, could we get a bisect to find the exact patch? That would at least help determine if the change was intentional.

Tried checking the issue by clicking on the empty space in bookmark bar. We were able to reproduce the issue on reported chrome version 69.0.3497.100 and on the latest canary 73.0.3636.0 using Mac 10.14.1
Note: Issue isn't seen on Windows 10 and Ubuntu 14.04

Bisect Information:
-------------------
Good Build: 69.0.3497.85
Bad Build:  69.0.3497.87

As this seems to be a branch build break, couldn't perform per-revision/chromium bisect. Hence providing Change log from https://omahaproxy.appspot.com/
https://chromium.googlesource.com/chromium/src/+log/69.0.3497.85..69.0.3497.87?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/8d3f27fbbbaa20f142e32b96d2936782e168e3aa
Review URL: https://chromium-review.googlesource.com/c/chromium/src/+/1152076/

@Sidney San Martín: Please help in assigning it to the right owner if this isn't related to your change.

Thanks!