Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

define permission persistence #8

Merged
merged 3 commits into from
Sep 18, 2014

Conversation

dontcallmedom
Copy link
Member

<p>When all <code><a>MediaStreamTrack</a></code> instances have
been detached from their sources, their <code>
<a href="#dom-mediastreamtrack-label">label</a></code>
<em class="rfc2119">must</em> be set to the empty string.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understood it, the resolution about "taking away labels when all devices have been closed", refers to the MediaDeviceInfo array you get from MediaDevices.enumerateDevices() (called after all devices have been closed), not MediaStreamTrack objects. The approach so far has been to leave the informational properties on MediaStreamTrack as is even though it's ended.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, I guess I was confused; in that case, I think that pull request is probably to be scrapped then.

@adam-be
Copy link
Member

adam-be commented Sep 4, 2014

The second part about stored permissions still applies.

Regarding taking away the label, I think we need some text in section 9.2.

From section 9.2.2:
"Collects information about the user agents available media input and output devices. The method MUST only return information that the script is authorized to access (TODO expand authorized)"

@dontcallmedom
Copy link
Member Author

I've updated the pull request to reflect what I understand the rules of access to enumerateDevices() to be; please review carefully since I was obviously confused before :)

@adam-be adam-be merged commit 3cd8cda into w3c:master Sep 18, 2014
@adam-be
Copy link
Member

adam-be commented Sep 18, 2014

Thanks for fixing this Dom.

I added a small fix that leaves resultList unmodified (since it's used again in the next invocation of the function). Instead, a copy, filteredList, is modified and emitted in the callback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants