Merge steps 5 and 9 for prompt() algorithm about remote-playback

[mfoltzgoogle]

Why would you need to run the steps to monitor available playback devices if you already know the video cannot be remoted? It seems like it's worthwhile to keep this optimization.

[mounirlamouri]

I agree with @mfoltzgoogle

[avayvod]

I think the algorithm wouldn't prevent the user agent from early exit (we could add a note for that).
My reasoning was that the algorithm now has two exit points where the promise is rejected with the same exception and the difference seems to be very subtle and hard to understand for web authors (even I had to read it a couple of times before I remembered what it is). Maybe we should just rephrase those.

[mounirlamouri]

I think rephrasing would be good. FWIW, ideally, it shouldn't matter for web authors. Actually, the only thing that bothers me about this step is that it is before the check for "is allowed to show pop up" which means that a web author could figure which formats can be played by calling prompt() on different <video>. In other words, it makes the step observable while in principle, it's mostly an optimization. I would be in favour to swap steps 5 and 6 and rephrase.

[mfoltzgoogle]

There are three other issues I noted when preparing #76.

• I don't see a guarantee that the steps to start monitoring devices in 7 complete before step 9 is encountered. If they don't happen to find a device in time, then prompt will reject.
• If the steps to monitor do complete, then steps 8 and 9 seem to be equivalent: if a compatible remote playback device is found, then availability must be set to true?
• Steps 9 throws NotSupportedError while Presentation API throws NotFoundError for this case.

I think the simplest thing to do is to drop step 9. This leaves 8 for the case where the user agent knows that there will never be a compatible device, e.g. because discovery failed to start or it is in a stable state from a previous call. WDYT?

[avayvod]

SGTM