New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 784164 link

Starred by 3 users
Status: Fixed
Owner:
aee@chromium.org
Closed: Jan 7
Cc:
aee@chromium.org
█ vamshi.k...@techmahindra.com
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Ctrl-F behaves in at least three different way in MD settings pages

Reported by mr.ber...@gmail.com, Nov 12 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36

Steps to reproduce the problem:
1. Go to chrome://downloads/
2. Click gray background
3. Hit Ctrl-F twice

4. Go to chrome://history
5. Click gray background
6. Hit Ctrl-F twice

7. Go to chrome://settings/searchEngines
8. Click gray background
9. Hit Ctrl-F twice

What is the expected behavior?
In all cases, a relevant text input should be highlighted, as all pages seem to use iron lists which do not render all their content from the start, rendering some of it unfindable.

What went wrong?
3. The "Search downloads" text input is highlighted, and nothing else happens. So this works as expected, thanks to fixed  Issue 578323 .

6. While the first Ctrl-F highlights the "Search history" text input, a subsequent hit of Ctrl-F opens the find-in-page dialog. Related bugs are  Issue 760836 , which was merged into  Issue 687762 . This latter bug is WontFix due to reasoning in  Issue 578323 , which was later fixed, so I suspect  Issue 687762  should be looked at again.

9. Each hit of Ctrl-F opens the find-in-page dialog; this is described in  Issue 784161 .

Did this work before? N/A 

Chrome version: 62.0.3202.89  Channel: stable
OS Version: 10.0
Flash Version: 

In general, I feel access to these (and probably other) in-page text search input fields should be harmonized.

Comment 1 by manoranj...@chromium.org, Nov 13 2017

Labels: Needs-Triage-M62

Comment 2 by vamshi.k...@techmahindra.com, Nov 14 2017

Cc: vamshi.k...@techmahindra.com
Labels: Triaged-ET Proj-MaterialDesign-WebUI
"Unable to reproduce the issue on the reported chrome version stable 
62.0.3202.89 and on the latest stable 62.0.3202.94, adding appropriate label 
and component for further triaging.

Thanks!"

Comment 3 by mr.ber...@gmail.com, Nov 14 2017 

I guess since I added 9-step repro instructions, if necessary, someone will get back to me with information about which step failed to reproduce.

Comment 4 by woxxom@gmail.com, Nov 14 2017 

The test team couldn't reproduce because they didn't have enough search engines added to force the list to be lazy-rendered. Anyway, this is a known issue as can be seen from the linked issues in the report so the test team could simply assign the relevant components (e.g. UI>Browser>Downloads and others) and make it Untriaged.

Comment 5 by krajshree@chromium.org, Nov 17 2017

Components: UI>Settings
Labels: M-64 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #62.0.3202.89 and latest canary #64.0.3270.0.
This is a non-regression issue as it is observed from M59 old builds from the time md-settings was implemented. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Comment 6 by dpa...@chromium.org, Jul 25

Cc: aee@chromium.org
Components: -UI -UI>Settings UI>Browser>WebUI
Labels: -Pri-2 OS-Chrome Pri-3
Status: Available (was: Untriaged)
There is ongoing work to make ctrl+F handling more sane, at least in Settings, see  issue 862701 .

Comment 7 by aee@chromium.org, Dec 27

Cc: -aee@chromium.org
Owner: aee@chromium.org
Status: Started (was: Available)

Comment 8 by aee@chromium.org, Dec 27 

The issues noted in this bug are resolved. I did find an issue with the bookmark manager. Pressing ctrl+f opens the browser find in page. It seems like the behavior should match the other pages (giving focus to a in-page search input).

This is a similar enough issue that I'll fix it under this bug.

Comment 9 by mr.ber...@gmail.com, Dec 27 

@aee if you say these issues are fixed, which version are you referring to? I  have just checked Version 73.0.3653.0 (Official Build) canary (64-bit), and the only change I can notice is that for the search engines settings page (step 9 in my repro steps). The other pages (steps 3 and 6 above) still behave as before, and still as inconsistently to each other and to the search engines settings page as before.

Comment 11 by aee@chromium.org, Dec 28 

When testing, I primarily use the tip of tree.

The main page search in the toolbar seems to be working consistently for chrome://settings, chrome://history and chrome://downloads. I've just changed chrome://bookmarks to work in a similar way.

The steps I took.

1. Load top-level page (settings, history, downloads and bookmarks).
2. The search input in the toolbar has focus due to autofocus.
3. Left mouse click the background. The search input no longer has focus.
4. Press ctrl+f. The search input has focus.
5. Press ctrl+f. The search input still has focus.

When trying the above steps with chrome://extensions, step 4 results in the find in page rather than search input getting focus. This should be updated.

It's arguable that step 5 should result in the find in dialog being shown.

For settings sub-pages with sub-page search like chrome://settings/searchEngines, I think it is reasonable for the sub-page search to initially gain focus. When the find shortcut is invoked when the sub-page search input already has focus, maybe the focus should move up to the settings toolbar search.

I do not notice different behaviors on the history and downloads pages. Am I missing a step in reproducing the inconsistency?

The settings sub-page with search is different. We should consider moving the focus from one search input to the next when the find shortcut is invoked while a search input already has focus. We should also consider either cycling through the search inputs or only move the focus up in one direction. If we don't cycle we should probably show the find in page when the find shortcut is invoked and the toolbar search input has focus.

Comment 12 by mr.ber...@gmail.com, Dec 28 

@aee I couldn't agree more with all of your above reasoning.

> I do not notice different behaviors on the history and downloads pages. Am I missing a step in reproducing the inconsistency?

I am not sure. I don't have ToT version, so I checked the newest Version 73.0.3654.0 (Official Build) canary (64-bit) (which is up one minor version from yesterday, so should be pretty brand-new). In that version, hitting Ctrl-F *twice* (that is, after step 5) on chrome://history/ opens the find-in-page search, which it does not on chrome://downloads/. I have double-checked your repro steps and they look complete to me. So maybe there still is some difference between ToT and Canary, in which case I can retest later. Or there is something else going on. Note I am using a clean profile with no downloads or history at all.

Comment 13 by aee@chromium.org, Jan 7

Cc: dpa...@chromium.org aee@chromium.org
 Issue 862839  has been merged into this issue.

Comment 18 by aee@chromium.org, Jan 7

Status: Fixed (was: Started)
History, Downloads, Bookmark manager, Settings and Extensions pages now all use the same find shortcut code which works the same way.

When the search input has focus, ctrl+f will move the focus to another search input in order of inner-most to outer-most. If the focus is on the outer-most search, the focus will move to the inner-most. If there is only one search input (on the toolbar), the find shortcut will do nothing.

When the search input does not have focus and no drawer, dialog or action menu is open, the inner-most search input will gain focus.

When a drawer, dialog or action menu has focus is shown, the find shortcut will display the browser's native find-in-page. The exception to this is when a dialog like "Add languages" has a search input, the find shortcut will move the focus to the dialog's search input.
Project Member

Comment 19 by bugdroid1@chromium.org, Jan 8 

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

commit 18da368b703fcbb53053b8946e568ffa5b07bc3f
Author: Esmael El-Moslimany <aee@chromium.org>
Date: Tue Jan 08 02:19:11 2019

Revert "Extensions WebUI: have ctrl+f focus on toolbar search input"

This reverts commit 5a7012aa902c2836c3370a30a61f2c0f6a53c356.

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> Extensions WebUI: have ctrl+f focus on toolbar search input
> 
> Bug:  784164 
> Change-Id: I1444d2ec9f52fff66b9a5138bf0c4d77bb209fcc
> Reviewed-on: https://chromium-review.googlesource.com/c/1394879
> Reviewed-by: Dan Beam <dbeam@chromium.org>
> Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#620416}

TBR=dbeam@chromium.org,aee@chromium.org

Change-Id: I1ad47c838aaeaeb2bcfa68c142ed9c4994c316de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  784164 
Reviewed-on: https://chromium-review.googlesource.com/c/1400055
Reviewed-by: Esmael El-Moslimany <aee@chromium.org>
Commit-Queue: Esmael El-Moslimany <aee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620583}
[modify] https://crrev.com/18da368b703fcbb53053b8946e568ffa5b07bc3f/chrome/browser/resources/md_extensions/BUILD.gn
[modify] https://crrev.com/18da368b703fcbb53053b8946e568ffa5b07bc3f/chrome/browser/resources/md_extensions/manager.html
[modify] https://crrev.com/18da368b703fcbb53053b8946e568ffa5b07bc3f/chrome/browser/resources/md_extensions/manager.js
[modify] https://crrev.com/18da368b703fcbb53053b8946e568ffa5b07bc3f/chrome/browser/resources/md_extensions/toolbar.js
►

Sign in to add a comment