This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

mlamouri@, could you help triage this issue since you're the ower of HTMLMedia*?
Please feel free to re-assign. Thanks!

I can't reproduce this with the clusterfuzz tool because it's a mac issue. This said, it seems very similar to  bug 735139  without the WebAudio specific crash site. +dalecurtis@ in case of he can reproduce.

Hmm, yeah seems like a similar bug, but don't see any WebAudio construction in the test; though parts seem obfuscated so possibly something is still being generated.

In any case it looks like something is destructing WebMediaPlayerImpl before calling Wrap(nullptr)... but I don't see how that could happen since both of those calls happen in the same spot in the right order.

Per the asan trace (click expand lines below stack trace), this DCHECK should be failing:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp?sq=package:chromium&type=cs&l=1214

I.e. we already have an active WebMediaPlayerImpl instance at the time load is started. So it seems we're missing a step somewhere which should be tearing down the old WMP instance (or possibly not starting this new load). I'd guess this is the root cause, but my loading fu is too weak to know where we're missing that reset.

A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

I should have looked more closely to the test case earlier...

This is what it is doing (with some cleanups):
```
var audio = document.createElement('audio');
audio.src = findMediaFile('audio', 'content/test');
audio.onloadedmetadata = t.step_func(function() {
  internals.setMediaElementNetworkState(audio, 0); // <-- cause of the crash
  audio.play().then(() => { t.done(); });
});
```

The crash happens because the network state is manually reset to 0 after the element's metadata have been loaded. This isn't expected and on a debug build, actually hits DCHECKs. On a non-debug build, it will crash in different ways. However, it is not possible to reproduce this is another way than calling the internals methods and these are not shipped to standard Chromium builds and can't be called by users or web developers.

Therefore, marking this as WontFix.

Hmm, +inferno, we should stop ClusterFuzz from using any internal.* methods or, better, use builds which have this functionality disabled?

Mounir, is there a buildflag for disabling the internals methods?

It's not the first time I got a crash from ClusterFuzz with internal methods enabled and because you have to manually enabled them, I assume this is a design decision from the team.

ClusterFuzz testcase 6290579637141504 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

@infero, ping on c#9, c#10?

This is coming from generic dom fuzzer that needs to run on content shell and since many layouttests set state / enable features based on window.internals, we just cant get rid of it. If we want to disable for media stuff, we may need another build flag and can add those to builder, but can't disable window.internals altogether.

Hmm, do you have an example of a valid windows.internals usage? I guess I'm unfamiliar with how other code is using the internals methods, but in every case they're not accessible to the normal sites, so I'm having trouble seeing how they're useful to clusterfuzz and not just generating noise.

E.g. enabling features in accessibility on fly without needing command line flag (so like upcoming feature) - https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/accessibility/aom-int-properties.html?rcl=b54ae33872700a909e2e20990a25f6ccad2f0174&l=16

or even better testing of features using internal api
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/accessibility/aom-int-properties.html?rcl=b54ae33872700a909e2e20990a25f6ccad2f0174&l=24

Hmm, runTime flags makes sense, so maybe we should separate that out from methods which are invoking test-only behavior? Or are there valid uses of the internals.method() type calls too?

there are other useful things too like page zoom levels setting, etc

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/dom/window-scroll-scaling.html?rcl=2257878a0dfb81bbbc37613752865983568580af&l=27

Ah, thanks for the context, seems we can't nuke it entirely then. Seems like we should nuke the media ones somehow though. Does CF have a blacklist for methods? Or is it as you suggest that we should have a build flag for them?

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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