Downloads page search field unexpectedly capturing ctrl + f |
||||||
Issue descriptionGoogle Chrome 66.0.3330.0 (Official Build) canary (64-bit) (cohort: Clang-64) Windows 10 Enterprise Version 1709 Build 16299.125 Steps to repro: # Launch chrome://downloads # Type ctrl + f Expected: find dialog is brought up like on any other page Actual: focus is brought to the search box at the top of the page Note that this is not just an accessibility issue since I can replicate with no assistive tech. However, it also affects screen reader users. For example, due to this bug, users find themselves in an edit box unexpectedly and there isn't an announcement explaining where they are/why they are there instead of the expected find UI. Tested with JAWS 2018.1801.18 Private Beta.
,
Jan 25 2018
FWIW, there is a workaround of going to the main Chrome dots menu on the top right, and selecting "Find in page". I believe the fact that ctrl+f triggers searching within downloads, and not "find in page", was intentional. Adding @dbeam to confirm.
,
Jan 25 2018
,
Jan 25 2018
dpapad@ this seems like expected behavior. Is there anyone who currently owns this/the other chrome:// pages? Assigning to you to make sure it gets tracked, if you don't know who owns it feel free to bounce back to me.
,
Jan 25 2018
@dtrainor: Looking at the code history, there is lot of discussion at the original issue 578323 . In short, Ctrl+F does not work well because downloads uses a virtualized list, so not all downloads are in the DOM during searching. Focusing the in-page searchbox alleviates that problem and was the suggestion in that bug, see https://bugs.chromium.org/p/chromium/issues/detail?id=578323#c4. Personally I think this is WAI given the previous discussion on this.
,
Jan 25 2018
,
Mar 14 2018
See #5. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by leberly@chromium.org
, Jan 25 2018