bedney@ In order to triage this issue could you please help us with the sample http test case.

Thank You...

kkaluri@ - Unfortunately, I cannot right now. The library that I'm using is not open source at the moment, although that's due to change within the next several months.

Also, I just noticed in testing again that today's Canary builds (Version 59.0.3044.0 canary (64-bit)) seem to have possibly fixed this problem. A bisect on your end between 3042 and 3044 might give a clue as to what was happening.

I'd like to leave this bug open if possible and continue to monitor the situation, at least until Chrome 59 hits the release channel. At that time, if the problem crops up again, I might be able to provide a link to the library that's causing the issue, since it may be open source at that time.

If a bisect can determine a relevant change, then I'd say close this out and it would be a 'happy day' for me :-).

Thank You!

Thank you for providing more feedback. Adding requester "kkaluri@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

avi@ since you were in this code recently. Does it ring any bells of issues you fixed?

This sounds like it might be beforeunload. If the browser is reloading a page, it would ask the renderer to give the page a beforeunload event, and it would start a timer. If it didn't get a reply within a second, it would continue on.

In the past, we reused the "hung page" timer for this, but in the (3042..3044) range my change to split off the beforeunload timer landed. It sounds reasonable that my change to split the timer (2d7d2c3632187e2cfaaa5c6ec26d3adb3ae784b0) could have had this positive effect.

Yes, that was probably it.

This library that we use installs a 'beforeunload' hook. If the change that you made between 3042..3044 is one that you're going to keep, then that fixes it for us and this can be closed.

Thank you everyone!

As a further note, the library that we're using is 'heavy' (it is a SPA library, so we don't reload it with every page), so it takes ~1500ms to load (on Chrome 59 - it used to take ~1850-2000ms on earlier versions before Chrome 56 and before TurboFan+Ignition landed). So 1000ms is a pretty short time for us. 2000-3000ms is better.

OTOH, if that time no longer affects the 'beforeunload' hook now, this might not be relevant.

c7: This was part of an ongoing refactor of the hang machinery for OOPIF, so we're planning on keeping it.

c8: Yes, you have a long loading time, but you don't have any unsaved data on your page while you're loading, so that shouldn't affect you. Once your page is loaded, surely your beforeunload handler won't take more than 1000ms, right?

That's great that you're keeping it.

No, our beforeunload handler won't be taking longer than 1000ms. :-)

Thank you for your prompt response and thanks to everybody for all of your hard work on Chrome! It gets more awesome every day!

This issue can definitely be closed! Yay!

Yay!

WontFix; give us a holler if circumstances change.