Bisect Info:
===========
Good build : 55.0.2875.0,  Revision Range - 421703
Bad build  : 55.0.2876.0,  Revision Range - 421986

After executing the per-revision bisect script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/e0c4f182dcdd69446fb4a01b08c0d35fd05d30de..b5c369c4b3fe3b1b9a3f710c39ae7ea67b56eb5d

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/b5c369c4b3fe3b1b9a3f710c39ae7ea67b56eb5d

Review-Url: https://codereview.chromium.org/2378253003

dpapad@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

I am able to reproduce this, investigating...

This seems to be a native <select> bug, where it stops respecting the "selected" attribute, for the some of the <option>s.

Deleted: select_broken.png 65.7 KB

	select_broken.png 65.7 KB View Download

Deleted: selected_attribute_not_working.mp4 1.3 MB

	selected_attribute_not_working.mp4 1.3 MB View Download

+tkent

It seems that blink somehow thinks that the <option> tag is not "dirty" and ignores the change, see https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLOptionElement.cpp?l=211.

I don't understand how changing the "selected" attribute would not cause the m_isDirtry boolean to true. Also this seems related to https://bugs.chromium.org/p/chromium/issues/detail?id=570367.

I have found simplified repro steps (also see new screencast).

1) Navigate to chrome://md-settings/search.
2) Change the default search engine from Google to Bing, and back to Google.
3) Enter "manage search engines" subpage.
4) Change the default search engine back to Bing from the 3-dot menu.
5) Exit the subpage and observe the incorrect selected value.

I believe this is related to the way the "selected" attribute behaves, and specifically about the order the items are updated by Polymer's dom-repeat. See https://jsfiddle.net/bmmcotjv/4/ for a simplified case.

It seems that if two [selected] <option>s exist at the same time, the element enters a weird state, and stops updating (which also happens on Firefox, so perhaps this is the speced behavior).

Deleted: selected_attribute_not_working.mp4 1.1 MB

	selected_attribute_not_working.mp4 1.1 MB View Download

> See https://jsfiddle.net/bmmcotjv/4/ for a simplified case.

As for the latter case in the fiddle,  it's an expected behavior.
https://html.spec.whatwg.org/multipage/forms.html#dom-option-selected
|option[index].selected = true| makes the option selected, but the following 'ask for a reset' operation clears option selection except the first selected option.

@tkent: If I am reading the spec correctly

"On setting, it must set the element's selectedness to the new value, set its dirtiness to true, and then cause the element to ask for a reset."

The "ask for a reset" should happen not only when a |selected| attribute is set to true, but also when it is set to false, which leads me to believe that the behavior observed in the 2nd case at https://jsfiddle.net/bmmcotjv/4/ is still incorrect.

So, my original jsfiddle minimal case, had a bug in the code, updated at https://jsfiddle.net/bmmcotjv/6/. Which basically means that
 - I still have not found a minimal case demonstrating the problem 
 - But I can reliably reproduce the problem within MD Settings.

A potential fix is at https://codereview.chromium.org/2736803002 (verified it fixes the issue), but I would like to understand the exact problem so that I can determine if a similar fix is needed in other places in the MD Settings code, so I will keep looking for a minimal repro.

New minimal repro case at https://jsfiddle.net/0urtfmsm/3/. This is not as minimal as before, since it is using Polymer's dom-repeat.

@tkent: Can you please take a look at the new minimal repro case and verify whether this is expected or a bug in <select>?

> New minimal repro case at https://jsfiddle.net/0urtfmsm/3/.

Though I don't understand how Polymer works exactly, the fiddle looks to update |selected| HTML attribute, not |selected| IDL attribute.  They are not same.  Updating |selected| HTML attribute is ignored if dirty. Updating |selected| IDL attribute isn't ignored even if dirty.

I think <select> works as expected.

> the fiddle looks to update |selected| HTML attribute

Correct. You can change "selected$=" to "selected=", to update the IDL attribute instead. Just tried this and it seems to address the problem. Thanks for the explanation.

The fact that the HTML attribute and the IDL attribute are different seems very subtle, from a developer's perspective. I would expect those two to always be kept in sync by the underlying element.

Is there a section in the spec I can point, to explain the difference (I am going to have to add a comment in the code to explain this subtlety)?

> Is there a section in the spec I can point

|selected| HTML attribute is explained by three paragraphs since https://html.spec.whatwg.org/multipage/forms.html#attr-option-selected .  The corresponding IDL attribute is |defaultSelected|, not |selected|.

As you know, |selected| IDL attribute is https://html.spec.whatwg.org/multipage/forms.html#dom-option-selected

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

commit 906adfec35ab217d2be4f851cbefb85400d43eab
Author: dpapad <dpapad@chromium.org>
Date: Tue Mar 07 21:07:18 2017

MD Settings: Stop using <option>'s |selected| HTML attribute in bindings.

The selected HTML attribute can be ignored if the <option> is in a "dirty"
state. Use the IDL |selected| attribute instead which is always respected.
https://html.spec.whatwg.org/multipage/forms.html#attr-option-selected

This fixes a corner case where the search engines <select> is showing the
wrong <option> as selected.

BUG= 698189 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/906adfec35ab217d2be4f851cbefb85400d43eab/chrome/browser/resources/settings/appearance_page/appearance_page.html
[modify] https://crrev.com/906adfec35ab217d2be4f851cbefb85400d43eab/chrome/browser/resources/settings/device_page/power.html
[modify] https://crrev.com/906adfec35ab217d2be4f851cbefb85400d43eab/chrome/browser/resources/settings/device_page/stylus.html
[modify] https://crrev.com/906adfec35ab217d2be4f851cbefb85400d43eab/chrome/browser/resources/settings/search_page/search_page.html