Sort camera device list to use front camera first

media/capture/video/linux/video_capture_device_factory_linux.cc

Index: media/capture/video/linux/video_capture_device_factory_linux.cc
diff --git a/media/capture/video/linux/video_capture_device_factory_linux.cc b/media/capture/video/linux/video_capture_device_factory_linux.cc
index 14a1ca12e6b4c5679e1ed4efd5fc3df4b9aae3a2..2bf09872467c6663397bedb1fd9dcbe1e380b23f 100644
--- a/media/capture/video/linux/video_capture_device_factory_linux.cc
+++ b/media/capture/video/linux/video_capture_device_factory_linux.cc
@@ -228,6 +228,12 @@ void VideoCaptureDeviceFactoryLinux::GetDeviceDescriptors(
 #endif
     }
   }
+#if defined(OS_CHROMEOS)
+  // Since JS doesn't have API to get camera facing, we sort the list to make
+  // apps can use the front camera by default.

[mcasas, 2017/01/25 17:35:15]

nit: s/to make apps can use/to make sure apps use/ ?

[henryhsu, 2017/01/26 02:22:54]

Done.

+  // TODO(henryhsu): remove this after JS API completed (crbug.com/543997).

[Guido Urdaneta, 2017/01/25 10:24:47]

Is this comment valid?
It is true that once crbug.com/543997 is fixed, constraints can be used to
specify which camera to use based on facing mode.
However, what about the case when no constraint is specified so that all cameras
are equally valid?
In this case the implementation needs a tie-breaking rule.
Would you prefer the tie breaker to choose front cameras over other cameras? If
so, the tie breaker could be implemented by preferring cameras that appear first
in the enumeration, so this ordering might need to be kept even after
crbug.com/543997.

[henryhsu, 2017/01/25 10:38:01]

Once crbug.com/543997 is fixed, caller should have all information to decide
which camera should be opened. The preference logic should be moved to caller
(camera app). So all cameras here are equal.

+  std::sort(device_descriptors->begin(), device_descriptors->end());
+#endif
 }
 
 void VideoCaptureDeviceFactoryLinux::GetSupportedFormats(