the url is https://zhangsanshi.github.io/demo/creazyFetch.html.
I write wrong title.

I was able to repro on linux.
This looks like a bug with setTimeout: the delay is ignored after reload.

Updating issue title to reflect the problem

Tested the issue on windows 7 , mac os 10.12.4 and ubuntu 14.04 using chrome M58 #58.0.3029.110 and chrome canary M60 #60.0.3111.0 and issue is reproduced.


During bisect , till M54 #54.0.2810.0 , issue is seen and is a bad build.
On M54 #54.0.2800.0 , when reloaded the given url , it is making the tab unresponsive and and page keeps loading for longer time..

Attached screencast for reference.

@Could someone check the attached screencast and confirm us if that is the expected behavior and if not , please provide us the expected result to traige the issue better.

Thanks!

Deleted: 726302.mp4 1.9 MB

	726302.mp4 1.9 MB View Download

I rewrite the test page and change trigger from setTimeout to click. you can test it in this page. In my pc,the tab isn't unresponsive...
https://zhangsanshi.github.io/demo/creazyFetch2.html?t=3

Deleted: 1.gif 786 KB

	1.gif 786 KB View Download

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

Tested the issue on windows 7 and mac os 10.12.4 using the given new url "https://zhangsanshi.github.io/demo/creazyFetch2.html?t=3" and observed page load for longer time after reload.

Attached screencast for reference.

@Could you please check attached screencast and confirm us if this is the expected result or provide us the expected result screencast to find correct suspect.

Thanks!

Deleted: 723602.mp4 1.3 MB

	723602.mp4 1.3 MB View Download

In this screencast, you can see the page isn't unresponsive and response code is 304.
If your tab is still unresponsive, maybe you can copy the code and test in your local server?

Deleted: 1.gif 3.4 MB

	1.gif 3.4 MB View Download

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

the code is:
<button id="btn">click me</button>
<script>
  function a () {
    fetch('https://www.google.com/xxx').then(a, a);
  }
 btn.onclick = a;
</script>

Tested the issue with the steps mentioned in comment #10 & 12 ,using the local server and observed the similar behavior as earlier.. after reload .. page keeps loading for longer time.

Attached screencast for reference.

Thanks!

Deleted: 726302.mp4 1.5 MB

	726302.mp4 1.5 MB View Download

Able to reproduce the issue on Win-10 using chrome reported version #58.0.3029.110 and latest canary #61.0.3136.0.

Following are the steps followed to reproduce the issue.
------------
1. Opened the url: https://zhangsanshi.github.io/demo/creazyFetch2.html?t=3 and dev tool and clicked network tab.
2. Waited for 10s, the request appeared.
3. Reloaded the page by typing F5.
4. Observed that request was sent immediately without waiting fro some seconds.

Note: In M-54 and M-53, on reloading the page at step-3, the page loaded for ever and became unresponsive.

Attached a screen cast of M-53 for reference.

Hence, marking it as untriaged for more inputs from dev.

Thanks...!!

Deleted: 726302.mp4 1.4 MB

	726302.mp4 1.4 MB View Download

More updated on this issue:

Till M-51 issue is not reproducible. Hence, it can be considered as good.
From M-52 till M-54, on reloading the page at step-3 of comment #14, the page loaded for ever and became unresponsive.
M-55 showed bad behavior.

Hence, its not feasible from TE-end to provide bisect results.

Requesting anyone from Platform>DevTools>Network team to help us in bisecting the issue and providing the bisect results.

Thanks...!!

I don't think setTimeout is the problem here. Instead it looks like the fetch request is somehow kept alive after the reload. Any idea how that could be happening?

Here's a slight variant which uses a different URL every time the page is loaded. This makes it easy to see that even after reload, it's the requests from the old page that keep going.

It's not just fetch() that is running, either. The Javascript code which starts each new fetch in response to the failure of last one has to still be running too. I didn't know that was possible.

Deleted: creazyFetch3.html 189 bytes

creazyFetch3.html 189 bytes View Download

Here's another variant that changes the URL via the unload handler. This demonstrates that the page does know that it has been unloaded.

I've tested in Firefox and Safari. Firefox doesn't have the issue. Safari maybe does? I'm not very familiar with Safari's devtools.

Deleted: creazyFetch4.html 222 bytes

creazyFetch4.html 222 bytes View Download

I've verified that it still happens when the target host is localhost using regular HTTP. So no dependency on HTTPS, HTTP/2 or QUIC, and CORS is not the cause.

+yukishiino@, domenic@

According to yukishiino@, it is an expected behavior. Domenic, what do you think?

My understanding is as follows.

There are two windows: parent and child.
The child window is running a function |func| as follows:
  function func() {
    fetch(url).then(func, func);  // [1]
  }
  func();
The parent window makes the child window navigate to another same origin page.
However, the infinite loop of |func| doesn't stop.

Even after the navigation, the old child window's context is still alive and |func| (or fetch's promise) is still running.  Even when |fetch| failed, the failure handler of the promise |func| is invoked.  I don't know who stops this.

After the navigation, the WindowProxy points to a new window object, then [1] is equivalent to:
  new_window.fetch(url).then(func, func);
So, the fetch task is done with the new child window.  This is confusing, but this is what WindowProxy is designed for, IIUC.

The questions that people here may have seem:
a) Why the infinite loop does not stop?  Who stops it?
b) Why the fetch task runs with the new window?  Why it doesn't stick to the old window (despite that the script is written in the old window)?

I'd like to hear domenic@'s opinions / interpretations.

I agree this is expected behavior. There is some spec ambiguity/bugs as to whether it should reject or fulfill, i.e. whether navigating should abort all ongoing fetches with some error or should just let them work. (See https://github.com/whatwg/fetch/issues/416 for example.) But one of the two handlers will definitely be called right now.

For a), the above describes why it keeps going infinitely, plus the fact that while navigating probably aborts fetches, once navigated, you can still fetch just fine. We could change this in the spec by not allowing fetch() calls from non-active (or non-fully-active?) documents. /cc @annevk. That is how setTimeout behaves, for example. That would break the infinite loop.

For b), your analysis about WindowProxy seems exactly right to me.

Removing Needs-Bisect label as this issue has been taken up by the dev team.
Please feel free to add the Needs-Bisect label if needed.

Thanks...!!

This is basically https://github.com/whatwg/html/issues/2621 as far as I can tell.

I suppose so, although that took a direction I do not favor of trying to patch promises, whereas I think the correct solution is to change fetch so that it does not even start the fetch in inactive documents. Should we use that bug to discuss such a solution, even though so far it's all about promise behavior?

We could have a different bug just for Fetch, but it's fundamentally the same problem. Using computing resources for documents that are abandoned using promises.

It also seems that even your proposal would still result in an infinite loop as the fetch() call would get rejected resulting in it being invoked again.

 Issue 781904  has been merged into this issue.