tguilbert@, can you take a look and see if there's an interaction between data saver and remote playback?

Data saver interferes with remote playback by deferring the player load, (which is equivalent to setting "preload=none").

If you change this line (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/html_media_element.cc?type=cs&q=HTMLMediaElement::PreloadType&sq=package:chromium&l=2283) to return kPreloadMetadata, there is no issue.

Another way to repro this is to disable data saver, and set preload=none on a video (for example using this test page http://storage.googleapis.com/watk/v)

A mitigation to the issue is to start playing the video, which forces the load.


As mentioned in the original description, there are two issues:
1) Prompt() button throws some exceptions
- There seems to be a legitimate problem with the prompt never being shown, and it then become impossible to clear the |prompt_promise_resolver_| because of this code:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/remoteplayback/remote_playback.cc?type=cs&q=%22prompt+is+already%22&sq=package:chromium&l=175

I am not very familiar with ScriptPromiseResolvers, so I have not looked deeper into this issue for now.

2) Cast icon does not appear
When preload=none is set, WMPI doesn't get created until we attempt to start playing video. This causes problems in both the old an the new pipeline.

- Using the old remote playback pipeline:
We get device discovery callbacks through the RemoteMediaPlayerBridge, which only gets created after WMPI is created. I don't think there is a good way to get discovery callbacks without WMPI, or that there is a simple workaround.
- Using the new remote playback pipeline:
It seems like discovery doesn't happen until we set |RendererController::is_remote_playback_disabled_| to false via this line https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/html_media_element.cc?type=cs&q=HTMLMediaElement::PreloadType&sq=package:chromium&l=1288. 


Fixing the prompt() issue is a worthwhile investment of time, but I haven't looked into what the proper fix actually is.

I do not think that fixing the issue for the old pipeline is worth it, considering how it is going to be removed, and how difficult it would be to surface discovery without WMPI being created.
For the new pipeline, I will focus on getting the pipeline up and running, and then see what can be done. There is likely a way to address the issue, considering that the RemotePlayback module is created regardless of preload type. 

Mini edit: the first link in the above comment should be https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/html_media_element.cc?type=cs&q=HTMLMediaElement::PreloadType&sq=package:chromium&l=2295

Are (1) and (2) related? In other words, does this happen if preload is set to auto for example?

SGTM to fix only for the new playback pipeline.  If there is a quick fix for prompt with preload=none, that would be worth landing as well but maybe should be tracked in a separate issue?

I didn't get a chance to address C#4 and C#5 today, I will update tomorrow.

C#4: There seems to be some odd behavior.
When datasaver is on, the value returned by preload is always "none", regardless of the 'preload' attribute value (it is therefore impossible to set preload=auto and test your question). See attached screenshot.

Is this a bug in and of itself?


C#5: For the new remote playback pipeline, I've traced back the only thing that seems to be preventing the prompt from showing to this line:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/html_media_element.cc?type=cs&sq=package:chromium&l=1169

(If you set it to true, it works without a problem)

And the prompt works when you play the media, because this line eventually gets triggered:
https://cs.chromium.org/chromium/src/media/remoting/renderer_controller.cc?type=cs&sq=package:chromium&l=330

I will look into fixing this the right way.

I haven't had a chance to look for the behavior in the old pipeline for this. I will take another look by EOW.

Deleted: 837299_preload_with_datasaver.png 27.9 KB

	837299_preload_with_datasaver.png 27.9 KB View Download

> C#4: There seems to be some odd behavior.
> When datasaver is on, the value returned by preload is always "none",
> regardless of the 'preload' attribute value (it is therefore impossible to set preload=auto and test your question). See attached screenshot.

> Is this a bug in and of itself?
 
Mounir, you sent an Intent to Ship back in 2016 affecting preload behavior.
Is this related?

https://groups.google.com/a/chromium.org/d/topic/blink-dev/_fxvn-ny2jA/discussion

> C#5: For the new remote playback pipeline, I've traced back the only thing that seems to be preventing the prompt from showing to this line:

I'm not deeply familiar with the Remote Playback implementation in HTMLMediaElement.

In general, if Chrome can monitor remote playback availability in the background, we are conservative: assume not available until we find out otherwise.  Blocking preload seems to leave the media element with no availability until playback is started by some means.

If the page calls prompt() and Chrome can search for screens, then ideally we search again, and show a spinner/progress bar while searching.  However, I am not sure the Android screen picker UX supports a "searching / searching failed" views.

If you change that line above to "true", what happens with prompt() on networks with & without Cast devices?