Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 70.0.3538.77 and on the latest canary 72.0.3601.0 using Ubuntu 14.04, Windows 10 and Mac 10.13.1

Bisect Information:
-------------------
Good Build: 70.0.3508.0
Bad Build:  70.0.3509.0

Providing the changelog from Omahaproxy as we are getting runtime error while running per-revision bisect, neither chromium bisect helped. I.e., all the invoked builds couldn't play the video and we didn't observe the error mentioned in c#0 in console.

https://chromium.googlesource.com/chromium/src/+log/70.0.3508.0..70.0.3509.0?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/bb1ff6ae23813a01f053dbc64ccf032b8a4c4025
Review URL: https://chromium-review.googlesource.com/1152690

@Jiajia Qin: Please help us in assigning it to the right owner if this isn't related to your change. Adding RBS as this seems to be a recent regression please change/remove if not required.

Remove me from the owner. It's not possible that my change causes this regression. My change is only to add a new API 'bindImageTexture' for webgl2-compute context which is behind a flag. If the test case doesn't use 'webgl2-compute' context and call 'bindImageTexture' explicitly, it's not possible to enter my code path. In addition, bindImageTexture won't affect texImage2D and this feature is not available on Mac.

We need a per-revision bisect for this issue.

Faced the issue with per revision bisect on Mac but worked fine on linux, hence updating the result from there.

You are probably looking for a change made after 579252 (known good), but no later than 579253 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/3860ee78d5dcee57cc223582d766976d60e6c885..7a7c46db9c1c9e5b557d73b71af515e2188e956e
Suspecting: https://chromium.googlesource.com/chromium/src/+/7a7c46db9c1c9e5b557d73b71af515e2188e956e
Review URL: https://chromium-review.googlesource.com/1150695

@Nate Chapin: Please help in assigning it to the right owner if this isn't related to your change.

Thanks!

M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

When I run this on stable (m70), I see the failure described in the bug report. However, when I try to run this on m72, I get 2 console errors.

One during page load that just says "steamx.min.js:1 An error happened."

The other after clicking start:
steamx.min.js:1 Uncaught TypeError: Cannot read property 'image' of null
    at Stage.play (steamx.min.js:1)
    at Player.play (steamx.min.js:1)
    at Player.onVideoPlayButtonClick (steamx.min.js:1)


...it's unclear to me why there's a different across versions.

It looks like that's associated with the code used to load the video file, so it's possible there's a bug in my code there that I haven't found yet.

Is m72 the same version as Chrome unstable? I'm on Fedora Linux, I could take a look on my end and see if it's related to my code or not.

I cannot reproduce @Japhet's result on Firefox. Chrome unstable (v 	72.0.3602.2) still shows original bug. Can test more if I can download the m72 build @Japhet is referencing.

@aaron, would you mind trying reproducing with a very recent build from our continuous builders? This one should do (for Linux):

https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F606633%2Fchrome-linux.zip?generation=1541718161394139&alt=media

I'm surprised to see a behavior difference between 72.0.3602.2 and our continuous builders, given that 72.0.3602.2 is only a couple days old. I'm wondering if I've got a configuration problem of my own...

I'm not sure if it's related but, I landed a fix for a similar CORS/media  issue 901383  - https://crrev.com/657a055a66492e996b296d7bb999e3c8551eed23 this morning. But that issue appeared at 71, not 70.

I can reproduce the issue with stable (Windows). I cannot reproduce the issue with 72.0.3606.0 (Windows). double-check will be appreciated.

I'm able to reproduce @Japhet's issue on the continuous build. It doesn't seem to be an issue in the JS code though, but more an issue with the browser loading the video at all. If you look in the Network tab and click through the JW player generated link, it can't load it in the browser either.

It could also be an issue on JW's end, but it's odd that this particular problem is only on the continuous build and not in my stable or unstable builds from Fedora's repos.

Sigh. The failures I described in Comment #12 are specific to chromium (i.e., non-Chrome-branded) builds, because ffmpeg is configured differently. Building locally with the GN arg:
ffmpeg_branding = "Chrome"
...fixed that issue.

I verified that yhirano's fix (https://crrev.com/657a055a66492e996b296d7bb999e3c8551eed23) also resolves the original report in this issue, so marking this as a duplicate of 901383.

Thank you japhet@ for getting to the bottom of this.

Submitter: the fix for this is being aimed at Chrome 71. We're sorry that Chrome 70 will remain broken, but merges back to Chrome's stable branch carry risk, and are reserved for only extremely urgent fixes like security bugs. Please test your site with Chrome Beta (and, ideally, Chrome Canary) on a regular basis and file bugs if you see them - feel free to email me the bug IDs so we can ensure they get triaged more quickly. Thank you.

Thanks for all the help figuring this one out! I'll be sure to test on Chrome Beta more often. When is 71 slated for release?

 Issue 902569  has been merged into this issue.