Tested on Mac os 10.12.2 using chrome M56 #56.0.2924.87 and followed below steps :

1. Launched chrome and navigated to sample url given in  issue 446756  i.e.,http://img04.taobaocdn.com/tfscom/TB1_hhLHXXXXXXqXFXXO04pFXXX.html 
2. Appended # to the url end and reloaded the page
3. Page scroll jumps to the first ., observed same behavior in firefox and safari browsers too.

Attached screencast for reference.

@veevers.paul-- Could you please check attached screencast and confirm us if anything we missed from our side to reproduce the issue and also provide us the test url and expected result screencast , that would help us in traiging the issue better.

Thanks!

Deleted: 699267.mp4 1.0 MB

	699267.mp4 1.0 MB View Download

veevers.paul@gmail.com: Did you forget to attach a sample page? Also, when you say reload, do you mean pressing "Enter" with focus in the omnibox? Or actually clicking reload? (I assume the former since you added the hash)

Also, unless it's a regression, reducing to normal priority.

Ah yes, very sorry I forgot the attachment. Here it is.

Thanks for the responses.

Deleted: chrome-iframe-bug.html 763 bytes

chrome-iframe-bug.html 763 bytes View Download

bokan@chromium.org: Either way seems to reproduce it.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" 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 Windows 10, mac 10.12.3 and Ubuntu 14.04 using chrome reported version #56.0.2924.87 and latest canary #59.0.3042.4.

Bisect Information:
=====================
Good build: 56.0.2913.0    Revision(430459)

Bad Build : 56.0.2914.0    Revision(430837)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/5db5553160affb9ea2464666320c3855e5d203d2..b8cb16f79a95c8bc639a9c58785a8484c197aca9

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2269043002

hiroshige@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Hmm. Looks like the scroll (unexpectedly) occurs if doc.write() is called after a certain point of time.

The <style> tag + https://codereview.chromium.org/2269043002 makes iframe's load event to occur a little later and thus causes the issue.
However, setTimeout() can also be used to delay doc.write() (see the attached test case).

Deleted: chrome-iframe-bug-2.html 759 bytes

chrome-iframe-bug-2.html 759 bytes View Download

Created a layout test: https://codereview.chromium.org/2797783002/
And the test fails even at r406082 on Linux.

I suspect this is not a recent regression: my CL just exposed an existing issue in scrolling.
bokan@, could you take a look?

r266359 is also failing.

Thank you hiroshige@ for the analysis and test, that will help. I'll take a look - I'm guessing our scroll to fragment logic is being triggered incorrectly.

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

commit 783d491b68d1b5833b65accba2e4fd595f09a404
Author: bokan <bokan@chromium.org>
Date: Mon Apr 24 21:21:39 2017

Clear hash when setting URL in document.open()

A document created via document.open()/write()/close() will have
as its URL the "responsible document" (see step #23 of
https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open)

This is a problem when the URL includes a fragment identifier, any
frame with a document.open from a document with a fragment will try
to scroll the iframe into view. I believe the intent in the spec was
not to include the hash.

BUG= 699267 

Review-Url: https://codereview.chromium.org/2801093002
Cr-Commit-Position: refs/heads/master@{#466770}

[add] https://crrev.com/783d491b68d1b5833b65accba2e4fd595f09a404/third_party/WebKit/LayoutTests/fast/scrolling/doc-write-to-iframe.html
[modify] https://crrev.com/783d491b68d1b5833b65accba2e4fd595f09a404/third_party/WebKit/Source/core/dom/Document.cpp

Confirmed fix in Canary, this would be good to merge back to 59

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

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

commit 6c3f14d345e3a04319074eced38eec423b8cd537
Author: David Bokan <bokan@chromium.org>
Date: Wed Apr 26 18:15:25 2017

Clear hash when setting URL in document.open()

A document created via document.open()/write()/close() will have
as its URL the "responsible document" (see step #23 of
https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open)

This is a problem when the URL includes a fragment identifier, any
frame with a document.open from a document with a fragment will try
to scroll the iframe into view. I believe the intent in the spec was
not to include the hash.

BUG= 699267 

Review-Url: https://codereview.chromium.org/2801093002
Cr-Commit-Position: refs/heads/master@{#466770}
(cherry picked from commit 783d491b68d1b5833b65accba2e4fd595f09a404)

Review-Url: https://codereview.chromium.org/2843763005 .
Cr-Commit-Position: refs/branch-heads/3071@{#232}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[add] https://crrev.com/6c3f14d345e3a04319074eced38eec423b8cd537/third_party/WebKit/LayoutTests/fast/scrolling/doc-write-to-iframe.html
[modify] https://crrev.com/6c3f14d345e3a04319074eced38eec423b8cd537/third_party/WebKit/Source/core/dom/Document.cpp

Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.4 using chrome latest beta M59 #59.0.3071.29 by following steps mentioned in the original comment using test case provided in the comment #7. Observed no scroll jump to iframe as expected. Hence adding TE-Verified label.

Deleted: 699267.ogv 854 KB

	699267.ogv 854 KB View Download

 Issue 596051  has been merged into this issue.