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

Issue 638482 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Sep 13
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression: Focus does not appear on Find bar via tab key after clicking on page.

Reported by jshan...@etouch.net, Aug 17 2016

Issue description

Chrome Version:53.0.2785.70 (Official Build) 96e2feaa628dc2acd70404bf970fbdf18ec1bc2b-refs/branch-heads/2785@{#635}-32/64 bit
OS: Windows (7,8,8.1,10), Mac(10.10.5, 10.11.4), Linux (14.04 LTS).

Steps:
1. Launch Chrome,Press 'Ctrl+F' key to open Find in page on any page/NTP.
2. Type some letter like 'g', click anywhere on page then click on 'Next' button.
3. Now press tab key and observe

Actual: Grey highlight is not seen on 'Previous' button after step 3 i.e Focus does not appear on Find bar.

Expected: Grey highlight should be seen on 'Previous' button after step 3 i.e Focus should appear on Find bar.

This is a regression issue broken in M-53, below is bisect info.

https://chromium.googlesource.com/chromium/src/+log/d3655e825ef57ce4543f96959523713d84a3b077..c89b095ae1e9a36e10aed62540b642f885743241?pretty=fuller&n=100

Suspecting: r401079 ?

Please help to re-assign if your change is not the cause for this issue.
 
Actual_find.mp4
573 KB View Download
Expected_find.mp4
983 KB View Download

Comment 1 Deleted

Comment 2 by jshan...@etouch.net, Aug 17 2016

Labels: hasbisect
Owner: msw@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: Regression: Focus does not appear on Find bar via tab key after clicking on page. (was: Regression: Grey highlight stays on 'Previous' button even after clicking on 'Next' button.)

Comment 3 by msw@chromium.org, Aug 19 2016

Cc: pkasting@chromium.org
Peter, I'm curious what you think should happen here. Should next/previous buttons take focus when clicked/touched (perhaps just when the find bar textfield itself doesn't have focus)?
My offhand reaction is that the current behavior is correct.

What happens in web content?  If you have tab focus on some element, and click a button elsewhere in the page, and hit tab again, does the focus transfer from the original element or from the button?

Comment 5 by msw@chromium.org, Aug 19 2016

Labels: OS-Chrome
AFAICT, clicking a button in web content transfers focus to that button.
(so hitting TAB causes focus to cycle to the element after the button)

Right now, focus disappears when clicking find-next after clicking web content; TAB/SPACE/ENTER/typing is no-op :(
My comment #3 seems better (focus next/prev(/close?) on click/touch, unless the find bar textfield has focus). WDYT?
Otherwise, I'm inclined to always focus the find next/prev(/close?) buttons on click/touch down.
The only two behaviors that make sense to me are:

* Clicking next/previous always sets focus to them
* Clicking next/previous never changes the focused element in any way

Sounds like the first is more consistent with how we handle web content.  But I don't know if it's consistent with how we handle top-level UI.  I don't think e.g. clicking back/forward set focus to them.

Comment 7 by msw@chromium.org, Jan 17 2017

Cc: msw@chromium.org
Labels: -Pri-1 Pri-2
Owner: ----
Status: Available (was: Assigned)
Project Member

Comment 8 by sheriffbot@chromium.org, Mar 9 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Archived (was: Untriaged)
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Sign in to add a comment