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

Add Basic navigator.mediaDevices test. #2657

Merged
merged 12 commits into from Mar 22, 2016
Merged

Add Basic navigator.mediaDevices test. #2657

merged 12 commits into from Mar 22, 2016

Conversation

agouaillard
Copy link
Contributor

=> DOM

@hoppipolla-critic-bot
Copy link

Critic review: https://critic.hoppipolla.co.uk/r/6243

This is an external review system which you may optionally use for the code review of your pull request.

In order to help critic track your changes, please do not make in-place history rewrites (e.g. via git rebase -i or git commit --amend) when updating this pull request.

@wpt-pr-bot
Copy link
Collaborator

Reviewers for this pull request are: @alvestrand, @dontcallmedom, and @foolip.

<!doctype html>
<html>
<head>
<title>getUserMedia: test that getUserMedia is present (with or without vendor prefix)</title>
Copy link
Contributor

Choose a reason for hiding this comment

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

Ths test checks that enumerateDevices is present, while the title, file name and so on claim to check for getUserMedia. Can you make it consistent?
(It's fine to check both in the same test)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will do.

@alvestrand
Copy link
Contributor

Seems to me you're doing an extremely deep hierarchy: mediacapture-streams/obtaining-local-multimedia-content/{navigatorusermedia,mediadevices}/.

Any reason for this deepness? If so, can you explain proper placement in a README.md file in the mediacapture-streams directory?
My immediate thought is that the "navigatorusermedia" level should go away.

@@ -1,3 +1,4 @@
@alvestrand
@dontcallmedom
@foolip
@agouaillard
Copy link
Member

Choose a reason for hiding this comment

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

Can you keep the file sorted?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@alvestrand : we decided with dom to follow the chapters in the spec for easier spec <-> tests scrum'ing.

@foolip will do.

<script>
"use strict";
//NOTE ALEX: for completion, a test for ondevicechange event is missing.
test(function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

No objection to having this kind of test, but isn't this (API presence) better done by adding the WebIDL-driven tests that we did earlier for peerconnection API?

(to be clear: I'm happy merging this version, but @agouaillard should look at the WebIDL-driven tools)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean like the one used for media track API in mediastream-api/mediastreamtrack-init ?

@alvestrand
Copy link
Contributor

I think we should merge this and progress iteratively. @dontcallmedom can decide.

"use strict";
//NOTE ALEX: for completion, a test for ondevicechange event is missing.
test(function () {
assert_true(undefined !== navigator.mediaDevices.enumerateDevices(), "navigator.mediaDevices.enumerateDevices() exists");
Copy link
Contributor

Choose a reason for hiding this comment

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

I think @foolip mentioned it before, but it seems to me more logical to test

undefined !== navigator.mediaDevices.enumerateDevices

since we're checking for existence

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean without the parenthesis? Please educate me on the difference in JS.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, test existence, and not execute it. got it. fixing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done.

assert_equals(error.name, "SecurityError", "SecurityError returned");
assert_equals(error.constraintName, null, "constraintName attribute not set for permission denied");
assert_equals(error.name, "securityError", "securityError returned");
// NOTE ALEX: this is also nullable, but practically, all the browsers but FF set it to an empty string.
Copy link
Contributor

Choose a reason for hiding this comment

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

we should test based on what the spec says, not based on what implementations do; if and when the spec gets proven to be wrong, we will update the test, but if we hide implementation bugs in our test cases, we won't find the discrepancies between spec and implementations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, and the commit you commented reverted to the original code that does just that as far as the error type is concerned. Now, some object are nullable by spec, but the spec does not address the default value at initialization. In that case, my understanding is that it is left to the implementation to decide if an empty string or a null object should be set. Do I understand wrong (and there is a spec that says that e.g. nullable object should be initialized as null)? Should we make the spec explicit in that case?

Copy link
Contributor

Choose a reason for hiding this comment

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

The only error objects that would have a non-undefined "constraintName" would be from overconstraint event; for any other error, the correct test is to assert_equals(error.constraintName, undefined)

dontcallmedom added a commit that referenced this pull request Mar 22, 2016
Add Basic navigator.mediaDevices test.
@dontcallmedom dontcallmedom merged commit 0e9955b into web-platform-tests:master Mar 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants