I can reproduce and it shows "Waiting on px.dynamicyield.com..." but chrome://net-internals shows all px.dynamicyield.com requests completed successfully.

Attached net_export.zip looks similar to my experience, all px.dynamicyield.com requests completed successfully.
Worked fine in non-incognito window, always hangs in first load in incognito window.
Removing networking component as it looks like some issue in the renderer.

Tried testing the issue on reported chrome version #70.0.3538.77 using Windows 10 and Mac 10.13.6 by following steps.

Steps:
=====
1.Launched chrome and opened incognito window.
2.Navigated to "https://fabled.com/christmas/gifts/limited-edition ".
3.Observed that the site got loaded( tried more than 30 times).
Note: Tried with the link mentioned in comment#1, observed "403 Forbidden" error.

Attached screencast for reference.
@reporter: Could you please review attached screencast an let us know if anything is being missed here. Request you to retry the issue by creating a new person without any apps and extension in it, reset all flags to default and let us know if the issue still persists.
Thanks.!

Deleted: 902237.mp4 3.7 MB

	902237.mp4 3.7 MB View Download

There's nothing missing in the steps. We did various changes today and it's possible the page was working properly when you tried it. We identified the culprit to be dynamically injected @import css statement (done by scripts from dynamicyield.com), visible in the newly attached screenshot (@import url('https://fonts.googleapis.com/css?family=Arimo');). After removing it the page renders properly.

Currently we restored the import statement and the issue is reproducible again on our side, if you wish to test it again.
If you are still not able to reproduce it and don't intend to investigate further, please close this ticket as we have a valid workaround now.

Deleted: screenshot_dynamic_css_import.png 159 KB

	screenshot_dynamic_css_import.png 159 KB View Download

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

We've seen a whole lot of these reports; see also https://bugs.chromium.org/p/chromium/issues/detail?id=900660. The most actionable was one that required #network-service to be enabled. So I'm still wondering if that's a field trial causing only some users to see problems. But on that bug above it seems that the network service angle might only be causing the issue due to faster loads.

Note from comment #5 that the files from px.dynamicyield.com are not the issue, it's the CSS fonts coming from 'https://fonts.googleapis.com/css?family=Arimo'

Maybe an issue with dynamically added CSS?

It may also be a bug with the change to paint before below-the-body-css is loaded. Maybe we never continue painting when more CSS comes in added by script.

We need to get to the bottom of this.

We removed the dynamically added css import from the original url (https://fabled.com/christmas/gifts/limited-edition) as this is production site. 

However, we created separate page with the import included where the issue still can be reproduced: https://fabled.com/chrome-issue-902237

If it started happening in M69, it could be related to CSSInBodyDoesNotBlockPaint being enabled in M69. Could you check if running Chrome with this argument make the problem go away?:

--disable-blink-features=CSSInBodyDoesNotBlockPaint

Tried it myself. I can reproduce the problem with https://fabled.com/chrome-issue-902237 in incognito. The problem goes away with --disable-blink-features=CSSInBodyDoesNotBlockPaint

Even i see consistent repro on OS X and goes away with --disable-blink-features=CSSInBodyDoesNotBlockPaint

Good Build# 68.0.3440.106
Bad Build# 69.0.3497.81

Some reason, per-revision bisect is not working for this range. Here is the wider change log incase if it helps.
https://chromium.googlesource.com/chromium/src/+log/68.0.3440.0..69.0.3497.0?pretty=fuller&n=10000

@marcin.grzywa: could you read through this markdown document, focusing on the "Blink (after launch)" part? We made an intentional change to rationalize loading, that does change semantics slightly in certain cases involving document.write.

https://github.com/chrishtr/rendering/blob/master/stylesheet-loading-behavior.md#blink-after-launch

The CSSInBodyDoesNotBlockPaint feature changes behavior so that the HTML parser stops when encountering a
<style> tag that is encountered after the first <body> This means that if you use document.write during
page load to insert content that includes a style sheet, and then try to synchronously read back DOM elements from the document.write-written content that come after the style sheet, there will be an error because those elements will not be present yet.

Is that what happened in your case? Would you mind sending me the code snippet which does dynamic CSS insertion,
or describing how it works so I can verify?

@chrishtr the exact code that does the injection is unknown to me as it comes from an external script. I've asked DynamicYield support to advise.

However, I'm not sure it's the case you described as css injection happens both in working and non-working versions - the only difference between them is that the non-working version has additional @import in injected style.
The injected node is a div inserted into body by a script referenced in head. The div structure is as follows:
<div>
  <div>
    <style type="text/css">
      <!-- @import url('https://fonts.googleapis.com/css?family=Arimo');  -- only in non-working version -->
      #skinny-banner {
       ...
      }
      ...
    </style>
    <div id="skinny-banner">...</div>
  </div>
</div>  

I suspect there should be no code that tries to synchronously read back the injected DOM elements that come after the style sheet, but I cannot be sure.
If that's the case, I would search for the issue in the treatment of @import statements injected dynamically in body.

