Update: "chromcasting" in question is casting with Chrome's native media controls, not with any JS api.

The following repro steps worked for me:
1. Open https://omroep-pwa-bmrzqpwxnl.now.sh/
2. Click on a video thumbnail to navigate to the video page.
3. Play & cast the video
4. Hit the back button to navigate back

Reproduces on Canary 61 and Stable 59.

The bug seems to occur because of the InvokeLoadAlgorithm in HTMLMediaElement::DidMoveToNewDocument() that has a FIXME before it:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp?rcl=ae67f19c066747ebc8f5cfe2e705b8169b508c21&l=603

git hyper-blame unhelpfully points to a patch by liberato@ that didn't touch that code. Could be foolip@ or acolwell@ who put it in place long time ago?

I wonder if we can remove it.

Found the original change here: https://chromiumcodereview.appspot.com/19693009/diff/13001/Source/core/html/HTMLMediaElement.cpp

Last time I looked at this, it wasn't a trivial change. It's something we would like to do though so it wouldn't be a bad use of time to investigate more but it will not allow us to fix the crash up to stable/beta.

Well, it's not the cause of the crash until it's proved to be, just the pause on Chromecast.

I don't believe this is cause of the crash. I avoided the crash by stopping using events in MediaElement#remote. I outlined some of the details in the crash issue. I don't remember how exactly, but crash was tied to `connect` event. So now I listen to those events but unsubscribe from them on `connecting` event and start polling state with setInterval() instead. 

This would seem to be the cause of this interop issue found on webcompat.com (not specific to Chromecast): https://webcompat.com/issues/8777

It would be good to address this before more sites come to rely on this auto-pausing quirk. Edge and Gecko do not pause on moving video/audio elements in the DOM (WebKit has its own issue for which I will file a bug).

I've attached a testcase in case it helps (but note that this affects not just <video> elements as in the testcase, but also <audio> elements).

Deleted: testcase.html 656 bytes

testcase.html 656 bytes View Download

> (WebKit has its own issue for which I will file a bug)

WebKit renders empty (black) buffer to Picture-in-Picture video when it's off-dom, i.e. moving it in dom blinks the video. Audio plays fine.

Not sure if this is the same issues you planned file.

>Not sure if this is the same issues you planned file.

No, it looks like WebKit currently restarts a video when I move it around in the DOM, using my above testcase (the video and audio both restart at the beginning). Firefox and Edge simply continue smoothly playing it.

I filed this bug: https://bugs.webkit.org/show_bug.cgi?id=176840

If this still matter, this issues causes some compatibility issues in frameworks: https://github.com/developit/preact/issues/747

Clearly, moving DOM elements such as video, audio or canvas shouldn't affect its internal (i.e. playing) state.

The spec for this is slightly below https://html.spec.whatwg.org/multipage/media.html#time-marches-on, at "When a media element is removed from a Document".

In short, removing the media element should pause, but not synchronously, only if it's not reinserted somewhere else, which is the case when moving.

This is a duplicate of  bug 382879 .