"Thanks for filing the issue.

@Reporter: Could you please provide a sample URL to check the issue and confirm."

It is not a Web URL as such. It is a hyperlink in a “.htm” file targeting an anchor in another “.htm” file. This is only happening offline, and is only happening with Canary. It is not happening in standard Chrome.

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

"Thanks for the clarification!

@Reporter: Could you please provide a sample .html file which will help us to triage the issue further in a better way."

The attached “.htm” files are in French, but they could be in any other language. The language is irrelevant.
If you open “_print_envelopes.htm” in Google Chrome Version 62.0.3202.94 (Official Build) (64-bit), and click on the “address_books.htm#ADRBK5” hyperlink, the target page is automatically scrolled down to the “#ADRBK5” anchor in “address_books.htm”. This is as designed.
On the other hand, if you open “_print_envelopes.htm” in Google Chrome Google Chrome Version 64.0.3279.0 (Official Build) canary (64-bit), and click on the “address_books.htm#ADRBK5” hyperlink, the target page is not automatically scrolled down to the “#ADRBK5” anchor in “address_books.htm”. The top of the page is displayed instead.
This is in Windows 10 64-bit version 1709.
HTH.

Deleted: _print_envelopes.htm 631 bytes

_print_envelopes.htm 631 bytes View Download

Deleted: address_books.htm 5.7 KB

address_books.htm 5.7 KB View Download

Deleted: help.css 7.6 KB

help.css 7.6 KB View Download

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

"Able to reproduce the issue on reported chrome version 62.0.3278.0 and on the latest canary 64.0.3279.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10.

Bisect Info:
================
Good build: 64.0.3271.0
Bad build:   64.0.3272.0

CHANGELOG URL:
You are probably looking for a change made after 517668 (known good), but no later than 517669 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/720d417bf1858ac64ff6f3ea8bbe2791aa065744..25cf0b97c844641e778fd1834b19489347eb1ea3

suspect:https://chromium-review.googlesource.com/777040

Suspecting same from changelog.

@bokan: Please confirm the issue and help in re-assigning if it is not related to your change.

Note:  Adding label RBS as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks!"

Fix is up at https://chromium-review.googlesource.com/c/chromium/src/+/809093 though I'm OOO for the next week.

Still seeing the same issue on Windows 7,Mac 10.12.6 & ubuntu 14.04 using chrome latest Canary-65.0.3290.0 as per C#6.

As bokan is OOO,could someone from scroll team please take a look into this issue as it is marked as stable blocker.

Thanks..!

I'm back, will try to land my fix ASAP.

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

commit 08015810cc4d2c65ce1d5b42250f5be033af1c0d
Author: David Bokan <bokan@chromium.org>
Date: Fri Dec 15 22:11:53 2017

Fix scrolling to anchor on load

It looks like between when I reverted my patch in
https://crrev.com/777040 and when I originally landed it there's
been some changes that meant my revert broke hash navigation.

I'm not sure how this worked before but it looks like currently
the navigation relies on the fact that at the end of a frame's
layout, we called into RootScrollerController::DidUpdateLayout
which would recalculate the root scroller and then synchronously
recompute style and layout using Document::UpdateStyleAndLayout().

When a page is finished parsing it tries to scroll to the hash
in FrameLoader::FinishedParsing. However, if the page is blocked
from rendering this will be deferred since we can't layout yet.
Normally, when the load event is fired, we'd call
Document::ImplicitClose which calls LocalFrameView::UpdateLayout.
This causes the scroll to the hash via the above indirect call to
Document::UpdateStyleAndLayout but my revert above removed this
call.

This CL fixes the issue by directly trying to scroll to the hash
in ImplicitClose.

Bug:  788486 
Change-Id: I67f78372380f043bf88fda036bf7c263b17fbca0
Reviewed-on: https://chromium-review.googlesource.com/809093
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524483}
[modify] https://crrev.com/08015810cc4d2c65ce1d5b42250f5be033af1c0d/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/08015810cc4d2c65ce1d5b42250f5be033af1c0d/third_party/WebKit/Source/core/loader/ProgrammaticScrollTest.cpp

Fix confirmed in Windows Canary (65.0.3298.0). Requesting merge to M64.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M64. Branch:3282

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

commit bff917606a7d3c87e7862739ce4abd9c70189325
Author: David Bokan <bokan@chromium.org>
Date: Tue Dec 19 13:34:25 2017

Fix scrolling to anchor on load

It looks like between when I reverted my patch in
https://crrev.com/777040 and when I originally landed it there's
been some changes that meant my revert broke hash navigation.

I'm not sure how this worked before but it looks like currently
the navigation relies on the fact that at the end of a frame's
layout, we called into RootScrollerController::DidUpdateLayout
which would recalculate the root scroller and then synchronously
recompute style and layout using Document::UpdateStyleAndLayout().

When a page is finished parsing it tries to scroll to the hash
in FrameLoader::FinishedParsing. However, if the page is blocked
from rendering this will be deferred since we can't layout yet.
Normally, when the load event is fired, we'd call
Document::ImplicitClose which calls LocalFrameView::UpdateLayout.
This causes the scroll to the hash via the above indirect call to
Document::UpdateStyleAndLayout but my revert above removed this
call.

This CL fixes the issue by directly trying to scroll to the hash
in ImplicitClose.

Bug:  788486 
Change-Id: I67f78372380f043bf88fda036bf7c263b17fbca0
Reviewed-on: https://chromium-review.googlesource.com/809093
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#524483}(cherry picked from commit 08015810cc4d2c65ce1d5b42250f5be033af1c0d)
Reviewed-on: https://chromium-review.googlesource.com/832829
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#293}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/bff917606a7d3c87e7862739ce4abd9c70189325/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/bff917606a7d3c87e7862739ce4abd9c70189325/third_party/WebKit/Source/core/loader/ProgrammaticScrollTest.cpp