When HLS redirects are encountered recreate WebMediaPlayer.

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

 /*
  * Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012, 2013 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 2973 matching lines @@
     if (remotePlaybackClient())
         remotePlaybackClient()->stateChanged(WebRemotePlaybackState::Disconnected);
 }
 
 void HTMLMediaElement::cancelledRemotePlaybackRequest()
 {
     if (remotePlaybackClient())
         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()
 {
     if (m_webLayer)
         m_webLayer->invalidate();
 
     updateDisplayState();
     if (layoutObject())
         layoutObject()->setShouldDoFullPaintInvalidation();
 }
@@ skipping 982 matching lines @@
 
 IntRect HTMLMediaElement::AutoplayHelperClientImpl::absoluteBoundingBoxRect() const
 {
     IntRect result;
     if (LayoutObject* object = m_element->layoutObject())
         result = object->absoluteBoundingBoxRect();
     return result;
 }
 
 } // namespace blink