When HLS redirects are encountered recreate WebMediaPlayer.

third_party/WebKit/Source/core/html/HTMLMediaElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp b/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
index 76a40bcf2f7241d937a90b544ee2a342e96c99ce..e07238514f001703483a79c379b67cb4a9adf05e 100644
--- a/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
@@ -2991,6 +2991,15 @@ void HTMLMediaElement::cancelledRemotePlaybackRequest()
         remotePlaybackClient()->connectCancelled();
 }
 
+void HTMLMediaElement::requestReload(const WebURL& newUrl)
+{
+    DCHECK(webMediaPlayer());
+    DCHECK(!m_srcObject);
+    resetMediaPlayerAndMediaSource();
+    ContentType contentType((String()));
+    loadResource(WebMediaPlayerSource(newUrl), contentType);

[foolip, 2016/06/22 13:10:54]

This will still have the problems with changing m_currentSrc and re-checking for
the muted attribute mentioned, and possibly other consequences that aren't
obvious.

I believe that exposing the redirected URL or a cross-origin resource could be
exposing information that isn't otherwise possible to get at.

I think the nicest fix here would be to match the spec, where the currentSrc
attribute is updated *before* the resource fetch algorithm is invoked. If we
pretend that loadResource is the resource fetch algorithm (it's the closest
thing we have) then it's just a matter of setting m_currentSrc before each call
to loadResource, maybe in a helper that also calls onCurrentSrcChanged.

[DaleCurtis, 2016/06/22 14:28:35]

I'm not sure I follow the differences from what's being done here. Setting
m_currentSrc before calling loadResource() appears equivalent to letting
loadResource() set the URL. Are you proposing removing the
m_currentSrc+onCurrentSourceChanged() from loadResource() in favor of making
callers to loadResource() perform that task on their own ahead of time? I.e.
with a helper SetCurrentSrc() which changes m_currentSrc+onCurrentSrcChanged?

[foolip, 2016/06/22 16:01:52]

Yeah, I'm suggesting to make the order more like the spec, and a setCurrentSrc
sounds reasonable. There would be one call (this one) to loadResource that
doesn't call setCurrentSrc first, which would be the whole point of such a
change.

[DaleCurtis, 2016/06/22 16:17:41]

StartPlayerLoad() also uses m_currentSrc though, so you're also proposing that
startPlayerLoad() use a passed in parameter instead? Or are you suggesting we
create some m_previousPlayerSource WebURL which is used by StartPlayerLoad() in
this case.

[foolip, 2016/06/22 18:00:49]

Oh, that's a problem. It's a bit silly that loadResource takes a
WebMediaPlayerSource but then startPlayerLoad has to create one from scratch. If
this new code path could just pass along the WebMediaPlayerSource all the way,
then it could leave m_currentSrc along and there is no problem.

How about letting startPlayerLoad also take a const WebMediaPlayerSource& and
constructing one in executeDeferredLoad? It's a bit brittle, but it will work so
long as deferred loads are only for normal URLs, which is currently the case.

I may have overlooked something more, of course.

[DaleCurtis, 2016/06/22 23:16:14]

I started going down this path and it quickly escalated into a pretty large
change. It ends up needing a couple helper functions that interact with the
loaded URL in subtle ways. I.e., today startPlayerLoad() doesn't use the source
given to loadResource() it filters its own.

Instead I introduced a playerProvidedUrl to the relevant functions which
overrides m_currentSrc updates and provides a succinct comment on why we do
this. I think this is simpler and less likely to have merge conflicts for
getting this back to M52.

+}
+
 // MediaPlayerPresentation methods
 void HTMLMediaElement::repaint()
 {