Seems to be reported on chromium build, Tested this on Mac OS 10.13.6 on the latest chromium build '71.0.3552.0 (Developer Build) (64-bit)' and this seems to be working fine. Presenter notes loaded fine. Attaching the screenshot of the same.

kain.centeno@: Could you please confirm if this is still an issue on the latest M-71 and also if this happens with any specific slides.

Deleted: 882920.png 585 KB

	882920.png 585 KB View Download

@ajha: the latest developer build fixes the issues with my personal gmail account but my company account is still having issues with it. I did notice that after clicking on the "i" button i get some information.

I'm going to go ahead and create a ticket for google support.

This issue is not seing if reverting to version 68 on Chrome.

Deleted: Screen Shot 2018-09-13 at 5.22.33 PM.png 167 KB

	Screen Shot 2018-09-13 at 5.22.33 PM.png 167 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

Hey all,

We have some reports of this on the Docs community:
- https://support.google.com/docs/forum/AAAABuH1jm0r60Yht4pa20

Thanks!

An enterprise customer has reported a very similar case details below.
Chrome version: 
-69.0.3497.100 (Official Build) 
-70.0.3538.16 (Official Build) beta

OS version: Windows 10 Pro (10.0.17134 Build 17134)
Case#:16957055

Steps to reproduce: 
1.Open Google Slide.
2.Click “Start presentation” to start.
3.Select “Open speaker notes” or “Q &A”
4.A blank screen appears. 
Please refer video file for the repro steps.
https://drive.google.com/open?id=1mBJ5vqoxzCAwV1lTxCue8h4Jjehyrtvm

Current Behavior: 
 “Open speaker notes” and “Q & A” windows open with blank.

Expected Behavior: 
 “Open speaker notes” and “Q & A” windows should open with contents.

I’ve tested listed below devices, but I couldn’t reproduce the same behavior.
-Win10 64bit with Chrome Browser.
71.0.3555.0 (Official Build) canary 
-Mac OS with Chrome Browser 69.0.3497.100 (Official Build)
-Chrome OS 69.0.3497.95
The customer has reported that Chrome browser version 68 is working fine. 

Drive link to logs: 
.har file.
https://drive.google.com/open?id=1lYJNp-7XoQ3Vc7qOQfNIIXXRyEerPhwx

Screen shot of the console window.
https://drive.google.com/open?id=1p4sCWdFb8uVtf2L3veNm2Ttk6LA3ieOq

Please let me know if it is separate issue with the original case, otherwise I will create a new bug case.

Tried checking the issue on reported chrome version 71.0.3550.0 using Mac 10.3.1 with the below mentioned steps.
1. Launched Chrome
2. Opened Google Slides
3. Clicked on "+"/Blank slide to start a new presentation
4. Then clicked "Click to add speaker notes"
We have neither observed a blank window nor a window with content(s). Attaching the screencast of the same for reference.
Note: Similar behaviour is seen on M68(68.0.3440.106) too

@ryutas: Please have a look at the screencast and let us know if anything missed from our end. JFYI: None of the drive links provided in C#6 is accessible as we do not have permission to open. Any further inputs from your end may be helpful.

Thanks!

Deleted: 882920.mp4 2.5 MB

	882920.mp4 2.5 MB View Download

Hey all,

Here's another report from the Chrome community:
- https://productforums.google.com/forum/#!topic/chrome/jDabTclu8Dc

I also found some listnr reports:
- https://listnr.corp.google.com/report/85667582106
- https://listnr.corp.google.com/report/85666731471
- https://listnr.corp.google.com/report/85659702659
- https://listnr.corp.google.com/report/85657686481
- https://listnr.corp.google.com/report/85655335933
- https://listnr.corp.google.com/report/85655303267

A couple reports are from Windows, so adding that label as well.

Thanks!

Also tracking listnr reports on the Docs Editor end, and linking them to b/116159019. 

Hey all,

The Docs team has done some extensive testing, including a bisect.

Their results point to http://crrev.com/21154794b8ae44ef571979016fd64b1de23a7cb7

cc: pmeenan@ Would you be able to take a look? Details in b/116159019.

I was able to repro the issue consistently as per the slide example given in b/116159019 on the latest Mac canary 71.0.3557.0.

Assigning to pmeenan@ for inputs and adding RB-Stable for tracking. 

Emil, would you know how this bug should be routed?

Looks like this was caused by turning on the CSSInBodyDoesNotBlockPaint feature in http://crrev.com/562150 however the author of the feature has since left Google.

Could you please take a look at this Rune and see what our options are? The feature was turned on in May so turning it off might cause other things to break...

I am on an internal thread already with the Slides team about this bug. Will take
it. They are working on building a reduced testcase.

Also removing target-69 because slides has a workaround already.

Removing "M-69" per comment #18.

Turning it off shouldn't break anything but it would be unfortunate.   Issue 882287  looks pretty similar so if there's a root-cause issue that is causing the parser to pause but never resume it's much worse than the impact of turning it off.

That said, I'd much rather figure out what is going on and actually fix it.  My guess is that the parser is pausing because it thinks a body stylesheet is still pending and it doesn't resume when it should for some reason.

I'm not at Google anymore but I can still look at the issue but it has to be in my free time (had planned to take a run at it over the weekend but didn't get a chance).

If we can get a few failcases I'd recommend moving the feature back to experimental to stop the bleeding, fix the known failcases and then re-enable it.

The other option is to move to match Firefox's behavior instead of Edge's and not block the HTML parser while waiting for in-body stylesheets.  The Chrome code and logic would be a lot cleaner but the dev experience isn't as nice.

I've put together a reduced test case. When the attached file is opened in chrome 69, the element is initially not present, but becomes present after a timeout. When open in chrome 68, firefox, and safari, the element is available immediately after writing.

Deleted: repro.html 565 bytes

repro.html 565 bytes View Download

 Issue 888972  has been merged into this issue.

Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

[bulk edit] - This issue is marked as a stable blocker for M70. We are two weeks away from M70 Stable. Please take a look urgently!

Going to look at this soon.

The repro steps in #21 are working as intended. Chrome now blocks the HTML parser whenever
an external style sheet, or style sheet with @import, is encountered, *and* the <body> element has appeared.
Content before <body> does not block.

See:

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

Details:

The testcase uses document.write to insert content into the document that contains a style sheet with an external dependency via @import, then queries a DOM element declared within the document.write text that occurs *after* the style sheet. document.write acts like an additional source of parsing, and so
it inherits the same blocking behavior as the regular HTML parser during load (for example, it
will block on load/execution of external scripts as well).

Some additional background on why we made this change is in the link below. The short version is the
change:
* Makes Chrome loading predictable and understandable
* Significantly reduces code complexity in Blink rendering that tried to deal with the old heuristic behavior
* Supports a rational way of doing progressive rendering
* Aligns behavior with Edge (I verified this on the testcase just now)

https://github.com/chrishtr/rendering/blob/master/stylesheet-loading-behavior.md

It is true that this behavior does not align with Safari or Firefox. Safari has very similar behavior
to what Chrome used to have, with lots of hard to explain/nondeterministic behavior. Firefox has fully
async behavior and doesn't block on anything, which is rational but can lead to unavoidable "flash of unstyled content" during load.

Hello team, can we get any updates on this issue? 

A customer is still being affected by it, as you can see on the screencast attached.

Customer's Chrome version: 69.0.3497.100