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

Issue 853726 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

key and link focus lost on back function

Reported by shrade...@nomissoft.com, Jun 18 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

Steps to reproduce the problem:
1. large link page, click a link down the page
2. see the linked page, click back function
3. focus on link (colour etc.) is lost, keyboard is back at first input field of original page

What is the expected behavior?
When returning to page via the back button the focus of keyboard, input field and URL should be kept and the previously clicked URL should be coloured according to focus again.

What went wrong?
Obviously the focus is either not stored on clicks or is not restored on the back functions.

Did this work before? No 

Chrome version: 67.0.3396.87  Channel: stable
OS Version: 6.3
Flash Version: 

This is an extremely annoying bug present in all versions I know of Chrome and causes me to still use IE where this works. Working with link pages it is essentiell to have a good colour marking of the last link processed so that the next link is found instantly and processing continues at the right spot.

It is also essentiel to maintain the keyboard focus so that an accidental go and back returns to the correct field and permits to continue proper input rather than needing to tab, perhaps several dozen of fields, to the field being edited.
 
Labels: Needs-Triage-M67
Cc: sindhu.chelamcherla@chromium.org
Labels: Triaged-ET Needs-Feedback
Unable to reproduce this issue on reported version 67.0.3396.87 using Windows 7 with below mentioned steps.

1. Navigated to wikipedia and scrolled down to bottom
2. Observed kink color as blue, clicked on the link so page gets navigated.
3. Now on using back button page is seen scrolled to bottom and color of link to which we navigated before changed. Attaching screencast for reference.

@Reporter: Please check the video and let us know if we miss anything. Could you please provide URL on which this issue is seen. If possible please guide us with a video on reproducing the issue. This would help in better triaging of the issue.

Thanks!


853726.mp4
4.0 MB View Download
The video shows the link got its "visited" (a.visited) colour.

Page (see example attached) needs to set visited and focus colours differently:

  A:visited { color:red;text-decoration:none:font-weight:bold; }
  A:active { color:green;text-decoration:none;font-weight:bold; }
  A:focus { color:green;text-decoration:none;font-weight:bold; }

Now click on "Bug List" link in the example, link (because it becomes focus and active) turns green, the new page (the list of chromium bugs) is called and displayed. Now go back, the link colour has changed to red (visited) but not to green (focus, active).

If you then try to tab to the correct link, the first tab "greens" the first "specific bug" link, only the second tab then the previously active "Bug list" link.

This second observation also highlights that the correct keyboard input field (focus) has been lost.


test.html
494 bytes View Download
Project Member

Comment 4 by sheriffbot@chromium.org, Jun 19 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: M-69 Target-69 FoundIn-69 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 67.0.3396.87 and latest canary using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

NOTE: On visiting back in firefox seeing green link for active link

Thanks!
Is there any estimate yet when this will get fixed? Two main versions of Chrome later the issue is still there and prevents the use of Chrome for working (large) link pages.
Labels: Hotlist-DesktopUIChecked
Status: WontFix (was: Untriaged)
*** UI Mass Triage ***

 Unable to reproduce the issue, if this bug still reproduces for you, please reopen or file a new issue. Thanks!
I updated to Chrome 69.0.3497.100 (current version as of today) and still find the issue active.

Please check out the sample/test.html that I had submitted earlier in comment 3, which makes different colour assignments to focus, active and visited links, only then this becomes visible at all and was verified already by a Chrome supporter (track back this bug history please). The focus is not dealt with correctly in both the link colouring as well as the keyboard focus position.

@ https://bugs.chromium.org/u/3421504036/

I seem to be unable to reopen the issue, please re-open the issue (I strongly hope the bug fix makes it into the next version of Chrome indeed)
Cc: phanindra.mandapaka@chromium.org
 Issue 907507  has been merged into this issue.
Labels: Hotlist-DesktopUIConsider
Status: Untriaged (was: WontFix)
Labels: Group-Focus_or_Input
Labels: -M-69 -Target-69 M-73 Target-73
Status: Available (was: Untriaged)
Staging on views team for focus investigation.
Labels: -Hotlist-DesktopUIConsider Hotlist-DesktopUITriaged

Sign in to add a comment