Should we add reasons to MediaStreamTrack.onended

[youennf]

Websites might have to react upon capture ended events.
Providing some reasons might help web sites decide whether they should call getUserMedia again to recover.

[eladalon1983]

I'm supportive of this, and even more so of MuteReasons.

[youennf]

Some various reasons for failure:

• user revoked permission
• device disappeared
• device has a hardware failure
• window is closed (screen capture).

The first two reasons might be somehow discoverable via permissions API and devicechange/enumerateDevices.
In all cases, I am not sure automatic recovery is ideal. The web page might show some specific UI for case 2 and 3, but not for case 1. I am unsure about case 4.

[bradisbell]

In all cases, I am not sure automatic recovery is ideal.

Automatic recovery by the user agent is not ideal, but the web page should be able to, depending on their use case.

For my use case, it seems incredibly common to have a USB cable yanked out causing the "device disappeared" scenario for a split second. When this happens, it makes sense to attempt to get the stream again after a few seconds pass, and start recording again. This behavior is specific to the application.

[eladalon1983]

The first two reasons might be somehow discoverable via permissions API and devicechange/enumerateDevices.

As a rule, I don't find the argument of "also discoverable through x" as convincing, because that often requires that the app iterate through an arbitrary number of disparate potential reasons and their matching detection mechanisms. It's also not future-proof for when new potential reasons are discovered. Contrast that with:

switch (reason) {
  case 'reason1':
    doSomethingAboutReason1();
    break;
  case 'reason2':
    doSomethingAboutReason2();
    break;
  case 'reason3':
    // Known to be inactionable; ignore.
    break;
  default:
    // Log to the server that a new reason was encountered
    // in the wild. This will issue an alert and get a developer
    // to examine this and decide if it deserves its own handling,
    // or if it needs to be explicitly ignored.
    logNewReason(reason);
    break;
}

I am unsure about case 4.

I think it's likely that some apps would want to experiment with showing a toast notification, in case the user closed the shared tab/window unintentionally. (It's been known to happen.)