[mediacapture-region] Behavior when cropTo races with the track ending (#72)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-region:

== Behavior when cropTo races with the track ending ==
Assume an active track. Assume cropTo() is called on that track while it's active. A Promise is returned, and IPC follows; in Chromium - IPC to the "browser process". What if, once the IPC message is received on the browser process, it is discovered that the track has recently been ended¹? Shall we:
1. Reject the Promise.
2. Resolve the Promise, since the guarantee holds that "no further old-crop-target frames will be issued on this track."
3. Leave the Promise hanging.

(Note that this question is loosely related to #71.)

Option 2, resolving, would be bad for code that `await`s the Promise and then immediately treats the happy case.
Option 3, hanging, is patently bad for any code that `await`s the Promise.

I'd say that the principle of least surprise mandates that we go with option 1 and reject the Promise with the same error as #71.

It's an open question as to whether we should also specify that the [ended event](https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/ended_event) should always fire before the Promise is rejected. Well-structured applications would already be listening for the event, ready to perform cleanup when it's observed. But the caller to cropTo() could be `await`-ing the Promise. It would be up to said caller, whether to perform cleanup from the onended-handler, from the cropTo() catch-block, from both, or from whichever runs first.

Wdyt?

--
[1] Or any other part of the multi-process system that precedes the actual resolution of the promise.


Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/72 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 22 September 2022 10:13:04 UTC