mediastream support: don't throw on readyState 0?

[fippo]

https://wicg.github.io/picture-in-picture/#request-pip requires throwing when the readyState is HAVE_NOTHING. Does that still make sense when the video element has a MediaStream set as srcObject?

Removing this restriction when the srcObject is a MediaStream would (assuming getDisplayMedia is considered a gesture, see crbug) allow calling getDisplayMedia and then pip-ing the resulting stream. I assume that waiting for loadedmetadata or similar and then calling requestpictureinpicture would loose the user activation.

[beaufortfrancois]

Hey @fippo, we still need video width and height size to be able to show a properly sized Picture-in-Picture window. I think what we need is User Activation v2

Browsers control access to "abusable" of APIs (e.g. opening popups or vibrating) through user activation (or "user gesture"). However, the web exposed behavior vary widely among major browsers. To unify the web, this feature defines a new user activation model that is simple enough for cross-browser implementation. The main changes introduced by this model are: (a) there is no concept of token passing, and (b) activation visibility changes from stack-scoped to frame-scoped.

Enable the flag at chrome://flags/#user-activation-v2 and let me know if that works better for you.

[fippo]

Yes, that works! For simple testing, on any page that has a video object named "remoteVideo" (e.g. this paste:

navigator.getDisplayMedia({video: true}).then(stream => {
  remoteVideo.srcObject = stream;
  remoteVideo.addEventListener('loadedmetadata', () => {
    remoteVideo.requestPictureInPicture()
      .catch(e => console.error(e.name, e));
  })
});