ImageCapture: Queue up requests while device not ready

ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in
 VideoCaptureManager, where we store such requests _if_ the
 capture device is not ready (but it's known) -- these are
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything
 yet  (Android API needs the device up and running for many
 operations).

- adds a takePhoto() content_browsertest for Android and
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental) --gtest_filter=*WebRtcImageCaptureBrowserTest*
or
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*

Committed: https://crrev.com/bd1933b1b5ee7a3557401fe79f63f38e3d5deb81
Cr-Commit-Position: refs/heads/master@{#409988}

[mcasas, 2016-08-02 00:09:30]

Patchset #1 (id:1) has been deleted

[mcasas, 2016-08-02 00:10:07]

Patchset #1 (id:20001) has been deleted

[mcasas, 2016-08-02 00:10:15]

Patchset #1 (id:40001) has been deleted

[mcasas, 2016-08-02 00:10:23]

Patchset #1 (id:60001) has been deleted

[mcasas, 2016-08-02 00:22:57]

Patchset #1 (id:80001) has been deleted

[mcasas, 2016-08-02 00:23:04]

Patchset #1 (id:100001) has been deleted

[mcasas, 2016-08-02 00:30:46]

Description was changed from

==========
ImageCapture: add getPhotoCapabilities impl to Mac and content_browsertests for
takePhoto()

this CL:
- adds a semi-dummy getPhotoCapabilities() implementation to Mac
- extends the content_browsertest for photo capabilities to Mac
- adds a takePhoto() content_browsertest for both Mac and FakeVCD

BUG=518807
==========

to

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation, inVideoCaptureManager
- actual device capture, in VideoCaptureDeviceAndroid

So, this CL:
- adds a "queue" of image capture-related requests in VideoCaptureManager,
 where we store such requests is the capture device is not ready (but is
 known).
- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything yet
 (Android API needs the device up and running for many operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice.

BUG=518807
==========

[mcasas, 2016-08-02 00:31:59]

Description was changed from

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation, inVideoCaptureManager
- actual device capture, in VideoCaptureDeviceAndroid

So, this CL:
- adds a "queue" of image capture-related requests in VideoCaptureManager,
 where we store such requests is the capture device is not ready (but is
 known).
- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything yet
 (Android API needs the device up and running for many operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice.

BUG=518807
==========

to

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation, inVideoCaptureManager
- actual device capture, in VideoCaptureDeviceAndroid

So, this CL:
- adds a "queue" of image capture-related requests in VideoCaptureManager,
 where we store such requests is the capture device is not ready (but is
 known).
- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything yet
 (Android API needs the device up and running for many operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice.

BUG=518807, 627537
==========

[mcasas, 2016-08-02 01:01:48]

Description was changed from

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation, inVideoCaptureManager
- actual device capture, in VideoCaptureDeviceAndroid

So, this CL:
- adds a "queue" of image capture-related requests in VideoCaptureManager,
 where we store such requests is the capture device is not ready (but is
 known).
- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything yet
 (Android API needs the device up and running for many operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice.

BUG=518807, 627537
==========

to

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
==========

[mcasas, 2016-08-02 01:11:59]

Description was changed from

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
==========

to

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

[mcasas, 2016-08-02 01:29:58]

Description was changed from

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a semi-dummy getPhotoCapabilities() implementation to Mac

- adds a takePhoto() content_browsertest for both Mac, Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

to

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

[mcasas, 2016-08-02 01:36:37]

Patchset #1 (id:120001) has been deleted

[mcasas, 2016-08-02 20:28:57]

Patchset #1 (id:140001) has been deleted

[mcasas, 2016-08-02 20:29:06]

Patchset #1 (id:160001) has been deleted

[mcasas, 2016-08-02 23:00:50]

Description was changed from

==========
ImageCapture: Queue up requests if device is not ready (plus tests)

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but is known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

to

==========
ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but it's known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

[mcasas, 2016-08-02 23:05:27]

The CQ bit was checked by mcasas@chromium.org to run a CQ dry run

[mcasas, 2016-08-02 23:05:37]

Patchset #1 (id:180001) has been deleted

[mcasas, 2016-08-02 23:05:43]

Patchset #1 (id:200001) has been deleted

[commit-bot: I haz the power, 2016-08-02 23:06:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mcasas, 2016-08-02 23:50:03]

mcasas@chromium.org changed reviewers:
+ emircan@chromium.org

[mcasas, 2016-08-02 23:50:04]

emircan@ PTAL

[commit-bot: I haz the power, 2016-08-03 00:42:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-03 00:42:10]

Dry run: This issue passed the CQ dry run.

[mcasas, 2016-08-03 17:12:54]

emircan@ ping

[emircan, 2016-08-03 21:55:54]

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
File content/browser/renderer_host/media/video_capture_manager.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
content/browser/renderer_host/media/video_capture_manager.cc:522: DVLOG(3) <<
"OnDeviceStarted";
__func__

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
File content/browser/renderer_host/media/video_capture_manager.h (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
content/browser/renderer_host/media/video_capture_manager.h:336: // Queue to
keep photo-associated requests waiting for a device to initialize.
Comment on what the pair is made of.

https://codereview.chromium.org/2193213003/diff/220001/content/browser/webrtc...
File content/browser/webrtc/webrtc_image_capture_browsertest.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/webrtc...
content/browser/webrtc/webrtc_image_capture_browsertest.cc:92: // This test is
flaky on WebRTC Windows bots: https://crbug.com/633242.
I think it looked better before with one #ifdef(WIN), in comparison to having
two pointing to the same bug. Can you Bring back
MAYBE_WebRtcImageCaptureBrowserTest?

https://codereview.chromium.org/2193213003/diff/220001/content/test/data/medi...
File content/test/data/media/image_capture_test.html (right):

https://codereview.chromium.org/2193213003/diff/220001/content/test/data/medi...
content/test/data/media/image_capture_test.html:83: 
Remove empty line.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
File media/capture/video/android/video_capture_device_android.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.cc:220:
main_task_runner_->PostTask(FROM_HERE, request);
photo_requests_queue_.clear();

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
File media/capture/video/android/video_capture_device_android.h (right):

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:120: const
scoped_refptr<base::SingleThreadTaskRunner> main_task_runner_;
Can we use SequencedTaskRunner and SequencedTaskRunnerHandle instead? AFAIU,
there isn't a reason why this would have to be pinned on a single thread.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:122: // |lock_|
protects |state_|, |client_| and |got_first_frame_|,
also |photo_requests_queue_|

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:126: bool
got_first_frame_;
Can this be an InternalState such as kCapturing?

[mcasas, 2016-08-03 22:19:19]

Patchset #2 (id:240001) has been deleted

[mcasas, 2016-08-03 22:19:37]

PTAL (and discussion)

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
File content/browser/renderer_host/media/video_capture_manager.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
content/browser/renderer_host/media/video_capture_manager.cc:522: DVLOG(3) <<
"OnDeviceStarted";
On 2016/08/03 21:55:54, emircan wrote:
> __func__

Done.

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
File content/browser/renderer_host/media/video_capture_manager.h (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/render...
content/browser/renderer_host/media/video_capture_manager.h:336: // Queue to
keep photo-associated requests waiting for a device to initialize.
On 2016/08/03 21:55:54, emircan wrote:
> Comment on what the pair is made of.

Done.

https://codereview.chromium.org/2193213003/diff/220001/content/browser/webrtc...
File content/browser/webrtc/webrtc_image_capture_browsertest.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/content/browser/webrtc...
content/browser/webrtc/webrtc_image_capture_browsertest.cc:92: // This test is
flaky on WebRTC Windows bots: https://crbug.com/633242.
On 2016/08/03 21:55:54, emircan wrote:
> I think it looked better before with one #ifdef(WIN), in comparison to having
> two pointing to the same bug. Can you Bring back
> MAYBE_WebRtcImageCaptureBrowserTest?

Heh the problem is that the syntax is erroneous! It 
would disable the test for all platforms, not just for
OS_WIN as intended (see some recent test builder, 
e.g. [1, 2], search for "WebRtc" and then for 
"WebRtcImage").


[1]
https://build.chromium.org/p/chromium.mac/builders/Mac10.9%20Tests/builds/260...
[2]
https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests/builds/443...

https://codereview.chromium.org/2193213003/diff/220001/content/test/data/medi...
File content/test/data/media/image_capture_test.html (right):

https://codereview.chromium.org/2193213003/diff/220001/content/test/data/medi...
content/test/data/media/image_capture_test.html:83: 
On 2016/08/03 21:55:54, emircan wrote:
> Remove empty line.

Done.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
File media/capture/video/android/video_capture_device_android.cc (right):

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.cc:220:
main_task_runner_->PostTask(FROM_HERE, request);
On 2016/08/03 21:55:54, emircan wrote:
> photo_requests_queue_.clear();

Done.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
File media/capture/video/android/video_capture_device_android.h (right):

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:120: const
scoped_refptr<base::SingleThreadTaskRunner> main_task_runner_;
On 2016/08/03 21:55:54, emircan wrote:
> Can we use SequencedTaskRunner and SequencedTaskRunnerHandle instead? AFAIU,
> there isn't a reason why this would have to be pinned on a single thread.

SingleThreadTaskRunner is more pervasive, i.e. 167 [1] vs 27 for
SequencedTaskRunner [2] (in content/). Reading the comments 
in [3] I think it applies to our case: this variable captures the
construction thread (== owning thread), that should not change
during its lifetime.

[1] grep -rn "scoped_refptr<base::SingleThreadTaskRunner>" content/ | grep "_;"
|wc -l
[2] grep -rn "scoped_refptr<base::SequencedTaskRunner>" content/ | grep "_;" |
wc -l
[3]
https://cs.chromium.org/chromium/src/base/sequenced_task_runner.h?q=Sequenced...

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:122: // |lock_|
protects |state_|, |client_| and |got_first_frame_|,
On 2016/08/03 21:55:54, emircan wrote:
> also |photo_requests_queue_|

Done.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:126: bool
got_first_frame_;
On 2016/08/03 21:55:54, emircan wrote:
> Can this be an InternalState such as kCapturing?

Hmm it could be it would mix two things: |state_| 
represents different possible transitions, whereas
this binary flag is a flip-flop: stays false until it becomes
true and then stays true forever. Mixing both might
make it less evident their purpose.

[emircan, 2016-08-03 22:52:59]

lgtm

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
File media/capture/video/android/video_capture_device_android.h (right):

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:120: const
scoped_refptr<base::SingleThreadTaskRunner> main_task_runner_;
On 2016/08/03 22:19:36, mcasas wrote:
> On 2016/08/03 21:55:54, emircan wrote:
> > Can we use SequencedTaskRunner and SequencedTaskRunnerHandle instead? AFAIU,
> > there isn't a reason why this would have to be pinned on a single thread.
> 
> SingleThreadTaskRunner is more pervasive, i.e. 167 [1] vs 27 for
> SequencedTaskRunner [2] (in content/). Reading the comments 
> in [3] I think it applies to our case: this variable captures the
> construction thread (== owning thread), that should not change
> during its lifetime.
> 
> [1] grep -rn "scoped_refptr<base::SingleThreadTaskRunner>" content/ | grep
"_;"
> |wc -l
> [2] grep -rn "scoped_refptr<base::SequencedTaskRunner>" content/ | grep "_;" |
> wc -l
> [3]
>
https://cs.chromium.org/chromium/src/base/sequenced_task_runner.h?q=Sequenced...

Acknowledged.

https://codereview.chromium.org/2193213003/diff/220001/media/capture/video/an...
media/capture/video/android/video_capture_device_android.h:126: bool
got_first_frame_;
On 2016/08/03 22:19:37, mcasas wrote:
> On 2016/08/03 21:55:54, emircan wrote:
> > Can this be an InternalState such as kCapturing?
> 
> Hmm it could be it would mix two things: |state_| 
> represents different possible transitions, whereas
> this binary flag is a flip-flop: stays false until it becomes
> true and then stays true forever. Mixing both might
> make it less evident their purpose.

Acknowledged.

[emircan, 2016-08-03 22:53:00]

lgtm

[mcasas, 2016-08-03 23:31:49]

mcasas@chromium.org changed reviewers:
+ nick@chromium.org

[mcasas, 2016-08-03 23:31:49]

nick@chromium.org: Please RS changes in
content/browser/webrtc/webrtc_image_capture_browsertest.cc

[ncarter (slow), 2016-08-04 18:23:14]

lgtm

[mcasas, 2016-08-04 18:24:47]

The CQ bit was checked by mcasas@chromium.org

[commit-bot: I haz the power, 2016-08-04 18:25:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 20:08:46]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[commit-bot: I haz the power, 2016-08-04 20:09:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 20:09:50]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[mcasas, 2016-08-05 01:52:02]

Patchset #3 (id:280001) has been deleted

[mcasas, 2016-08-05 01:52:19]

Patchset #3 (id:300001) has been deleted

[mcasas, 2016-08-05 01:52:28]

Patchset #3 (id:320001) has been deleted

[mcasas, 2016-08-05 01:53:59]

Patchset #3 (id:340001) has been deleted

[mcasas, 2016-08-05 02:32:59]

The CQ bit was checked by mcasas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 02:33:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-05 04:03:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-05 04:03:02]

Dry run: This issue passed the CQ dry run.

[mcasas, 2016-08-05 04:07:50]

The CQ bit was checked by mcasas@chromium.org

[mcasas, 2016-08-05 04:07:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
emircan@chromium.org, nick@chromium.org
Link to the patchset: https://codereview.chromium.org/2193213003/#ps380001
(title: "Reduce requested getUserMedia() resolution")

[commit-bot: I haz the power, 2016-08-05 04:08:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-05 04:11:29]

Description was changed from

==========
ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but it's known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

to

==========
ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but it's known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

[commit-bot: I haz the power, 2016-08-05 04:11:30]

Committed patchset #4 (id:380001)

[commit-bot: I haz the power, 2016-08-05 04:13:35]

Description was changed from

==========
ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in 
 VideoCaptureManager, where we store such requests _if_ the 
 capture device is not ready (but it's known) -- these are 
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything 
 yet  (Android API needs the device up and running for many 
 operations).

- adds a takePhoto() content_browsertest for Android and 
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or 
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*
==========

to

==========
ImageCapture: Queue up requests while device not ready

Calls to ImageCapture methods (e.g. takePhoto(), getPhotoCapabilities())
might be lost if racing against either:
- device creation (in VideoCaptureManager)
- actual device capture (in VideoCaptureDeviceAndroid)

So, this CL:
- adds a "queue" of image capture-related requests in
 VideoCaptureManager, where we store such requests _if_ the
 capture device is not ready (but it's known) -- these are
 served OnDeviceStarted().

- adds a similar "queue" of requests in VideoCaptureDeviceAndroid,
 where we store requests is the device has not captured anything
 yet  (Android API needs the device up and running for many
 operations).

- adds a takePhoto() content_browsertest for Android and
 FakeVideoCaptureDevice, factoring Js code appropriately.

BUG=518807, 627537
TEST=added new content_browsertest:
out/gn/bin/run_content_browsertests(_incremental)
--gtest_filter=*WebRtcImageCaptureBrowserTest*
or
out/gn/content_browsertests --gtest_filter=*WebRtcImageCaptureBrowserTest*

Committed: https://crrev.com/bd1933b1b5ee7a3557401fe79f63f38e3d5deb81
Cr-Commit-Position: refs/heads/master@{#409988}
==========

[commit-bot: I haz the power, 2016-08-05 04:13:37]

Patchset 4 (id:??) landed as
https://crrev.com/bd1933b1b5ee7a3557401fe79f63f38e3d5deb81
Cr-Commit-Position: refs/heads/master@{#409988}

[Guido Urdaneta, 2016-08-05 10:19:55]

A revert of this CL (patchset #4 id:380001) has been created in
https://codereview.chromium.org/2219813002/ by guidou@chromium.org.

The reason for reverting is: Speculative revert. Suspect of breaking Android
Tester bots.
Will revert if it doesn't fix it.

See
https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg...
https://build.chromium.org/p/chromium.linux/builders/Android%20Tests/builds/3...
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Tests%20%...
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Tests%20%....