User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3355.0 Safari/537.36 Steps to reproduce: do a getUserMedia with mediaSource: 'window'. Select a window from the dropdown menu. Note: you have to actually publish the video to someone who subscribe to it, unless the bug not reproduce. (this make me think that maybe is an encoder bug). I'm using VP8 + opus. Actual results: once we close the selected window (ex. close the shared application), Firefox completely crashes. sometimes it crashes also when resizing the window (but happened only once and i'm not 100% sure). Happens both on windows and osx. Executing FF with -console param, the following line is printed 2 times at every crash: [Parent 1320, Gecko_IOThread] WARNING: pipe error: 232: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 513 Note: In windows 10, when screensharing an Office product (ex. Excel), only the first frame captured is sent, but then is stuck. if you modify the document, the subscriber can't see the updates. He only see the cursor pointer moving on top at the first captured frame. This does NOT happens when screensharing a full screen. Happens also in FF 59/60 dev Expected results: When you close a window that is being screenshared, the getusermedia should return an error or an event close as always did.

You can test the behavior with 2 tabs for example in https://simplewebrtc.com/demo.html?firefoxscreensharebug

Please post a relevant crash report link. https://developer.mozilla.org/docs/How_to_get_a_stacktrace_for_a_bug_report

Sure! bp-c259b438-31c0-4f93-87b6-927980180306 bp-3cf96611-334f-453d-a57f-778e60180306

(In reply to Francesco Durighetto from comment #3) > Sure! Thank you. > bp-c259b438-31c0-4f93-87b6-927980180306 Bug 1264209. > bp-3cf96611-334f-453d-a57f-778e60180306 Bug 1432793. :jesup you were involved in both the aforementioned bug reports; maybe you can sort this out. I don't know what to put in the Summary and Crash Signature fields since there are two different crash signatures.

Hi Francesco, Your two crash reports are for Firefox 58. Does this problem reproduce for you with the latest Nightly (Firefox 60)? Thank you, Dan

Yes, tested also with last nightly. Following stack trace are from Firefox 60 nightly: Doing the same test as reported: Here's the Crash report: bp-25e86025-e87b-4735-a9a5-8beb70180308 Also note that I have installed in my mac Camtwist that's a "webcam emulator". Nothing related to the previous screensharing bug but the first time he asked me what webcam to use, I selected it and crashed immediately: Here's the Crash report: bp-5f281be3-900c-4a03-97dd-8530b0180308 The stack trace seems quite similar, maybe because Camtwist wasn't available at the moment. It should have throw an getusermedia error but crashed instead.

(In reply to Francesco Durighetto from comment #6) > Yes, tested also with last nightly. Following stack trace are from Firefox > 60 nightly: > > Doing the same test as reported: > Here's the Crash report: bp-25e86025-e87b-4735-a9a5-8beb70180308 > > Also note that I have installed in my mac Camtwist that's a "webcam > emulator". Nothing related to the previous screensharing bug but the first > time he asked me what webcam to use, I selected it and crashed immediately: > > Here's the Crash report: bp-5f281be3-900c-4a03-97dd-8530b0180308 > > The stack trace seems quite similar, maybe because Camtwist wasn't available > at the moment. > It should have throw an getusermedia error but crashed instead. Thank you for checking it on 60. For whatever reason, I was unable to get this to happen on my osx machine but it just reproduced on windows.