For reference:
- 'working' version - without @import: https://fabled.com/christmas/gifts/limited-edition
- 'non-working' version - with @import url('https://fonts.googleapis.com/css?family=Arimo'): https://fabled.com/chrome-issue-902237 

I also prepared two additional versions to take @font-face out of the question (inlined css with @font-face is ok, @import to a very simple css sheet is not):
- 'working' version - with font Arimo css inlined: https://fabled.com/chrome-issue-b-902237 
- 'non-working' version - with @import url('https://fabled.com/static/chromeTest.css'): https://fabled.com/chrome-issue-c-902237 

Please let me know if I can provide any additional test cases for you (under additional links).

I am pretty sure it is the case described. However, the main difference for you would
be whether the CSS injection happens via document.write or imperative DOM APIs.

If it is the former then the browser code is likely working-as-intended and you
need to not synchronously look for DOM nodes inserted by the parser after a
style tag with external references. If it is the latter then it may be a duplicate
of  issue 904966 .

I'm trying to reproduce by loading https://fabled.com/chrome-issue-902237
in incognito windows w/Chrome 70, but not succeeding. Can anyone still reproduce?

No, tried both 70.0.3538.110 and ToT.

I also cannot reproduce it on 70.0.3538.110.

As for the CSS insertion mechanism we got following response:
1. We create a tag of '<style rel="stylesheet">'
2. In the tag, we insert the CSS code of the entity
3. We then insert the tag in the body section of the HTML.

Anyway, as this is no longer reproducible feel free to close it, thanks for your help.

Confirmed the code inserting CSS code was using document.write.

Thank you for confirming that it uses document.write. document.write invokes the HTML
parser, and also means that any bug that was here is not a dup of 904966. Please
open a new bug if you see additional issues.

Still reproducable in Chrome 70.0.3538.110.
Fixes by removing @import "https://fonts.googleapis.com/css?family=..." from the <style> section.
In our case it's a advertise which including dynamicaly by js (style tag with @import also inserts by js)

Re comment 24: please provide reproduction steps.

The NextAction date has arrived: 2018-12-04

Without a way to reproduce the issue I'm afraid there isn't much we can do. The previous reproduction steps no longer reproduce the issue and we've had reports of the issue having been resolved.

If it still reproduces for you please provide version number and steps needed or URL, thanks!

I was able to reproduce it again on 71.0.3578.80 (Windows 10) - https://fabled.com/chrome-issue-902237 and https://fabled.com/chrome-issue-c-902237

The NextAction date has arrived: 2018-12-11

I can reproduce now. Disabling the flag does fix the issue. In the cases where
there is a failure, there is *not* a call to document.write. document.write
does happen, but only in cases where there is not a failure.

I think I know what is happening:

0. Inline script runs, which schedules a task, via setTimeout, to add a stylesheet with an external
resource.
1. Parser runs, adding some tags to the DOM.
2. Parser decides to yield (based on a scheduling heuristic), and schedules a task to resume.
3. Script task from 0 runs.
4. Scheduled task from #2 runs. This runs the "ResumeParsingAfterPause" logic in HTMLDocumentParser
instead of "ResumeParsingAfterYield".

The difference between ResumeParsingAfterPause and ResumeParsingAfterYield is that
the code assumes that ResumeParsingAfterPause only happens after pausing due to a
parser-encountered style or script tag, and has a last_chunk_before_pause_ state of parsing set.
If there is no last_chunk_before_pause_ then it gives up. and parsing never recovers.

The reason for the code involving setting last_chunk_before_pause_ is that pausing may
be necessary in the middle of a token chunk, which requires setting up some state to recover and
re-start in the middle of that chunk.

In the situation leading to this bug, that isn't needed. It's ok to simply call PumpPendingSpeculations()
again to find a new chunk to start parsing.

The problems above have what looks like a one-line fix. Another way to fix is to resolve this TODO in
HTMLDocumentParser::ValidateSpeculations:

// TODO(kouhei): We should simplify codepath here by disallowing
  // ValidateSpeculations

See also

https://bugs.chromium.org/p/chromium/issues/detail?id=904966#c12

for why we need to consider script-inserted style sheets as "parser blocking".

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

commit 73ba5348b74cffc022fe8cb77a1f05d9e20c3b66
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Fri Jan 11 19:42:33 2019

[HTMLParser] Always start pumping new chunks after unpausing.

Pauses may happen while the parser has already yielded, and in
particular when a script-inserted style sheet appears that has
an external resource.

The failure mode before this patch was:
1. Yield & schedule unyield
2. Script task runs
3. Script task inserts stylesheet with external resource
4. Resource finished
5. ResumeParsingAfterPause called, but there is no last_chunk_before_pause_
because there was a yield, not a pause.

Bug:902237

Change-Id: Id65c721fc193ecec7190e6b466a6794b65ea6acc
Reviewed-on: https://chromium-review.googlesource.com/c/1389502
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622099}
[modify] https://crrev.com/73ba5348b74cffc022fe8cb77a1f05d9e20c3b66/third_party/blink/renderer/core/html/parser/html_document_parser.cc