This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22272 - Permission revokation via MediaStreamTrack.stop()
Summary: Permission revokation via MediaStreamTrack.stop()
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 minor
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-04 21:34 UTC by Dominique Hazael-Massieux
Modified: 2013-10-17 11:32 UTC (History)
3 users (show)

See Also:


Attachments

Description Dominique Hazael-Massieux 2013-06-04 21:34:05 UTC
Right now the spec says:
"Note that a web application can revoke all given permissions with MediaStreamTrack.stop()."

but there is no matching conformance requirement; I believe the stop() method should describe the relevant conformance requirements, e.g. "The User Agent must revoke all given permissions for the given media source (?) when the stop() method is invoked".

I'm not sure if that also means revoking access to other existing media tracks that would originate from the same source, or if it "only" means requiring consent for new tracks originating from the said source.
Comment 1 Stefan Hakansson LK 2013-09-27 13:48:56 UTC
Harald recently sent some text on how this part can be interpreted [1]. The comments so far seemed to say that that interpretation made sense, so I think the text in the draft should be updated to reflect this.



[1] http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0192.html
Comment 2 Adam Bergkvist 2013-10-04 07:33:44 UTC
Updated description of the MediaStreamTrack.stop() method.

Proposed change:
https://github.com/fluffy/webrtc-w3c/commit/295ef0fea7ab9597f756fd4b493fedb493e712f8
Comment 3 Adam Bergkvist 2013-10-17 11:32:45 UTC
Fixed in Editor's draft v20131017