Change two media request "invalid state" results.

chrome/browser/media/media_capture_devices_dispatcher.cc

Index: chrome/browser/media/media_capture_devices_dispatcher.cc
diff --git a/chrome/browser/media/media_capture_devices_dispatcher.cc b/chrome/browser/media/media_capture_devices_dispatcher.cc
index def0efa240eadcec162d11fc3b25e436fe2ac12d..21140474deff423561ab8a54af09f1af82feef98 100644
--- a/chrome/browser/media/media_capture_devices_dispatcher.cc
+++ b/chrome/browser/media/media_capture_devices_dispatcher.cc
@@ -626,12 +626,15 @@ void MediaCaptureDevicesDispatcher::ProcessScreenCaptureAccessRequest(
       ui = GetDevicesForDesktopCapture(devices, screen_id, capture_audio,
                                        display_notification, application_title,
                                        application_title);
+      DCHECK(!devices.empty());
     }
   }
 
+  // The only case when devices can be empty is if the user has denied
+  // permission.

[tommi (sloooow) - chröme, 2014/09/20 14:45:23]

or !screen_capture_enabled or !origin_is_secure?

in either case, I think that 'permission denied' would be the appropriate error
code (unless we add a specific one for screen capture).

[Henrik Grunell, 2014/09/22 09:16:14]

Ah, right.
I'd prefer to have the permission denied for user action, though I do think we
use it for non-user action cases in other places already. I changed it so that
invalid state is kept for the cases you pointed out. Wdyt?

I could add another denied result in a follow-up that's used for non-user action
denial such as this case.

   callback.Run(
     devices,
-    devices.empty() ? content::MEDIA_DEVICE_INVALID_STATE :
+    devices.empty() ? content::MEDIA_DEVICE_PERMISSION_DENIED :
                       content::MEDIA_DEVICE_OK,
     ui.Pass());
 }
@@ -711,7 +714,21 @@ void MediaCaptureDevicesDispatcher::
 
   content::MediaStreamDevices devices;
 
+  // Set an initial error result. If neither audio or video is allowed, we'll
+  // never try to get any device below but will just create |ui| and return an
+  // empty list with "invalid state" result. If at least one is allowed, we'll
+  // try to get device(s), and if failure, we want to return "no hardware"
+  // result.
+  // TODO(grunell): The invalid state result should be changed to a new denied
+  // result + a dcheck to ensure at least one of audio or video types is
+  // capture.
+  content::MediaStreamRequestResult result =
+      audio_allowed || video_allowed ? content::MEDIA_DEVICE_NO_HARDWARE
+                                     : content::MEDIA_DEVICE_INVALID_STATE;

[tommi (sloooow) - chröme, 2014/09/20 14:45:23]

instead of invalid state, should it be permission denied if neither video nor
audio is allowed?

[Henrik Grunell, 2014/09/22 09:16:14]

Same reply as above, as the todo also says.

+
   // Get the exact audio or video device if an id is specified.
+  // We only set any error result here and before running the callback change
+  // it to OK if we have any device.
   if (audio_allowed && !request.requested_audio_device_id.empty()) {
     const content::MediaStreamDevice* audio_device =
         GetRequestedAudioDevice(request.requested_audio_device_id);
@@ -742,6 +759,7 @@ void MediaCaptureDevicesDispatcher::
 
   scoped_ptr<content::MediaStreamUI> ui;
   if (!devices.empty()) {
+    result = content::MEDIA_DEVICE_OK;
     ui = media_stream_capture_indicator_->RegisterMediaStream(
         web_contents, devices);
   }