able to reproduce the issue on Mac 10.11.6 using chrome version 55.0.2883.28 

Please find the  per-revision bisect as below

Good :: 55.0.2880.0  -- (build revision 422654)
Bad  :: 55.0.2881.0  --  (build revision 423030)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/cd20702d3b3dd5224beaa7fd7b876313b33b6b70..c9604416470e1bcb85be4adf15dc605efea29ded

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/c9604416470e1bcb85be4adf15dc605efea29ded

dpapad @ Could you please look into this issue if it is related to your change,else please route this to an appropriate dev person.

Thanks,

Haha, that's awesome.

We shouldn't be trying to create .search-highlight-wrapper spans inside <options>. And probably some other elements too, if you can think of any where similar issues could crop up.

Need to update the ignored elements list for searching, see https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/search_settings.js?l=30.

FWIW, this regressed at https://codereview.chromium.org/2360853006, which was fixing another search bug. Also note that the old Options do search within <select> elements, but don't exhibit the problem because there is no need to keep the original node around. 

In MD Settings case (as explained by CL 2360853006), the original node might be part of various data bindings, and therefore it has to be kept around to address corner cases. Unfortunately within an <option>, the original text node is not respecting "dislay: none", so it becomes visible.

After digging in the <option> implementation at [1], the only hidden text inside an <option> can be inside a <script> node, see example [2]. Not sure if that is helpful in our case, seems pretty hacky if we were to exploit that. I think two reasonable approaches are the following

a) Ignore <select> when searching. This is not on-par with old Options.
b) Search within <select> but don't preserve the original text node. I doubt this can create
   a user visible bug, since I could not find any <option> instances in Settings codebase
   where the textContent of the <option> can change dynamically (without triggering a dom-repeat
   restamp).

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLOptionElement.cpp?l=401
[2] https://jsfiddle.net/vtvq6Lhs/

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

commit 9128a695732eba4729713506cf40268e1aada67a
Author: dpapad <dpapad@chromium.org>
Date: Tue Nov 01 21:38:36 2016

MD Settings: Fix <select> search highlighting.

<select> elements should not be highlighted with yellow rectangles
because the highlight CSS style is ignored anyway and breaks the
<select> (duplicate strings displayed). Just including the parent
<settings-section> should be sufficient for now (matches old Options).

Also add the first unit tests for the DOM searching algorithm internals.

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

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

[modify] https://crrev.com/9128a695732eba4729713506cf40268e1aada67a/chrome/browser/resources/settings/search_settings.js
[modify] https://crrev.com/9128a695732eba4729713506cf40268e1aada67a/chrome/test/data/webui/settings/cr_settings_browsertest.js
[add] https://crrev.com/9128a695732eba4729713506cf40268e1aada67a/chrome/test/data/webui/settings/search_settings_test.js