Addendum: this also affects Chrome Canary version 71 (Desktop + Android).

Addendum:

Video demonstrating the issue and comparison with Firefox browser performing the same steps.

Chrome: https://youtu.be/rYDomyJeJvs

Firefox: https://youtu.be/R502f_a88ac

jordan@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.13.3 on the reported version 69.0.3497.81 and the latest Canary 71.0.3548.0 by following the below steps.

1. Launched Chrome and navigated to https://www.gamesmen.com.au/.
2. Could observe that the page is loading until F5 key is pressed.
Attached is the screen cast for reference.

Could you please confirm if the issue is observed on step 2, where the initial page should load correctly or should we follow all the 5 steps mentioned above to reproduce the issue?

Thanks..

Deleted: 882287.mp4 3.1 MB

	882287.mp4 3.1 MB View Download

The issue occurs on step 2,the remaining steps are for reproducibility.

Thanks.

Thank you for providing more feedback. Adding the requester to the cc list.

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

jordan@ Thanks for the update.

Able to reproduce the issue on Windows 10, Mac OS 10.13.3 and Ubuntu 14.04 on the reported version 69.0.3497.81 and the latest Canary 71.0.3548.0 as per comment #4.

But unable to provide the bisect info as the issue is inconsistent. Can observe the good and bad behaviors on the reported version 69.0.3497.81.
Attached is the screen cast for reference.

Hence marking this issue as Untriaged and requesting 'Internals>Network' team to look into the issue and help in further triaging.

Thanks..

Deleted: 882287-1.mp4 2.2 MB

	882287-1.mp4 2.2 MB View Download

I was able to repro this reliably enough to repro on Linux. Regression range just points to a single CL:
https://chromium.googlesource.com/chromium/src/+/21154794b8ae44ef571979016fd64b1de23a7cb7

Pat/Yoav: can once of you take a look?

I can take a look but probably not until the weekend (and I'll have to bring the dev environment back up).  From the sound of it, something must be triggering the parser to pause (a stylesheet of some kind) but it isn't resuming when it should.

Upon further investigation, we found this to be tied to this block of code:

`<!-- BEGIN PRIVY ASYNCHRONOUS WIDGET CODE -->
<script type='text/javascript'>
  var _d_site = _d_site || '08EE97F59C748D28165C1312';
  (function(p, r, i, v, y) {
    p[i] = p[i] || function() { (p[i].q = p[i].q || []).push(arguments) };
    v = r.createElement('script'); v.async = 1; v.src = 'https://widget.privy.com/assets/widget.js';
    y = r.getElementsByTagName('script')[0]; y.parentNode.insertBefore(v, y);
  })(window, document, 'Privy');
</script>
<!-- END PRIVY ASYNCHRONOUS WIDGET CODE -->`

When this was removed, then the page continued to load fine.

We substituted it with the "synchronous" alternative:

<!-- BEGIN PRIVY WIDGET CODE -->
<script type='text/javascript'> var _d_site = _d_site || '08EE97F59C748D28165C1312'; </script>
<script src='https://widget.privy.com/assets/widget.js'></script>
<!-- END PRIVY WIDGET CODE -->

We have also forwarded this issue to Privy.

As the code has been removed from the site, it may not longer be possible to replicate the issue directly on our website.