Reproduced on Windows 10 x64, Nightly 2018-02-21. STR: 1 In Sound settings, make sure there is only one recording device available (disable the others if there are any) 2 Open gum_test.html 3 Click Audio 4 In the prompt, select the audio device prefixed with "default: " 5 Open Sound settings, disable the only recording device. Expected: The track is ended. Media element enters ended state. Doorhanger goes away. Actual: The track doesn't end. The media element currentTime stops incrementing but it stays in a playing mode. Doorhanger is still around.

Alex mentioned on IRC that the reason for this is [1]. It seems like we assume that a default recording device is always present. [1] https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/media/libcubeb/src/cubeb_wasapi.cpp#1621

58, 59 and 60 have exactly the same failure modes. Choosing a non-default device (isn't prefixed "default: ") and disabling/unplugging it will end the track and update UI. Choosing the default (prefixed "default: ") will stall things after unplugging like comment 0. Plugging a device in again will resume the capture.

I should mention that for esr 52 we have the same behavior for the default device, but when chosen as an explicit one (no prefix for the default one here, so just the 2nd in the list), we also don't detect it being unplugged, so the capture just continues. Doesn't seem like a regression in any case, so P3. Though on the higher side for being low hanging fruit. Please correct me if I'm wrong.

IMO this bug should block bug 1299515. When the A/V have the same source (web cam) we hit the case described in bug 1436341: the web cam doesn't turn off the camera light even though both A and V tracks are disabled.

(In reply to Adrian Florinescu [:AdrianSV] from comment #4) > IMO this bug should block bug 1299515. > When the A/V have the same source (web cam) we hit the case described in bug > 1436341: the web cam doesn't turn off the camera light even though both A > and V tracks are disabled. As an additional details: -we are encountering this case when using Microsoft LifeCam HD-3000 which is both Audio and Video source for the call and the camera light is supposed to turn off when both A/V tracks are disabled. (when the call is done using the webcame A/Vsources). -the above is restricted only to windows (10, 7) -so the affected platforms are correct @Andreas- if you think this is not related to this bug, we'll log a new one describing the issue.

What you described to me on slack sounds just like bug 1436341. And I don't think this bug should block bug 1299515 because this is not a regression caused by bug 1299515.