Affected versions]: Tested on Nightly 60.0a1(2018-02-06) [Affected platforms]: Tested on Mac OS X 10.12, [Steps to reproduce]: Prerequisites: 1. Make sure you have connected 1 camera that uses the USB port. STR: 1. Open Firefox and go to https://appear.in and start a video call by selecting the camera that you plugged in. 2. Unplug your camera. 3. Plugin the camera but in a different USB port and try to reconnect to the previous call. [Expected result]: The camera starts to capture. [Actual result]: In the drop-down from where you select what camera to share you have the camera name plus #2. Here is a print screen of this issue: https://imgur.com/a/m8qpV If I select that camera the browser crashes. After the first crash, I can connect to the site but the camera name is the same. NOTE: I tested on Ubuntu and I can't reproduce this issue there, I will try with Windows and I will update this bug if something doesn't work. The crash signatures are related to bug 1435670.

On Ubuntu, it has different behaviors depending on which site are you. Appear.in - if you go into settings after you connect the camera, you don't see any camera displayed in the dropdown, only 2 empty boxes. Jitsi - You can select the camera from the drop-down in the Settings but you are prompted with this message: "Unable to access camera" and the camera doesn't capture anything.

This is reproducible also on Windows7 and 10 but without any crashes, the camera capture freezes. The behavior is similar to the one from Ubuntu.

Can you get cubeb logs (cubeb:4) from the freeze on Windows case?

Hello Alex, please tell me how to do that.

Sure that's a link about it. Go on Windows sections. Replace the MOZ_LOG env with cubeb:4 https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

This stack is also the same signature as in Bug 1435670. Not sure if it is a dupe?

Thanks for the logs, on Windows you hit Bug 1426333. When it is fixed we could probably recheck.

Likely a dupe to 1435670 but since this is where we have an STR I'll use this to investigate.

This crash happens when a camera doesn't report any capabilities at all. The child ignores this fact (rightfully so for screensharing as it looks from comments) and tries to start it anyway. The parent however, has a hard assumption about there being a capability. Bug 1419374 fixed a real issue here in 59 and put in a MOZ_DIAGNOSTIC_ASSERT instead. I think this assert should be removed, but note that there's no risk here in release. Reducing priority. I'm also hitting a crash in the child after this. I imagine that is a regression from bug 1299515 for now but will file bugs accordingly.

I'm duping this and following up in bug 1435670.

Pondering a bit about this I think it just happens to share symptoms with bug 1435670 but the flaw must be more fundamental. Instead I think this could be related to bug 1436959 -- the unplugged camera doesn't go away so after replugging we're using some stale state from its previous incarnation. I also got confirmation from Ovidiu on slack that this only happens on Mac, which points to bug 1436959. With that in mind I'm lowering priority.

Ovidiu, with bug 1436959 now fixed, could you retest this on latest Nightly to see if this was fixed in the process?

Hi Andreas, I tested this issue on Windows 10 x64, with FF Nightly 60.0a1(2018-03-05) using the Logitec HD-pro-webcam-c920 and the results are the same as are described in comment 1.

Comment 1 is not necessarily a bug, unless you can show that it's a regression by us. You are after all unplugging the camera in use. You also don't say what microphone device you're using. If that device is in fact the camera you unplug, and you haven't given the page you're testing on persistent permissions, you don't have any live capture going anymore. This is a state that applications don't handle particularly well and, for one, trying to enumerate devices will not give you real labels - which could result in empty boxes like you say in comment 1. This needs an exact STR, cross platform testing and regression analysis for me to be able to say much. What about the extra "#2" camera after replugging per comment 0, is it still around? That's what I consider this bug to be about.

The extra "#2" is not reproducible anymore. But following the same STR that are described in this bug, on Windows, I have the results from comment 1. I will look to see if this is a regression or not.

Tested on FF beta 59.0b14 with https://appear.in and Logitec HD 920 camera. Results: go to settings after you re-connect the camera, the camera section is greyed out and in the microphone section you have a drop down but no matter what device you choose the video and audio capture is blocked in the same state as when you unplug the camera. Maybe we should split this in separate bugs?

(In reply to ovidiu boca[:Ovidiu] from comment #17) > Tested on FF beta 59.0b14 with https://appear.in and Logitec HD 920 camera. > > Results: go to settings after you re-connect the camera, the camera section > is greyed out and in the microphone section you have a drop down but no > matter what device you choose the video and audio capture is blocked in the > same state as when you unplug the camera. > > Maybe we should split this in separate bugs? Can you explain how this is a bug on our end?

Because I compared this behavior with Chrome and there you can select what device to share and the video is refreshed and you can continue your call, on Firefox you can't continue your call.

(In reply to ovidiu boca[:Ovidiu] from comment #19) > Because I compared this behavior with Chrome and there you can select what > device to share and the video is refreshed and you can continue your call, > on Firefox you can't continue your call. This is because of differences in permission handling of getUserMedia in Chrome vs Firefox. With websites building specifically for Chrome (where most users are) instead of for all cases covered by the spec we can't expect them to always get it right. (Chrome provides some shortcuts in that it automatically persists the permission given by the user, so most sites assume that once you've got one gUM resolved you can do whatever you want) From my point of view this issue was resolved by bug 1436959. Marking as such. Feel free to open a new bug if you have a concrete case where we don't follow the spec. Or perhaps Tech Evangelism issues for the sites that don't work well with Firefox.