Bisect Information:
---------------------
You are probably looking for a change made after 464697 (known good), but no later than 464698 (first known bad).

Change Log URL:
------------------
 https://chromium.googlesource.com/chromium/src/+log/188c1056bbfb9c98eca691c12f5641d4204f6066..0f65d25a4097959d977dbb1077717323438240a6

From the above change log suspecting below change
Review-Url:https://codereview.chromium.org/2616623002+

@hugoh: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.

Thanks in Advance.!

When I pick a language using Space bar -> no scroll to top.
When I pick a language using Enter key -> scroll to top.

dpapad@, can it be that this <form> gets "submitted" on Enter and that resets focus to top?

I'm assigning this over to you @dpapad because I hope this can be solved within md-settings.

@hugoh: There is no <form> involved in this code. It is just a series of checkboxes, see https://codereview.chromium.org/2616623002.

At first glance it does not seem that it is fixable within MD Settings. @hugoh, can you take a look? I read the CL description, but could not see the connection with the bug that is reported here. Do you have any insight?

I don't see the connection either :/ I don't understand md-settings' WebComponents so it is hard for me to boil this down to a minimal test case. Do they listen for 'selectionchange'? If not, this might be something related to painting. I will take a look.

If I re-introduce ClearSelectionIfNeeded() in FocusController.cpp I don't see the bug. That means md-settings assumes that selection is coupled with focus. After my CL, the frame's selection can reside in an element that doesn't have focus and this selection can be invisible. 

Here no text was selected, so FrameSelection represents the caret placed at the <settings-subpage-search>'s <paper-input-container>'s <input type="search">. Why does md-settings scroll back up to this selection on Enter? 

Strangely, I did not receive any email for your comment#6 and 7. I'll attempt to rule out a Polymer component misbehaving, or <settings-subpage-search> stealing focus and therefore forcing a scroll. Will post updates once I have any.

 crbug.com/712986  is very similar, it's also shows a random "scroll jump" in md-settings after my CL. I wish we'd have smaller test cases for these bugs.

Minimal repro at https://jsfiddle.net/yfqdxo0b/2/. It only happens with paper-checkbox, but not with native checkbox element.

Notice that the native checkbox does not change state on "Enter", whereas the paper-checkbox does. I am suspecting that some of the many behaviors inherited by paper-checkbox might be the culprit?

Polymer.PaperCheckedElementBehavior
 - Polymer.PaperInkyFocusBehavior
   - Polymer.IronButtonState,
   - Polymer.IronControlState,
   - Polymer.PaperRippleBehavior,
   - Polymer.PaperInkyFocusBehaviorImpl
 - Polymer.IronCheckedElementBehavior,
   - Polymer.IronFormElementBehavior,
   - Polymer.IronValidatableBehavior,
   - Polymer.IronCheckedElementBehaviorImpl
 - Polymer.PaperCheckedElementBehaviorImpl

@dbeam: Maybe we should  consider rolling our own checkbox that does not inherit from so many behaviors. Current paper-checkbox seems that it has a lot of unnecessary code attached to it.

dbeam, will your new checkbox fix this issue?

@hugoh: I spotted one more regression happening because of the same original CL (see comment#1).

Repro steps:
1) Navigate to chrome://md-settings/searchEngines?search=search+engines
2) Wait for the spinner to finish.
3) Tab to the 1st element on the list.
4) press down arrow until reaching the end of the list (or some intermediate element)
5) press up arrow, 2-3 times.

Expected: Focus travels up.
Actual: Focus is lost!

It seems that the original change is breaking iron-list in some way we have not been able to explain yet.

Deleted: unexpected_loss_of_focus.mp4 56.3 KB

	unexpected_loss_of_focus.mp4 56.3 KB View Download

dpapad@, since this bug involves random scrolling, this bug and  https://crbug.com/714535 , feel very related to  https://crbug.com/712986 . 

dpapad@, I cannot explain the lost focus either.

 Issue 715000  has been merged into this issue.

@hugoh: Are you investigating the problem?

Should we revert r464698? There are at least 3 bugs caused by that revision, and no candidate fix has been proposed yet.

dpapad@, the problem you describe in #12 is a duplicate of  http://crbug.com/715038  (focus is not lost, but moved to the <input>-field).

I work at very low speed as I am allocated full time to internal projects. I let yosin@ decide if we should revert. 

I'm not reproducing this on 60.0.3112.66. Marking as Fixed to ease book keeping. 

dpapad@, tell me if you have any other information.