Using the per-revision bisect providing the bisect results,
Good build:59.0.3037.0 (Revision:455955).
Bad build:59.0.3038.0 (Revision:456244).

You are probably looking for a change made after 456158 (known good), but no later than 456159 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/0d84b239465f9786e3e79e5b89ac14832b70ca7c..d5fc002027195691680b127e58458d1b2b86d5a1

From the CL above, assigning the issue to the concern owner

@huangs : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2744893002
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #59.0.3040.0

Sorry for the lateness; just saw this.

This is indeed caused by my CL, and was deliberate to emulate regular behavior of <a>: Focus ring do not appear on links with mouse click, including the case where you leave the tab and return to it.  Please see attached index.html file.

Deleted: index.html 185 bytes

index.html 185 bytes View Download

Leaning towards WontFix: Working as Intended.  +dbeam@ to comment.

a focus ring should be shown when a user tabs to an action-link.  the "Actual_video" is NOT working as intended.

I see. I tried Shift-TAB and TAB previously and the focus ring appears. But if you keep on tabbing forward then the ring doesn't appear! Investigating.

This is happening because the "current settings" link happens to be the last tabbable element in DOM. Bug mechanism (see action_link.js):

- Click on link: '.no-outline' gets applied, and ring is hidden.
- Link navigates: 'blur' event is invoked, and the event has e.sourceCapabilities === null, so '.no-outline' is kept, as intended by my fix.
- Return to tab: No change.
- TAB: 'blur' is invoked, but since this is the last tabbable element and focus goes to some stuff outside page, so e.sourceCapabilities === null, and '.no-outline' is kept. If you keep on tabbing forward, '.no-outline' is kept, and we have the bug.
- Meanwhile, if you Shift-TAB, 'blur' is invoked and we land at an element in DOM, so '.no-outline' gets cleared, and on next focus we see border.

In summary, the current approach of using '.no-outline' is non-robust, and my fix neglected edge case of tabbing away from page.

@huangs any update on this? MD Settings is launching in M59 and this is currently a launch-blocker.

My proposed fix https://chromiumcodereview.appspot.com/2768673002/ does not handle some edge cases, and I didn't have time to address them.  The lower risk change is to revert https://codereview.chromium.org/2744893002 but this reopens  bug 698270 , which I filed.  I'm going with the latter.

Reverting CL in flight: http://crrev.com/2796663002/

fix landed, bug wasn't updated