This has been discussed before, for other similar cases where virtual lists are used, which make "Find in page" feature not sufficient, see for example https://bugs.chromium.org/p/chromium/issues/detail?id=805781#c5.

The solution is to use the password specific search box provided at the top right of the page (see screenshot). Whether that field should be focused when pressing Ctrl+F is a different discussion.

Deleted: password_search.png 26.2 KB

	password_search.png 26.2 KB View Download

+1, native Ctrl+F is infeasible due to the lazy loading, as dpapad@ correctly described. We could simply focus "Seach passwords" on Ctrl+F, but this is something UX should decide on.

So my understanding of https://codereview.chromium.org/1613233003 is that this existed but got lost due to the Polymer migration?

My position is that for a user the Ctrl+F shortcut, a global pattern to trigger searches, is broken and this is not WAI. A user should not need to know what a lazily loaded list is.

I see three ways of fixing this:
1) Ctrl+F focusses the search field.
2) Ctrl+F reveals a new field that is at the top of the page (where they would expect the search field) that lives in the content area.
3) The lazy list is loaded in the background beyond the visible viewport so that Ctrl+F works.

It looks like that  bug 578323  concluded to go with solution 2, which seems to be the easiest approach and reasonable to me.

Marking this as a regression of  bug 578323 .

@battre:  Issue 578323  is different than the Settings case described here. In chrome://downloads there is only one search field.

In the case of Settings there are two search fields. One at the top of the pages which triggers a Settings-wide search. One within the passwords subpage (other subpages have similar fields), that triggers a password only search.

What would Ctrl+F focus is this case? Once could argue for both Settings-wide search, or password specific search. Don't fully understand how the Settings is now considered a regression of  issue 578323  which refers to a different page.

I think there's a few confusing aspect here.

Settings has *contextual* search (i.e. searching for "google.com" inside of the passwords dialog filters matching passwords).

Settings also has *global* search, ex: you type "autofill" and only sections that match /autofill/i are preserved (others filtered out) and there are bubbles pointing at highlights.

Downloads really only has 1 search, and it's hard to understand whether it's *global* or *contexual*, as downloads is such a simple page it's basically like 1 list in settings (which has like 50+ lists/contexts).

History (middle complexity) actually does the best here, IMO, as both Ctrl+f and / trigger search globally.

As to whether downloads/history have *global* search -- the top blue bar on all these pages has a search box and ALWAYS shows.  History and Downloads both respond to Ctrl/Cmd+f globally (the event listener is installed "catch all" place: the document).  

TL;DR - I think focusing a contextual search box (i.e. the passwords search box) when a user presses Ctrl/Cmd+f with passwords dialog open makes sense.  This should probably apply to any dialog -- if it has a custom search box and it's taking up the whole screen, I think it's fairly sane/intuitive to have this behavior ESPECIALLY if the native Ctrl/Cmd+f wouldn't work will cuz virtualization (i.e. <iron-list>).  I also think Settings should implement global search.

I DO NOT THINK that force-rendering a bunch of DOM just to handle native find in page is a good answer.  It'll jank up the UI thread for a long time, bloat the tab's memory, and I'm not sure when we'd unrender it (if any of this is even easily possible).

I also don't think it's a good idea to use our native C++ access super power to make Ctrl/Cmd+f smarter, because it just doesn't scale and it's incredibly uncommon (i.e. normal web pages can't do this, the blink team will probably dislike this compared to actually fixing this problem for the web, etc.).

might as well implement the global search (when no dialogs are showing)

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

commit ded18d436d795a6d7dc326321067de513beb42d9
Author: Dan Beam <dbeam@chromium.org>
Date: Thu May 10 02:19:39 2018

Settings: Add reusable contextual search mechanism

- Add FindShortcutBehavior for handling Ctrl/Cmd+f keyboard shortcut
- Use new behavior in <settings-ui> and <settings-add-languages-dialog>

The functional results of this change:

- Ctrl/Cmd+f focuses settings-specific search box (+ prevents default)
- Ctrl/Cmf+f does nothing when a <dialog> (i.e. side bar) is showing

Note: when navigating to a subpage, focus seems to be lost (both with
keyboard and with mouse), so Ctrl/Cmd+f doesn't trigger
settings-specific search in these cases.

Bug:  819770 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I8e8263827b107aaf256900750ea14409b736f597
Reviewed-on: https://chromium-review.googlesource.com/956901
Commit-Queue: Dan Beam (no longer on Chrome) <dbeam@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557427}
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/BUILD.gn
[add] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/find_shortcut_behavior.html
[add] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/find_shortcut_behavior.js
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/languages_page/BUILD.gn
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/languages_page/add_languages_dialog.html
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/languages_page/add_languages_dialog.js
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/settings_resources.grd
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/settings_ui/BUILD.gn
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/settings_ui/settings_ui.html
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/browser/resources/settings/settings_ui/settings_ui.js
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/test/data/webui/BUILD.gn
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/test/data/webui/cr_elements/cr_drawer_tests.js
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/chrome/test/data/webui/settings/settings_ui_browsertest.js
[modify] https://crrev.com/ded18d436d795a6d7dc326321067de513beb42d9/ui/webui/resources/cr_elements/cr_drawer/cr_drawer.js

 Issue 759395  has been merged into this issue.

i'm not [currently] looking into making Ctrl/Cmd+f work on all dialogs

Work on this started as part of https://crrev.com/c/1141157. +aee@

https://crrev.com/c/1141157 merged as r579225 and fixed this issue. Thank you, aee@!