I can absolutely confirm this bug.  I have it on 3 PC's just today alone.  It worked fine yesterday before we got the update.  Additionally I would like to point out that this has happened previously(about 1 month ago) when another update was performed.  At that time I was able to remove and reinstall chrome and it fixed it(I had to completely remove the folders/directories and registry entries but it did fix it).  This time however it is not working that way.  It continues to be an issue.

The issue is that when you first login to OWA the message is ok but if you change to another email it blinks the message but does not show it in the preview pane.
It mainly affects the inbox as other folders sometimes(emphasize sometimes) do not have this same problem.
It worked previously.
Please contact me anytime and I can show you the problem.  
How long will it take you to resolve as I now have an entire staff of computers that cannot access their email properly any more?  I need to develop a solution by tomorrow morning (9/8/2017) and it is 5:30pm EST right now.

I'd like to add, we're are no longer able to access any of the OWA settings as well. 

Switching to +Enterprise

vmtech1976@ or poolpakintl@ can you please provide below details :

1. Were there any errors in JS console if so please let us know what are the errors 
2. If possible can you please provide "chrome://net-internal" logs.


Matt by any chance do we have Outlook Web app to see this is reproducible or not.

I know when I. Inspected the elements, i did see JS errors. I'll attach them in the morning. 

We will triage this an update.

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

Able to reproduce the issue on the latest canary(63.0.3208.0) and the latest stable(61.0.3163.79) on Windows-10, Mac OS 10.12.6 and Linux Ubuntu 14.04. Email preview works fine but issue is seen under Options menu.Options menu items - account,organize email,groups,site mailboxes,settings,phone,block or allow,apps doesn't render at all. I was able to reproduce this on Tech-Mahindra email portal which uses OWA.

This is a regression issue broken in M-61.

Last good build: 61.0.3118.0
First bad build: 61.0.3119.0

Changelog:
https://chromium.googlesource.com/chromium/src/+log/4a05a88fc69524f811fc574a006f07d976bacd3f..021a340142453876a5a7ab92e90295cb176163ee

Seems to be V8 related:

https://chromium.googlesource.com/v8/v8/+log/dcf65ba2..a8a39548

Suspecting: https://chromium-review.googlesource.com/c/v8/v8/+/535474. Since email to author bounced, assigning to marja@ for further investigation of this.

Note: This looks similar to  Issue 724028  duped into  Issue 724166 .  Issue 724166  was fixed by reverting the CL https://chromium-review.googlesource.com/c/v8/v8/+/501789 and this issue probably re-appeared due to reland in https://chromium-review.googlesource.com/c/v8/v8/+/535474

Does this bug reproduce with --js-flags=--no-script-streaming ?

Can you send more detailed repro instructions, i.e., where to navigate to etc.?

The repro URL(https://hydowa.techmahindra.com/owa/) is company Email portal so would not be possible to share the password here. 

This issue is resolved when launched chrome with --js-flags=--no-script-streaming. Attached is the screen-cast of the same. 

Deleted: 763106.mp4 2.2 MB

	763106.mp4 2.2 MB View Download

Update: Working on this. Cannot repro without credentials.

A panic move to turn off script streaming altogether is prepared here: https://chromium-review.googlesource.com/c/chromium/src/+/657103

ajha@ is able to repro this, remote-debugging this with him.

Simultaneously, investigating reverting the guilty commit but it's non-trivial, since it has been a while.

using the --js flag I'm still able to reproduce the issues on Version
61.0.3163.79 (Official Build) (64-bit)
Please see attached file OWA 2010, Exchange 2010 SP3 update 18, which is
the latest version released on 7/2017.
when looking at the elements I see the following error when loading OWA
options page.
microsoftajax.js:5 Uncaught SyntaxError: Unexpected identifier
    at microsoftajax.js:5
microsoftajax.js:5 Uncaught SyntaxError: Unexpected identifier
    at common.js:1
js.axd:5 Uncaught TypeError: Cannot read property 'notifyScriptLoaded' of
undefined
    at js.axd:5
mail.herricks.org/:136 Uncaught TypeError: Cannot read property
'initialize' of undefined
    at mail/:136

The revert is non-trivial; I can come up with a commit that reverts the guilty one, but it won't apply cleanly to V8 6.1 branch.

The revert is here:

https://chromium-review.googlesource.com/657386

Current plan of action as discussed with marja@:

1.) Revert culprit on master
2.) Wait for Canary coverage
3.) cherry-pick to 6.1: This cherry-pick will not apply though which is ok.
4.) Reland on master with the fix: I think we still need access to the OWA application running in order to do this.

