Checked the issue on reported chrome version 63.0.3239.132 and on the latest canary 65.0.3325.0 using Mac 10.13.1 with the below mentioned steps.
1. Launched Chrome
2. Navigated to both the URLs provided in comment#0
One URL rendered Blank page and other just kept loading. Attaching the screen cast of the same.

@Reporter: Could you please check the screen cast and let us know know whether the steps followed was correct. And please attach a sample test file as it would be out of scope for ET team to create an iframe and append it to dom. Any further inputs from your end helps us to triage the issue in a better way.

Thanks!

Deleted: 803416.mp4 5.6 MB

	803416.mp4 5.6 MB View Download

Hello. I've checked screencast. Steps are correct.

Html file with bug reproduction:
https://github.com/Urkass/forChromiumBug/blob/master/index-with-bug.html

Script file that is loaded by html file with bug reproduction:
https://github.com/Urkass/forChromiumBug/blob/master/index.js

Html file without bug reproduction:
https://github.com/Urkass/forChromiumBug/blob/master/index-without-bug.html

Thanks!

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

Checked the issue on reported chrome version 63.0.3239.132 and on the latest canary 66.0.3327.0 using Mac 10.13.1 with the below mentioned steps.
1. Launched Chrome
2. Navigated to the URLs provided in comment#4
3. Pasted the code present in both the URLs in dev tools console
4. They both rendered "Uncaught SyntaxError"
Attaching the screen cast of the same.
We even tried creating a .html file with the given code opened it throught chrome, still they resulted in the same.

@Reporter: Could you please check the screen cast and let us know if the process followed was correct. It would be highly helpful if clarified on point no.4 of comment#0 about calling a function. Providing a screen cast/screenshot showing the problem helps us to triage it in a better way.

Thanks!

Deleted: 803416.mp4 7.9 MB

	803416.mp4 7.9 MB View Download

Sorry, it happened after some refactoring. Already fixed. Take a look one more time please.
Thanks!

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

@Reporter: Could you please clarify us on your comment#7 which says "it happened after some refactoring. Already fixed". Does that mean the issue caused due to your change? and please clarify on "Already fixed". Please confirm if we can close the issue if it got resolved.

Thanks!

No, I fixed an example page that represents a bug. Now it represents it correctly. Bug in chrome still exists.
https://bugs.chromium.org/p/chromium/issues/detail?id=803416#c3 correctly represented it.

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

Rechecked the issue as per the confirmation given by the reporter in comment#10.
Able to reproduce the issue on reported chrome version 63.0.3239.132 and on the latest canary 66.0.333.0 using Mac 10.13.1, Ubuntu 14.04 and Windows 10.

Bisect Info:
=================
Good Build : 63.0.3232.0
Bad Build: 63.0.3233.0

Change Log: 
You are probably looking for a change made after 506443 (known good), but no later than 506444 (first known bad).
  https://chromium.googlesource.com/chromium/src/+log/4dccf5d1c1bf257fdf600271404a8dd8d6d06fc6..3ecbb0c68cd72a8f2a9ef16691e6c13c9b80d0fc
Suspecting: https://chromium.googlesource.com/chromium/src/+/3ecbb0c68cd72a8f2a9ef16691e6c13c9b80d0fc

Review URL: https://chromium-review.googlesource.com/696324

@japhet: Please help in re-assigning to others this is not related to your change.

Note: Adding RB-Stable, Please feel free to remove if it is not applicable.

Thanks!

Tagging with M-64, feel free to adjust if someone feels otherwise.

Punting this to M65 stable roll out.

This bug requires a specific sequence of steps:
1. Add an iframe and have it complete loading while its parent is still blocked from firing onload on something else (in the case of this repro, we haven't finished parsing the parent's html).
2. open() the iframe's document while the parent is still loading. Because the iframe is now parsing, it is back in the loading state, and will therefore block the parent from firing onload.
3. Let everything that is blocking the parent's onload complete, except the iframe.
4. Remove the iframe.

I'll do my best to have something mergeable for M65, but especially if it's already been out on stable for several weeks, this is a sufficiently unusual set of steps that I'm not convinced it should be a release blocker.

As per C#15, removing stable blocker for now.Please add if required.

Thanks..!

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

commit fd506b0ac6c7846ae45b5034044fe85c28ee68ac
Author: Nate Chapin <japhet@chromium.org>
Date: Tue Jan 30 18:47:44 2018

Fix detach with open()ed document leaving parent loading indefinitely

Change-Id: I26c2a054b9f1e5eb076acd677e1223058825f6d6

Bug:  803416 
Test: fast/loader/document-open-iframe-then-detach.html
Change-Id: I26c2a054b9f1e5eb076acd677e1223058825f6d6
Reviewed-on: https://chromium-review.googlesource.com/887298
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532967}
[add] https://crrev.com/fd506b0ac6c7846ae45b5034044fe85c28ee68ac/third_party/WebKit/LayoutTests/fast/loader/document-open-iframe-then-detach-expected.txt
[add] https://crrev.com/fd506b0ac6c7846ae45b5034044fe85c28ee68ac/third_party/WebKit/LayoutTests/fast/loader/document-open-iframe-then-detach.html
[modify] https://crrev.com/fd506b0ac6c7846ae45b5034044fe85c28ee68ac/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/fd506b0ac6c7846ae45b5034044fe85c28ee68ac/third_party/WebKit/Source/core/loader/DocumentLoader.h
[modify] https://crrev.com/fd506b0ac6c7846ae45b5034044fe85c28ee68ac/third_party/WebKit/Source/core/loader/FrameLoader.cpp

This should be fixed in canary. Regarding whether this gets merged to M65...

The case for merge:
* It's annoying that a page can leave itself in the loading-forever state.

The case against merge:
* This is already present on stable.
* It requires a fairly specific set of steps to trigger, and if the page does almost anything else after that, it will fix itself.
* The user could always just hit the stop button.
* The bug fix *should* be safe, but the code around stopping loading a page is very subtle, and it's entirely possible I introduced a bug.

I think this is a no-merge situation, but I'm happy to be persuaded otherwise.