Bisect Tool Info:

You are probably looking for a change made after 425533 (known good), but no later than 425534 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspectas some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/4dbb42fe4765527a3f0ed359caac5f3dce7b1440..46b5ca1056271d70ed5e264612aafe9fa948a2a4

@dpapad , Please reassign if this is not related to your change 

I am able to reproduce this on CrOS. Will take a look and report back with findings.

My initial investigation leads me to IronControlState behavior, which steals the focus even if the element is disabled, see [1]. Checking for |disabled| at that line fixes half of the bug (no more unnecessary focus ripple). The other half (pressing down arrow keys focus is directly seen on 'Move to top') still happens though.

[1] https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/iron-behaviors/iron-control-state-extracted.js?l=61

if my interpretation of the spec[1] is correct, negative tab index shouldn't participate in the tab order.  imo, <dialog> should not focus() an element with a custom tabindex if it's < 0.

here's a reduced repro: https://jsfiddle.net/7gbbbjcr/

[1] https://html.spec.whatwg.org/multipage/interaction.html#negative-tabindex

note, if my blink CL[1] is interpreted as The Right Way To Do Stuff, it'd only solve part of the battle here (but it might be OK for our uses).

<button tabindex="-1"> will still magically get focus if it comes before <paper-checkbox tabindex="0"> because [reasons].

[1] https://chromiumcodereview.appspot.com/2428333002/

btw, my blink CL was NOT interpreted as "The Right Way"

 Issue 662316  has been merged into this issue.

 Issue 664422  has been merged into this issue.

 Issue 665699  has been merged into this issue.

 Issue 656906  has been merged into this issue.

 Issue 667209  has been merged into this issue.

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

commit 25958da94dac85cfe9cf3ec07d428fa0d75aab8e
Author: dbeam <dbeam@chromium.org>
Date: Sat Mar 18 19:48:52 2017

MD WebUI: fix action menu initial focus to be more like context menus

This is easily possible now because <dialog>#showModal() looks into
shadow DOM.

R=dpapad@chromium.org
BUG= 656924 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/25958da94dac85cfe9cf3ec07d428fa0d75aab8e/chrome/test/data/webui/cr_elements/cr_action_menu_test.js
[modify] https://crrev.com/25958da94dac85cfe9cf3ec07d428fa0d75aab8e/ui/webui/resources/cr_elements/cr_action_menu/cr_action_menu.html

Tested the issue on Chrome Dev# 59.0.3047.0 on Windows and found the issue to be Fixed.
No focus is displayed on the options present under iron icon of language.
Attaching screencast for reference (only windows).

Note: Also checked on Latest CrOS Dev# 59.0.3041.0/9386.0.0 dev channel Minnie and is still reproducible.

@dbeam -- Could you please confirm the Fix on Chrome OS, so that verified labels would be added from TE side.
Thanks in Advance.

Deleted: 656924.png 97.3 KB

	656924.png 97.3 KB View Download

Verified on ChromeOS 59.0.3054.0/9409.0.0