User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36 Steps to reproduce: 1. Initiate screen capture with navigator.mozGetUserMedia 2. Grant permission to a screen or window via the address bar permission dialog 3. stop the stream via the permissions dialog in the address bar Actual results: 4. observe that the stream's currentTime continues to advance Expected results: 4. observe that the stream's currentTime is stopped at the time at which the sharing was stopped
Juan -- Can you confirm this bug? And check if it's a regression?
I can confirm this, but it doesn't seem to be a recent regression. I see it on the latest Firefox Dev Edition as well. Steps: 1. Go to https://mozilla.github.io/webrtc-landing/gum_test.html 2. Click on "Screen" 3. Select "Entire Screen" and share. 4. Open the Web Console under developer tools 5. Under the console tab look for video.mozSrcObject.currentTime in the prompt at the bottom 6. Stop sharing the screen from the sharing icon next to the address bar You will the current time continue to be updated even after you stop sharing the screen. This is also the case in Firefox 38.x (current release version).
This bug seems correctly prioritized to me, so I don't have anything else to add. Is there something in particular that's held up by this api-observable behavior?
Seems resolved in 47.0
Mass change P2->P3 to align with new Mozilla triage process.