- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 18 Jan 2012 15:29:26 +0100
- To: Travis Leithead <Travis.Leithead@microsoft.com>
- Cc: public-media-capture@w3.org
On Jan 16, 2012, at 21:08 , Travis Leithead wrote: >> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] >> * It is not stated what should happen when the browser tab that has been >> allowed to capture is not in focus. I bring this up since one of the >> Speech JavaScript API Specifications >> (http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- >> 1696/speechapi.html#security) >> proposed that capture should stop in such cases, while that kind of >> behavior is not at all what you would want in e.g. a conferencing >> scenario (where you would often like to use another browser tab to check >> out things while being in the conference) > > This indeed is an interesting scenario. I would love to hear other's thoughts on this. We'll walk a fine line between user privacy (e.g., seems like a bad idea to just leave the user's camera on when they switch away from an active browser tab), and usability (e.g., in conferencing scenarios). Perhaps the use of a PeerConnection can trigger some state change in implementations such that they persist after switching tabs? You'll note that killing capture when the tab is backgrounded largely kills the screen capture scenario as well! I think that this may largely be a UX issue, namely: is it possible to background a tab (or possibly the entire browser) while still making the user aware that capture is ongoing, and while making it easy for them to turn it off post-haste. If there's a decent UX solution to this (e.g. some on-screen button that's always on top) then I think we're good, but if not we're probably in trouble. People have been prototyping this. Is there any input on this aspect? -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 18 January 2012 14:30:05 UTC