Good Build: 53.0.2746.0
Bad Build: 53.0.2748.0

Narrow Bisect: 
https://chromium.googlesource.com/chromium/src/+log/edf4c2a2a9a387ac62c66391e63e93c70658cbc3..4542ad283b4659bdee20b139997fe98b7ef06d22?pretty=fuller&n=100

Suspecting: r395586

@yutak: Please help me to reassign this issue, if your change is not cause for it.

1. I can't see what is wrong with the actual result. There isn't a cursor at all
   in both screencasts, is there?

2. I believe the bisect result is incorrect. Mine has nothing to do with this,
   and all others aren't relevant, either. Please retry bisection.

With respect to comment 2:

Rebisected for the above issue and below is bisect info:

Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/61c5a5d0d32c6b995426f802a560889242968665..a6291c3ea84f371d10c0d10e66ee6d11458c9d42?pretty=fuller&n=100

Suspecting: r395325

@rob.buis: Please help me to reassign this issue, if your change is not cause for it.

My change is not changing any code, only layout tests.

With respect to comment 5:

Re-bisected for the above issue, and getting same bisect range as mentioned in comment 4:

Suspecting: r395324

@rob: Please help me to reassign this issue, if your change is not cause for it.

My change only added assertions to unrelated code, try again.

FWIW, I followed the steps from the video in 55.0.2877.0 on Linux and did not observe the blue outline.

For testing, I downloaded the source of 
https://chrome.google.com/webstore/detail/browser-sample/edggnmnajhcbhlnpjnogkjpghaikidaa
(also available at https://github.com/GoogleChrome/chrome-app-samples/tree/master/samples/webview-samples/browser).

The assigned owner "rkote@etouch.net" is not able to receive e-mails, please re-triage.

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

Assigning to James for triage.

So I just tried this using ToT Chromium on Mac (58.0.2992.0 (64-bit)) and here are my observations:

0) Since this bug was filed, a lot of webview-focus related changes have occurred, and the original intent of this bug may no longer exist.

1) The repro instructions no longer apply - in particular, right clicking in the app's URL bar does not open a context menu with a "reload app" option.

2) Loading/reloading google.ca in the regular browser moves focus to the text input box, while  loading/reloading the same site in Browser Sample does not.

It seems to me that the two should act the same, but I could be wrong.

avallee@ - Could you please triage this further and determine:

1) What is the current behaviour on Windows?

2) Is it reasonable to expect the same focus behaviour in the app as in the main browser window when loading google.ca?

wjmaclean@: I just checked canary on Windows.

Observations:
1. The reload app option only shows for extensions that were loaded as unpacked in dev mode. Web store extension don't get the reload app option (makes sense that the dev options are only on the dev extensions).

2. The browser behaviour is what I'd expect from the browser sample. I've got a patch for browser sample which focused the webview on load (loads google home page) and on navigation from the url bar.

3. The current behaviour without cross process frames is that the content starts off not focused, there's no caret on the search page, the search box does not have the larger "active" shadow.

4. The current behaviour with cross process frames is that the content always gets focused, there is a caret and the shadow is slightly larger indicating that the box is active.

Fixed browser sample to always have the web content focused on start and after navigation.

https://github.com/GoogleChrome/chrome-app-samples/pull/468

No changes required to Chromium.