Also encountered this issue, here's another (similar) test case:
http://storage2.interlude.fm.s3.amazonaws.com/dev_temp/tomer/chrome_play_promise_bug/index.html

mlamouri@: Can we get an update on this stable blocker issue. Appreciate your response!

Note: Issue is still reproducible on the latest canary(51.0.2686.0) on Mac OS 10.11.3.

@mlamouri:  Hey, would you mind providing an update on the above issue ?

This issue is still reproducible on latest canary version - 51.0.2692.0 on All-OS.

Appreciate your quick response, as this is mark with stable blocker label.

Thank you!

A friendly reminder that M50 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by Apr-5. All changes MUST be merged into the release branch by 5pm on Apr-8 to make into the desktop Stable final build cut. Thanks!

mlamouri@: Please review the blocker label and remove if this is not blocking for M-50.

Cc'ing hiroshige@ as well for more inputs.

Note: Issue is still reproducible on the latest canary(51.0.2698.0) on Windows-7.

M50 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on Apr-8 to make into the desktop Stable final build cut. Thanks!

I didn't realise this was marked as a stable blocker. I don't think it should be a stable blocker. The error doesn't block the playback, it simply reject the promise and has no other effect unless the website is using the returned promise.

Given that the feature is new (shipping in M50) and the bug is a edge case in the specification (filed an issue with a suggestion to fix https://github.com/whatwg/html/issues/996), I think it's fine to fix that in M51.

Not sure it's the same bug, but I'm seeing some other issues that might be related:

1. I sometimes get the following error: DOMException: The play() request was interrupted by a new load request.
However, I never call HTMLMediaElement's load() method (using MSE).

2. In Android Chrome Dev, with UMP enabled, I often get MEDIA_ERR_SRC_NOT_SUPPORTED exceptions.
I believe this only started happening when the play() promise was introduced.

Re 1, I believe this is the same issue.
Re 2, I believe the default support for various codecs like h264 has been removed from Chromium builds, although it's still should be there in the official release builds. Is it happening for you in Chrome Dev as in the app you install from Google Play Store? If so, could you provide an example and file a bug? I'm not sure it's relevant to the play() promise but could just be the new media pipeline issue.

For me as a developer, it feels a bit off shipping a known bug that is causing an exception that can't be caught.

Re comment 12: a "load request" doesn't mean that "load()" was called but that the load algorithm ran. It can run for a few different reasons.

Re comment 14: it is a minor bug knowing that it is an edge case (calling `pause(); play();`) and doesn't break current behaviour. At that point, we can fix the bug in the Beta branch just before the Stable cut (Friday) and take the risk of the fix creating worse regressions. The alternative is to send a fix to trunk and have it available in Beta (also cut on Friday) soon at which point, we should be able to fix any regression.

FWIW, I've open a spec issue:
https://github.com/whatwg/html/issues/996

I wrote a Blink patch:
https://codereview.chromium.org/1865933002

And I'm about to write a spec change.

Hi thanks for the detailed discussion, as this is affecting us at JW Player as well.
We can confirm that the browser works as expected in Chrome 49, but not in Chrome 50.

We are preparing to move about 1.6bn/month video streams from Flash to HTML5 and this issue is manifesting 
when trying to tear down and re-use the same video tag again. In this case, the "play" doesn't take
and the video tag remains paused.

The essential steps we are using are

    // video is playing back
    video.pause()
    video.removeAttribute('src');
    video.load()
    video.src = new MediaSource()
    video.play()
    // video's play promise hangs, tag is paused, until we pause (forcing the play request to be interrupted) and then play again

I can provide a test page if that is helpful, just let me know what email to send it to.

I think it's a slightly different issue. The play() promise isn't even affected by the previous pause() because load() and src reset will make the play promise resolve asynchronously.

I wonder if this could be MSE specific. I tried your example with src set to file and it is working fine: https://mounirlamouri.github.io/sandbox/bugs/593273.html

I think it would be very helpful if you could provide an example on which I can investigate.

Re 17: Re 18: This is not related to the above ticket, and has been resolved in our app.
Thank you,
Donato

Just to update, the original issue still persists on Canary 52.0.2710.0. on MAC 10.11.4. 

@mlamouri: Request you to please take a look into it.

Issue reproducible on mac 10.11 chrome version canary 52.0.2713.0 and dev 51.0.2704.19

@mlamouri: Gentle ping! Could you please take a look.

This is affecting us at KnowledgeCity Online Video training. Se have a page of  videos and when you scroll, it pauses any active video.  Now nothing is playing and the error is showing:

Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().

Notably, this only happens if we put "crossdomain" in the video tag so that the subtitles can be loaded cross domain

Just to update issue still seen on latest canary 52.0.2715.0.

 Issue 606966  has been merged into this issue.

This is breaking a lot of videos on the internet. Any sort of "play on hover" is impacted. 

I can't believe this bug made it to stable version. This is causing billions of console errors across the web. Practically anyone who's using the video tag has experienced the error. Looking forward to stable release with a fix to this. 

Thanks people, I appreciate your efforts, maybe this snippet can help you:

```
<script>
function onClick(){
  setTimeout(function(){
    var video = document.querySelector("#video")
    video.pause();
    video.play();
  },10)
};
</script>

<a href="#" onclick="onClick()"> Play here </a>

<video id="video" controls  src="http://www.sample-videos.com/video/mp4/240/big_buck_bunny_240p_2mb.mp4" />
```

I am having the same issue on 50.0.2661.94

We are having users report this same issue on our real estate video platform.

undefined:1 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()

For us, when a user seeks to a new time, the player throws this error and a large white rectangle appears over the video and locks up.

I have an Android mobile app using Cordova that hits this error. When it happens audio makes a popping sound and causes a secondary track to stop playing.

FWIW, none of the examples provided actually blocks the playback. Could someone provide a better example where playback actually fails because of the exception thrown? Thanks!

For me, it is just logging out the message but the playback continues fine.

Same here: the playback continues fine, but an error gets logged and this is worrying

Same issue that just started happening for me on Chrome v50 (Windows 10).

My HTML5 syntax:

        <video id="myvideo" preload autoplay loop muted width="100%">
            <source type="video/mp4" src="myvideo.mp4" />
            <source type="video/ogg" src="myvideo.ogg" />
            <source type="video/webm" src="myvideo.webm" />
        </video>
        <script type="text/javascript">document.getElementById('myvideo').play();</script>


Chrome console now renders the error and it's not happening in any other browser:
"Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()."

We are seeing the same error in our console logs, but we're also seeing playback impacted. We have audio files that are controlled with the player/controls, and whenever a user pauses or searches within the timeline, the whole file locks up and won't resume. We can't replicate using other browsers, and this issue wasn't present before the update to 50.

To give some update about this, I've updated the HTML spec to fix the race in there. I also have a fix in Blink that needs to be reviewed. It should most likely land in M53 and I will try to cherry-pick to M52.

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

commit 3a82d82079ca79cddd932eb77f924db5428885b9
Author: mlamouri <mlamouri@chromium.org>
Date: Tue Jun 07 21:25:33 2016

Fix race when HTMLMediaElement.play() is called just after pause().

The consequence is that the Promise returned by play() is rejected by
the task created by pause(). The fix is to associate the tasks with a
list of promises.

BUG= 593273 

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

[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/media-play-promise-expected.txt
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/media-play-promise.html
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/track/track-cues-pause-on-exit-expected.txt
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/video-controls-overlay-play-button-expected.txt
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/video-played-collapse-expected.txt
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/LayoutTests/media/video-played-ranges-1-expected.txt
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/3a82d82079ca79cddd932eb77f924db5428885b9/third_party/WebKit/Source/core/html/HTMLMediaElement.h

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Please merge your CL in to M52 branch asap so that it gets picked up for Beta promotion scheduled for next week. 

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

commit b62b49b650018c1367069a6c8e2a049e998fc4d9
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Fri Jun 10 10:34:20 2016

Fix race when HTMLMediaElement.play() is called just after pause().

The consequence is that the Promise returned by play() is rejected by
the task created by pause(). The fix is to associate the tasks with a
list of promises.

BUG= 593273 
TBR=avayvod@chromium.org

Review-Url: https://codereview.chromium.org/1865933002
Cr-Commit-Position: refs/heads/master@{#398370}
(cherry picked from commit 3a82d82079ca79cddd932eb77f924db5428885b9)

Review URL: https://codereview.chromium.org/2053333002 .

Cr-Commit-Position: refs/branch-heads/2743@{#311}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/media-play-promise-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/media-play-promise.html
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/track/track-cues-pause-on-exit-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-controls-overlay-play-button-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-played-collapse-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-played-ranges-1-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/Source/core/html/HTMLMediaElement.h

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

commit b62b49b650018c1367069a6c8e2a049e998fc4d9
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Fri Jun 10 10:34:20 2016

Fix race when HTMLMediaElement.play() is called just after pause().

The consequence is that the Promise returned by play() is rejected by
the task created by pause(). The fix is to associate the tasks with a
list of promises.

BUG= 593273 
TBR=avayvod@chromium.org

Review-Url: https://codereview.chromium.org/1865933002
Cr-Commit-Position: refs/heads/master@{#398370}
(cherry picked from commit 3a82d82079ca79cddd932eb77f924db5428885b9)

Review URL: https://codereview.chromium.org/2053333002 .

Cr-Commit-Position: refs/branch-heads/2743@{#311}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/media-play-promise-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/media-play-promise.html
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/track/track-cues-pause-on-exit-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-controls-overlay-play-button-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-played-collapse-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/LayoutTests/media/video-played-ranges-1-expected.txt
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/b62b49b650018c1367069a6c8e2a049e998fc4d9/third_party/WebKit/Source/core/html/HTMLMediaElement.h

Retested the above issue on Windows, Mac 10.11.5 & Ubuntu 14.04 on Chrome version '52.0.2743.41' and Error message are not displayed in the console continuously which earlier used to get displayed in the console.

Hence marking the above issue as TE-Verified-52.0.2743.41.

Attach are the before and after screen-shot for the same.

Deleted: Before fix-console.png 739 KB

	Before fix-console.png 739 KB View Download

Deleted: After fix console.png 233 KB

	After fix console.png 233 KB View Download

The error is still here with Canary 53.0.2767.4 / Mac 10.11.5. We've same problem with JwPlayer 7 too when we use mpeg-dash streaming 

We are also still seeing this in Canary Version 53.0.2770.0 canary (64-bit) on Mac OS/X 10.10.5 as of this morning.  Should the fix referenced above not yet be in the Canary release for some reason and if so when should we expect it to be in a Canary release ?  

Deleted: 2016-06-17_13-23-19_canary_js_promise_error.png 42.6 KB

	2016-06-17_13-23-19_canary_js_promise_error.png 42.6 KB View Download

Thank you for the report. Can you give a link to a test page where the issue can be reproduced?

This is a test page that reproduce problem with jwplayer: http://codepen.io/fdambrosio/pen/oLLEWz

This is actually an issue with JWPlayer: they call play() and before the playback actually starts call pause(), thus the play request is cancelled.

Are you suggesting that developers now need to add a check that the video playback has actually started every time they want to call pause(), or Chrome will throw a console error? 

Google's Blockly is also affected by the ongoing play-pause issue (as opposed to the pause-play issue that apparently has been fixed).  Sometimes we play a sound, then pause it before it has even started, resulting in an error.  Work-arounds for this Chrome issue invariably end up breaking Safari on iOS.
https://github.com/google/blockly/issues/299

This bug still appear in chrome version 52.0.2743.116 m

It's also on Chrome 54.0.2824.0 dev (64-bit)

Still seeing this issue in Version 52.0.2743.116 m

seeing this on Version 53.0.2785.57 beta (64-bit) (os-x 10.11.6)

i also hear 'tearing' / glitching in the audio track and playback seems to be accelerated.

I can still see this issue. It sucks. Stopping me from launching my project.

Still present in 53.0.2785.89 (win 64)

Adding 150ms pause in js before play prevents this error, and allows video to play. Workaround suggested here:
http://stackoverflow.com/questions/36803176/how-to-prevent-the-play-request-was-interrupted-by-a-call-to-pause-error

Still see this issue in Ver. 52.0.2743.116 win(x86/x64)，
And makes Google Translator/Baidu Fanyi can't read text. 

I have multiple pages that generate a video from the webcam for authentication and other features and this is massively killing off all of those services, anyone know how to fix this yet ?

I’m still getting this error in 53.0.2785.116 ~but only~ by calling pause() before the media element has finished loading. Once the readyState = 4 or the play() promise has fired, I don’t get the error any more.

To reproduce, throttle your bandwidth so the video doesn’t load immediately:

```
<script>
  function onClick(){
    setTimeout(function(){
      var video = document.querySelector("#video")
      if(video.readyState < 4){
        console.log('will error')
      } else {
        console.log('won’t error')
      }
      video.pause();
      video.play()
        .then(function(){
          console.log('played')
        })
    },10)
  };
</script>

<a href="#" onclick="onClick()"> Play here </a>

<video id="video" controls src="http://www.sample-videos.com/video/mp4/240/big_buck_bunny_240p_2mb.mp4" />
```

Chrome version  53.0.2785.116
This is still broken I am afraid. I have this issue when looping a video, the pause/play sequence work 2 times, the third time it does not play but it does not give error either, the fourth time it gets the infamous

Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()

And after that it fails constantly and not playing the content at all... 

I installed the version of Chromium compiled by Nik with all codecs (online tester) and PGO enabled v55.0.2875.0 (421462)
At first it playing mp4 videos didn't work on it.
I completely uninstalled Chromium and reinstalled the above version again and things started working like magic.

This is still affecting 54.0.2840.59

Still effecting Version 54.0.2840.99 m (64-bit)
but not 55.0.2883.52 beta (64-bit)
or Version 56.0.2922.0 canary (64-bit)
so seems to be on it's way

Can still reproduce 100% reliably in version 56 and version 57 (canary) if one is moving the mouse when pause() is called.

Can reproduce on 55.0.2883.87 m (64-bit) Windows 10, also 55.0.2883.75 on Windows 8.1, and 54.0.2840.90 (64-bit) on Ubuntu 16.06.

Reproducible on Chrome 55 Macos. Has anyone managed to find a workaround for it ?

I am also seeing this when working on Google Blockly on Chrome 55. It's reproducible every time I work with Blockly.

Please re-open because it's not fixed in Version 55.0.2883.95 (64-bit) Mac OS.

I too am seeing this on 55.0.2883.95 (64-bit), macOS Sierra.

I'm seeing this as well on 55.0.2883.95, MacOS 10.9.5.

Seeing this issue still occur on Windows 10, Version 57.0.2979.2 (Official Build) dev (64-bit)

Still seeing this issue on Version 55.0.2883.95 (64-bit) macOS Sierra

Seeing this on Windows 7, Version 55.0.2883.87 m

I have videos with preload="none" that I wanted to start playing when scrolled into view with a .play() followed by a .pause() soon after (my bad), but checking readyState === 4 before calling pause, like comment #66 suggested, fixed the issue by not showing any errors (otherwise it worked).

Also still seeing this on Chrome Version 56.0.2924.87, macOS El Capitan (10.11.6).

Why is this marked as "fixed" if it is not?

Yeah, i can see that sometimes on Windows 10 56.0.2924.87 (64-bit).
Why is this marked as "fixed"?

Seeing this on Chrome 56.0.2924.87 on Ubuntu 16.04.

Still getting the error in Chrome 57.0.2987.133 on Max OS 10.12.4 (Sierra)

This bug is not fixed

Agree, this is not fixed. 

Seeing in:
Chrome Mobile 57.0.2987
Chrome Mobile 56.0.2924
Chrome Mobile 55.0.2883
Chrome 57.0.2987
Chrome 56.0.2924
Chrome 55.0.2883

I also got this error.
Version 55.0.2883.87 (64-bit)

Why is this labeled at fixed?

Adding my voice to this too.
Able to reproduce as far as the latest Canary 60.0.3073.0

I see this in 57.0.2987.133 (64-bit)

Having this issue in 58.0.3029.81 on Ubuntu 16.04 (64-bit)

Still happening on 58.0.3029.81

Same, here,  58.0.3029.96 (64-bit) on OSX 
Why was this classified as "Spam"?

Hey!!! same error in version 58.0.3029.110 i was goin crazy. More than a year and still not resolved?

This has been resolved a long time ago. If you are seeing an error but that your website otherwise behave exactly the same, this is not a bug in Chrome but in your website. If you are seeing an error in the console *and* your website stopped behaving properly, please file another bug with a test page.

I understand the desire to wrap up the conversation, but I think Restrict-View-EditIssue is inappropriate ("Only users who can edit the issue may access it"), as it prevents most people from seeing the conversation that has already taken place.

Mounir, can we please change that label to Restrict-AddIssueComment-EditIssue ("Only users who can edit the issue may add comments") so that the conversation and the reasoning behind your decision remain publicly accessible?

Thanks for the ping Joey! I did not mean to hide the entire issue but wanted to avoid a pile of comments that isn't very productive. I don't have much experience doing this :)

No worries!  I didn't know about the various labels myself until I visited with a google.com account and was prevented from viewing.  :-)

For info, I've just published an article about this exact issue at https://developers.google.com/web/updates/2017/06/play-request-was-interrupted that tells you exactly what is happening and how to fix it.