This happens because of the presence of the no-search attribute at https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/people_page/people_page.html?l=245.

@stevenjb: Do you know if no-search has been added intentionally for "screen lock" subpage?

I suspect it may have just been copy/pasted?

sammiequon@ - Please either fix this or chat with Tom if this was done intentionally.

I vaguely remember now that there was a problem because that particular subpage pops up a dialog when it is rendered. This was causing problems with the background forced-rendering that happens during searching.

I'll look for a previous CL or bug with more context.

Ah, that makes sense. The subpage shows a dialog that requests authentication to access.

Not sure what the best approach is here; can we add keywords to a section?

Not supported. Only text that appears in the DOM is being searched. Perhaps if we could differentiate between forced-rendering vs user navigating to the subpage, we could prevent the dialog from being opened. Sounds like we could do this within currentRouteChanged.

That would be OK so long as we don't allow actually navigating to the subpage for real, i.e. if we can make a change that allows us to search the subpage but not show it, that would be fine.

Looking at the code seems that a previous CL (https://codereview.chromium.org/2728173002), already added conditional logic to only open the dialog if the currentRoute matches the subpages's path, which seems sufficient for enabling search for the subpage.

@sammiequon: I am looking into this, so re-assigning to me for now.

FYI, candidate fix is at https://codereview.chromium.org/2896303005. I'll do a bit more manual testing before sending out for review.

re #9 - Does that fix enable searching for all words in the new MD Settings or is it specific for "Screen Lock"?

CBC is already receiving posts from users who can't find a number of settings.

Smart Lock is now part of the Screen Lock section - this is quite confusing.

https://productforums.google.com/forum/#!topic/chromebook-central/E6qWagPaDVk

#CBC-RS/TC-watchlist

@dpapad thanks for the quick fix! Will you also merge this into CrOS M59?

@jim.dantin this is specific to the Screen Lock section. If other settings aren't showing in search results, please feel free to file a bug and assign it to me!

While moving settings around at any point is going to cause some confusion, having all authentication-related settings in one place will make things easier to find in future (Show Screen Lock when waking from sleep, PIN, Smart Lock, and more to come).

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

commit 6fb4b00925d05aea219c1c966a4869e970c972ff
Author: dpapad <dpapad@chromium.org>
Date: Thu May 25 18:31:11 2017

MD Settings: Allow searching the lock screen subpage.

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

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

[modify] https://crrev.com/6fb4b00925d05aea219c1c966a4869e970c972ff/chrome/browser/resources/settings/people_page/people_page.html
[modify] https://crrev.com/6fb4b00925d05aea219c1c966a4869e970c972ff/chrome/browser/resources/settings/people_page/people_page.js

@tbuckley, @stevenjb: I am adding the Merge-Request-59 label, but not very familiar with the process of merging to Chrome OS. For Desktop usually it is OK to merge if the merge is approved and the change has been on Canary for a few days.

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The process is the same as for chrome, we just need approval from the CroOS TPM for the release, +gkihumba@.

This change is pretty small and low risk. It would be good to try it in Canary before merging, but I'm not sure where we are at with the 59 release cycle.

@gkihumba let us know if you have any questions, this issue has been causing a lot of confusion.

I think is too late to merge this to M59 now. Don't think this is severe enough to justify merging to stable.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

9592.22.0, 60.0.3112.34

The fix was landed at refs/heads/master@{#474714} and M60 branched at refs/heads/master@{#474934}, therefore I don't think there is anything to merge. The original merge request was for M59.