Confirmed.  Entire company affected.  Please fix!

I just recently switched everyone to Chrome, and boy am I hearing it from users (including VIPs).  Reverting to Firefox to get by.

This is a disaster.

The revert is in the CQ.

what does The revert is in the CQ mean?

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9f21cab8c80bb6bbdb926cf4e950626924446eec

commit 9f21cab8c80bb6bbdb926cf4e950626924446eec
Author: Marja Hölttä <marja@chromium.org>
Date: Fri Sep 08 13:36:04 2017

Revert "Reland#2 [parser] Refactor streaming scanner streams."

This reverts commit de9269f3c365d428d4547ec45c34e9a0851f6ba9.

Something's still wrong in the encoding handling (see bug).

Bug:  chromium:763106 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icd19dd42b84b9d090e191375a2942b9941110bcf
Reviewed-on: https://chromium-review.googlesource.com/657386
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47924}
[modify] https://crrev.com/9f21cab8c80bb6bbdb926cf4e950626924446eec/include/v8.h
[modify] https://crrev.com/9f21cab8c80bb6bbdb926cf4e950626924446eec/src/parsing/scanner-character-streams.cc
[modify] https://crrev.com/9f21cab8c80bb6bbdb926cf4e950626924446eec/test/cctest/parsing/test-scanner-streams.cc

That it's getting committed to the V8 repository. From there, V8 still needs to roll to Chromium repository. And then, Chromium needs to do a stable refresh release.

For quick help, use:

--js-flags=--no-script-streaming

when you launch Chrome *or* refresh the page. The problem should go away.

"For quick help, use:

--js-flags=--no-script-streaming

when you launch Chrome *or* refresh the page. The problem should go away."

I tried both.  It does not fix the problem with our OWA.

Switches did not seem to have any effect.

Refresh moves off the email not showing preview.  When you select the email again, preview does not show.

That is very concerning. Maybe there are several bugs here, and only one of them is what is identified by comment 9.

(A possible reason for the flags seemingly not having any effect is that if your chrome is already running - and it might be, on the background, even if you don't see any windows - that will open a new window in the existing session.)

61.0.3118.0 is supposedly the last known good version. Does that work for you?

(Can somebody knowledgeable paste a link to where to download it from?)

Folks affected by this please try to do the following:

1.) Kill all the chrome processes (also look in the task manager)
2.) Start Chrome with "chrome.exe --js-flags=--no-script-streaming"
3.) List what does not work as expected, list which Chrome version you are using

It would be great to have a screencast about this too! According to https://bugs.chromium.org/p/chromium/issues/detail?id=763106#c11 turning off script streaming seems to fix the problem.

again tried that that didn't work
Version 61.0.3163.79 (Official Build) (64-bit)

reading pane content disappears when you advance to the next message.
I am able to access the see all options, which i wasn't able to do before.
I think there are a few bugs we're dealing with.

here are some screen shots.
capture.jpg is when you first login to owa, which looks normal however when
you advance to the next email you see how the content disappears in
capture1.jpg

i can confirm that chromium 61.0.3118.0 works correctly with OWA.

We are using Chrome Version 61.0.3163.79 (Official Build) (64-bit)  Windows 10 Versions 1511 and 1703.

All Chrome processes killed.  Used recommended switches.  Still has problem.

It should be noted that the preview not showing issue is actually intermittent, but more likely to not show.

Thanks, that is interesting. I think we need a way to reproduce this on our computers to advance. Can you provide us with a test account or similar?

We cannot see the screenshots, they don't seem to be attached.

Looks like the issue described in comment 22 is something different and it sounds like it's not streaming-related. We'd need a bisect for that one. Can you file a separate bug for it?
- Does it persist / reappear after reloads?
- What are the known good / known bad versions?

