providing Findit results for internal purpose:
Suspected CLs	Findit could not find any suspected CLs.

Suspected Project: chromium

using codesearch, seeing some changes to 'DocumentLoader.cpp' in 

dcheng @, Could you please check the above issue & help us in finding an owner it its not yours.
https://chromium.googlesource.com/chromium/src/+/19ad54cb204cde45db95e773c5d54b04b2f178d4

I'm not really sure what's going on here. +kouhei@, any thoughts? I guess the PluginDocumentParser pointer is null, but I'm not sure how we would get to this point without crashing: I would have expected it to crash when calling needsDecoder().

Could the document be detached? toPluginDocument(document()) may be returning nullptr.

Issue 636386 has been merged into this issue.

After looking through the regression range I mildly suspect
https://codereview.chromium.org/2154233003 - Rewrite YouTube Flash embeds.

dcheng, do you think this could be a suspect? I'm not familiar with our plugin infrastructure but I'm worried there could be some weird interactions here.

redoing the regression range to see if we can get something tighter. The current range is:
https://chromium.googlesource.com/chromium/src/+log/5bc62a8764ac6b005c185526f58ed82b39413268..e1f4cec887a02280f984810ef9588a65d1d3fce0?pretty=fuller

Also note that the clusterfuzz repro config runs chrome with
--ppapi-flash-path=%APP_DIR%\flash\pepflashplayer.dll

Not sure if that's really proof of anything, but I thought it was relevant given #5.

Oh, also all the URLs in issue 636386 initiate downloads of Shockwave Flash file (application/vnd.adobe.flash.movie). I couldn't repro the crash there though.

also ccing mlamouri to see if the flash CL caused this.

FWIW, I couldn't reproduce the issue locally with or without asan/lsan enabled. Though I didn't try on a Windows machine.

I would be surprised if the "Rewrite YouTube Flash embeds" is the cause because it's not platform specific and should only have an impact for YouTube Flash embeds.

Yeah I couldn't repro on linux w/ asan and I don't have a windows box handy. Thanks for taking a look.

Do you mind taking also looking at the urls in some of the crash reports? I did notice devtools emitted the warning:
Resource interpreted as Document but transferred with MIME type application/x-shockwave-flash: "https://www.youtube.com/v/<URL>

when I navigated to them on TOT (#411043)

Adding labels from the duped bug and moving kouhei to cc. Chatted with mlamouri offline and conclusion is the rewrite CL is suspicious but we aren't sure of root cause.

Users experienced this crash on the following builds:

Win Canary 54.0.2825.0 -  9.98 CPM, 41 reports, 15 clients (signature blink::PluginDocumentParser::appendBytes)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

A co-worker was able to repro this running current canary on Windows 7 by navigating to:
http://www.game-debate.com/games/index.php?g_id=907&game=Medal%20of%20Honor

Woohoo! Kinda. Unfortunately I don't have a windows machine (yet!) to debug this on. So it would great to have some help here by folks w/ windows.

I'm nervous the flash rewriting is not the root cause. I wonder can we bisect?

In doubt, I sent a CL to disable the Flash rewrite: https://codereview.chromium.org/2230423002

Being able to try locally would be great. I will find the Windows machine we have in London tomorrow if the youtube flash rewrite is still the main culprit.

I will assign this to myself. I have a theory: some pages create an <iframe> with a YouTube *Flash* embed. This behaviour seems semi-broken on Linux (file download). We have code to actually create a PluginDocument for some supported plugins. When we do this, we hand craft a document with an <embed> which would point to the YouTube Flash version and the feature will kick in and rewrite it to HTML. Unfortunately, the PluginDocument really expects to get a plugin and that doesn't happen.

I think the two ways to fix this is to add an override before trying to create a PluginDocument so we create a HTMLDocument instead or we disable the override if inside a PluginDocument. The latter is easier to do but the former might be more interesting for users.

I've sent a real fix for review. It seems to resolve the issue. Also, the reason why we couldn't reproduce locally is because it only happen with official builds. I was able to reproduce when building an official build with asan enabled.

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

commit 8ec7d278c86fbf5194eb5acabbe6e3dab88777f1
Author: mlamouri <mlamouri@chromium.org>
Date: Fri Aug 12 11:47:09 2016

Do not try to use an HTML embed instead of a Flash one inside a PluginDocument.

The PluginDocument is written in a way that expects to get a plugin
inside the created <embed>. If we want to handle this case, we would
have to either make this relationship less strict or prevent the
creation of the document when we know a rewrite will happen.

BUG= 636226 
TEST=cluster-fuzz

Review-Url: https://codereview.chromium.org/2238983002
Cr-Commit-Position: refs/heads/master@{#411598}

[modify] https://crrev.com/8ec7d278c86fbf5194eb5acabbe6e3dab88777f1/third_party/WebKit/Source/core/html/HTMLEmbedElement.cpp
[modify] https://crrev.com/8ec7d278c86fbf5194eb5acabbe6e3dab88777f1/third_party/WebKit/Source/core/html/PluginDocument.cpp

This should have been fixed.

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

commit cbed5d5488c6b659aee576611b0e21efc29a0dce
Author: mlamouri <mlamouri@chromium.org>
Date: Fri Aug 19 13:13:03 2016

Reject play promises when the playback reaches the end.

This is implementing a recent change in the HTML specification.

BUG= 636226 
TEST=fuzzer
R=foolip@chromium.org

Review-Url: https://codereview.chromium.org/2237503002
Cr-Commit-Position: refs/heads/master@{#413122}

[modify] https://crrev.com/cbed5d5488c6b659aee576611b0e21efc29a0dce/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp

Hmm, I linked to the wrong bug, ignore comment 22.

For future reference (if someone is looking for the bug related to comment 22 from blame, it's  bug 636228 )

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

commit 3fa2f0b980f25c83408ff33a6d2f97ed628ff8bf
Author: mlamouri <mlamouri@chromium.org>
Date: Mon Aug 22 22:48:45 2016

Allow rewriting of Flash embeds in PluginDocument.

This is writing a real fix for the crash that was caused instead of
avoididng rewriting embeds inside a PluginDocument.

BUG= 636226 
TEST=fuzzer

Review-Url: https://codereview.chromium.org/2262053002
Cr-Commit-Position: refs/heads/master@{#413564}

[modify] https://crrev.com/3fa2f0b980f25c83408ff33a6d2f97ed628ff8bf/third_party/WebKit/Source/core/html/HTMLEmbedElement.cpp
[modify] https://crrev.com/3fa2f0b980f25c83408ff33a6d2f97ed628ff8bf/third_party/WebKit/Source/core/html/PluginDocument.cpp

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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