New issue
Advanced search Search tips

Issue 827491 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Setting location.hash doesn't scroll the page when the new and old value are same.

Reported by taken....@gmail.com, Mar 30 2018

Issue description

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

Steps to reproduce the problem:
1. Setting location.hash with value previously set

What is the expected behavior?
2. The page should be scrolled
3. The sequential focus navigation starting point should be updated

What went wrong?
1. Setting location.hash with value previously set
2. The page isn't scrolled
3. The sequential focus navigation starting point isn't updated

On Firefox and Edge, the page is scrolled and the sequential focus navigation starting point is updated.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 67.0.3383.0  Channel: canary
OS Version: 10.0
Flash Version: 

Summary of issue:
Setting location.hash doesn't scroll the page and update the sequential focus navigation starting point (https://developers.google.com/web/updates/2016/03/focus-start-point) when the new and old value are same.

- Chrome has this issue
- Firefox and Edge don't have this issue (the page is scrolled and the sequential focus navigation starting point is updated)

Activating internal links (intra-page links) always scroll the page and update the sequential focus navigation starting point when the new and old hash are same.

- Chrome, Firefox, and Edge works fine.

Expected behavior:
Setting location.hash should scroll the page and update the sequential focus navigation starting point regardless of value.

Related information:
This issue causes making simple apps keyboard accessible a bit harder.

Without this issue, developer can write following code:

<div id="page"><!-- the content goes here --></div>
<button type="button" id="button">The content will be refreshed. Please read from the beginning of the page.</div>
<script>
document.getElementById('button').addEventListener('click', () => {
	// refreshing the content...

	// Navigate user to the beginning
	location.href = 'page';
}, false);
</script>

However, with this issue authors need to write a bit complicated script.

<div id="page"><!-- the content goes here --></div>
<button type="button" id="button">The content will be refreshed. Please read from the beginning of the page.</div>
<script>
document.getElementById('button').addEventListener('click', () => {
	// refreshing the content...

	// Navigate user to the beginning
	var el = document.getElementById('page');
	el.scrollIntoView(el);
	el.focus();
	// focus() fails silently
	// there is no simple cross-browser way to identify whether the element is focusable or not.
	if (document.activeElement !== el) {
		el.tabIndex = -1;
		el.focus();
	}
}, false);
</script>

 

Comment 1 by woxxom@gmail.com, Mar 30 2018

Simplified test case attached below.
Expected to show "SUCCESS" on a green background, but Chrome shows "FAILURE" on red.
Observed in all versions of Chrome, including Canary.
test-location-hash.html
383 bytes View Download
Labels: Needs-Triage-M67
Components: UI
Labels: -Pri-3 Triaged-ET M-67 Target-67 FoundIn-67 OS-Linux OS-Mac OS-Windows Pri-2
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue(as per comment# 2) on reported chrome version 67.0.3383.0 and on the latest chrome version 67.0.3386.0 using Windows-10, Mac 10.12.6 and Ubuntu 14.04. As the issue is seen from M60(60.0.3112.0) considering it as non-regression and marking it as Untriaged.

Thanks!
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
***UI Mass Triage***

We are able to reproduce this bug on latest canary #72.0.3622.0.Hence adding respective labels for further triage. Thanks!


Sign in to add a comment