(Sorry, still not able to help for real, because I don't have a test account.)

what is needed?  I can give temp access to OWA.

That would be extremely helpful, can you e-mail the credentials (of your test account / temporary account) to e.g., hablich@chromium.org, marja@chromium.org?

As the revert is already in, we (at least from V8 side) won't work on this on the weekend. But we'd need to eventually be able to repro so that we can reland the code which originally broke this.

Oops, meant comment 30 in the previous comment. For that one, we'd need a new bug report.

vmtech1976, for the problem you're reporting, we don't need any more information at the moment, only the test account so that we can repro ourselves.

I'll sent the info!
I did however find if I have the emails arranged by just date I can't see
the message in the reading pane.  if I check off "Conversation" I can see
the message.

Received the credentials, thanks!

The bug described in comment 36 is potentially something different.

Thanks everybody for your help and patience and providing the needed info for debugging this bug.

Looks like disabling plznavigate fixes this.

To clarify, disabling plznavigate without specifying --js-flags=--no-script-streaming fixes the preview pane.

I think we have multiple issues here: One plznavigate and one with script streamer. Will try to repro than split the issue.

jam et al: there are multiple issues listed in this bug - which one does disabling plznavigate fix?

What I was looking at was preview pane.

Ok, an update:

1.) Disabling PlzNavigate via about:flags fixes the preview and the options pane (both reported issues)
2.) Switching off ScriptStreamer and switching on PlzNavigate fixes the options dialog (the issue reproduced in #11)

So this seems primarily a problem with PlzNavigate although the bug in #11 might be something different. The revert for ScriptStreamer will for now get some Canary coverage and we will have a further look on Monday. Handing off to to PlzNavigate folks.

Disabling PlzNavigate via about:flags fixes the preview but not the
options pane for me.

Disabling PlzNavigate via about:flags seems to fix the preview pane for me.

Options pane works for me.  I had same problem with options as vmtech yesterday, but it started working again yesterday before changing anything.  I "clicked around" on the options page and refreshed/shift-refreshed, and it started to show the options screen.  I am not sure what to make of that. Cache?

Refreshing will indeed remedy the streaming-related bug. So comment 44 is the most accurate description, afaics.

For reporter/others seeing this: please star the bug so we know how many users are hitting this.

Thanks for giving us login access to your server, that was quite helpful to see the issue. At this point, it's not clear if it's a bug in Chrome vs a timing difference. We're still investigating and collecting more data.

I noticed that this OWA install is from 2010. Is it possible to upgrade to a more recent version? Another workaround might to disable browser-side-navigation in chrome://flags/#browser-side-navigation.

No it's not possible to upgrade our exchange server.

@vmtech1976@gmail.com, thanks for the quick response. Since it's not possible to upgrade, here's a workaround. Do you have access to the IIS server? If so, you can edit C:\inetpub\wwwroot\web.config (or whatever configuration file is used for the OWA site). The file should already have a section like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
.
.
.
    </system.webServer>
</configuration>

There's probably already stuff inside the "system.webServer" tag. If you add the text below in there, it will serve a 204 for a specific url which would mask this problem.

        <rewrite>
            <rules>
                <rule name="OWAFix" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{URL}" matchType="Pattern" pattern="*owa/14.3.361.1/scripts/premium/blank.htm" ignoreCase="true" negate="false" />
                    </conditions>
                    <action type="CustomResponse" statusCode="204" />
                </rule>
            </rules>
        </rewrite>

If you can test this and let us know, that would be appreciated, thanks.

I'll give it a try, so there is no way to correct this? I'm sure I'm not
the only exchange 2010 environment out there.

@vmtech1976@gmail.com: we're still investigating the exact issue and then we'll look to see what the fix, if any, is.

@clamy @nasko and other chrome devs:
-it looks like the issue is that a frame is navigated to blank.htm, and then an xhr response comes back (probably the message data) and the navigation is cancelled. However when this breaks, the abortnaviggation IPC is received in the browser after it had already received the navigation response body and told the renderer to commit.

FYI another workaround is to check "Use the light version of Outlook Web App" option.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/a3938162b01c5a7411503729b4998a9ec697daf3

commit a3938162b01c5a7411503729b4998a9ec697daf3
Author: Marja Hölttä <marja@chromium.org>
Date: Mon Sep 11 11:14:22 2017

Revert "Reland#2 [parser] Refactor streaming scanner streams."

This reverts commit de9269f3c365d428d4547ec45c34e9a0851f6ba9.

Something's still wrong in the encoding handling (see bug).

(Merging https://chromium-review.googlesource.com/657386 to the
6.1 release branch manually.)

NOTRY=true
NOPRESUBMIT=true

Bug:  chromium:763106 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic97d13a13ec70be698540741cda2dd49b18c2ec3
Reviewed-on: https://chromium-review.googlesource.com/659998
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.1@{#72}
Cr-Branched-From: 1bf2e10ddb194d4c2871a87a4732613419de892d-refs/heads/6.1.534@{#1}
Cr-Branched-From: e825c4318eb2065ffdf9044aa6a5278635c36427-refs/heads/master@{#46746}
[modify] https://crrev.com/a3938162b01c5a7411503729b4998a9ec697daf3/include/v8.h
[modify] https://crrev.com/a3938162b01c5a7411503729b4998a9ec697daf3/src/parsing/scanner-character-streams.cc
[modify] https://crrev.com/a3938162b01c5a7411503729b4998a9ec697daf3/test/cctest/parsing/test-scanner-streams.cc

FYI the merge in #55 for 61 and the upcoming for 62 for the scriptstreamer only helps for part of the problem. The bug is still not resolved regarding PlzNavigate

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/20a63a25f8c569b605228e97968f1ed869e78c25

commit 20a63a25f8c569b605228e97968f1ed869e78c25
Author: Marja Hölttä <marja@chromium.org>
Date: Mon Sep 11 11:35:44 2017

Merged: Revert "Reland#2 [parser] Refactor streaming scanner streams."

Revision: 9f21cab8c80bb6bbdb926cf4e950626924446eec

BUG= chromium:763106 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=hablich@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id58953347989fef227f3a91b9cce042b1b2a682e
Reviewed-on: https://chromium-review.googlesource.com/659800
Reviewed-by: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.2@{#9}
Cr-Branched-From: efa2ac4129d30c7c72e84c16af3d20b44829f990-refs/heads/6.2.414@{#1}
Cr-Branched-From: a861ebb762a60bf5cc2a274faee3620abfb06311-refs/heads/master@{#47693}
[modify] https://crrev.com/20a63a25f8c569b605228e97968f1ed869e78c25/include/v8.h
[modify] https://crrev.com/20a63a25f8c569b605228e97968f1ed869e78c25/src/parsing/scanner-character-streams.cc
[modify] https://crrev.com/20a63a25f8c569b605228e97968f1ed869e78c25/test/cctest/parsing/test-scanner-streams.cc

Is there anyway to disable PlzNavigate via the chrome ADMX GPO?

I'm able to repro the Options failure at last. The way to bypass the "only light version available" is to use an user agent changer extension, e.g., https://chrome.google.com/webstore/detail/user-agent-switcher-for-g/ffhkkpnppgnfaobgihpdblnhmmbodake , and select e.g., "Firefox on Mac". (For some reason, selecting IE is not a good idea.)

I was able to repro that reverting the suspected commit indeed fixes the options pane. (<- This confirms ajha@'s analysis.)

-------------


An interesting finding:

https://mail.herricks.org/ecp/14.3.361.1/Scripts/microsoftajax.js begins with two BOMs right after each other.

Maybe handling two BOMs is a relevant difference between our previous and current UTF-8 decoding. Maybe it's something else. More debugging needed.

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

commit 69b2a240b29809604dc859c8a41eb4f920deccfa
Author: John Abd-El-Malek <jam@chromium.org>
Date: Mon Sep 11 19:27:52 2017

Fix renderer-initiated navigations committing even though they were aborted with PlzNavigate.

If the response came back quickly, the browser would send the commit message to the renderer and 
the abort would be ignored. To fix this, keep track of last renderer-initiated URL and also reset
the pending-navigation bit when it's aborted.

Bug= 763106 

Change-Id: I50430183667ac244b04e69a958cece07807f97f1
Reviewed-on: https://chromium-review.googlesource.com/658399
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500995}
[modify] https://crrev.com/69b2a240b29809604dc859c8a41eb4f920deccfa/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[modify] https://crrev.com/69b2a240b29809604dc859c8a41eb4f920deccfa/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/69b2a240b29809604dc859c8a41eb4f920deccfa/content/renderer/render_frame_impl.h

Confirming that Issue on the Options page related to script-streaming is resolved due to the revert of the suspected CL:https://chromium-review.googlesource.com/c/v8/v8/+/657386. Tested on the latest canary version: 63.0.3213.0 on Windows-10, Mac OS 10.12.6 and on 62.0.3212.0 of Linux Ubuntu 14.04.

I was unable to reproduce the PlzNavigate bit of this issue on Preview pane, hence unable to verify and confirm the fix.

vmtech1976@/pdlandis@: Could you check the Preview pane issue on the latest canary(https://www.google.com/chrome/browser/canary.html) with default PlzNavigate and confirm if this is resolved from your end as well.

Thanks in advance!


  

I just tried it, i'm still unable to see content in the reading pane. I can
however get to the options pane and navigate it which I couldn't before on
61.0.3163.79.

Make sure you have Conversations un-ticked when testing.  if you have the
messages grouped in Conversations the reading pane works.

If I manually disable PlzNavigate everything works as expected.

Requesting merge to m61 for r500995. This only affects PlzNavigate code path, and is a small cl to fix a race condition that's quite rare. If it causes issues with PlzNavigate, we will disable PlzNavigate. It's been on Canary for a day.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

@vmtech1976@gmail.com and  ajha@chromium.org, are you saying you can still see the preview bug with Chrome Canary version 63.0.3213.0? Please make sure you're using this version on Windows or Mac.

On Linux, 62.0.3212.0 is older and doesn't have the fix.

I just updated to 63.0.3213.0 both issues seem to be fixed.  sorry for the
disconnect.

Approving merge to M61 branch 3163 based on comment #66 and #69. Please merge ASAP. Thank you.

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

commit fbcca8ea1adac54b9e4c4dc63381994098f6c6ff
Author: John Abd-El-Malek <jam@chromium.org>
Date: Tue Sep 12 17:28:21 2017

Fix renderer-initiated navigations committing even though they were aborted with PlzNavigate.

If the response came back quickly, the browser would send the commit message to the renderer and
the abort would be ignored. To fix this, keep track of last renderer-initiated URL and also reset
the pending-navigation bit when it's aborted.

Bug= 763106 

TBR=jam@chromium.org

(cherry picked from commit 69b2a240b29809604dc859c8a41eb4f920deccfa)

Change-Id: I50430183667ac244b04e69a958cece07807f97f1
Reviewed-on: https://chromium-review.googlesource.com/658399
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#500995}
Bug: 
Reviewed-on: https://chromium-review.googlesource.com/663821
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#1172}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/fbcca8ea1adac54b9e4c4dc63381994098f6c6ff/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/fbcca8ea1adac54b9e4c4dc63381994098f6c6ff/content/renderer/render_frame_impl.h

When do you think this fixed release will be released to a production
environment?

@vmtech1976@gmail.com: it will be in the next m61 release, probably within a week or so.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Approving change in #61 merge to M62 (branch:3202) 

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

commit e64a92a5b37c8ad5e57ecf9766a5818878b10b83
Author: John Abd-El-Malek <jam@chromium.org>
Date: Wed Sep 13 19:01:02 2017

Fix renderer-initiated navigations committing even though they were aborted with PlzNavigate.

If the response came back quickly, the browser would send the commit message to the renderer and
the abort would be ignored. To fix this, keep track of last renderer-initiated URL and also reset
the pending-navigation bit when it's aborted.

Bug= 763106 

TBR=jam@chromium.org

(cherry picked from commit 69b2a240b29809604dc859c8a41eb4f920deccfa)

Change-Id: I50430183667ac244b04e69a958cece07807f97f1
Reviewed-on: https://chromium-review.googlesource.com/658399
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#500995}
Bug: 
Reviewed-on: https://chromium-review.googlesource.com/665342
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#206}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/e64a92a5b37c8ad5e57ecf9766a5818878b10b83/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[modify] https://crrev.com/e64a92a5b37c8ad5e57ecf9766a5818878b10b83/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/e64a92a5b37c8ad5e57ecf9766a5818878b10b83/content/renderer/render_frame_impl.h

Verified the 'Options blank page' bit of this issue on 61.0.3163.91, Windows-10, Mac OS 10.12.6 and Linux Ubuntu 14.04. This is working as intended and Issue is resolved.

I was unable to repro the 'Preview bit of this bug' but that issue also seems to be resolved as per C#69 on canary by the CL(https://chromium-review.googlesource.com/c/chromium/src/+/658399). Same CL has been merged to M-61/M-62 branch, which should also fix the Preview issue on M-61 and M-62.

Adding the verified label, therefore.

Thank you!

This patch is now pushing out to stable channel in version 61.0.3163.91 for Desktop (Win,Mac & Linux).

Thanks, works great!

Thank you for fixing the bug. Requesting postmortem for this please see go/chrome-postmortems for the process to follow.

@govind: postmortem sent, you're CC'd. Thanks for the reminder.

Can you cc me in the postmortem too so that I can write about the part caused by the streaming bug?