New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 732041 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

DOMException: on attempting to use the new Image Capture API

Reported by 00st...@gmail.com, Jun 10 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce the problem:
1. use the new ImageCpature API in the most naive way possible
2. execute the "takePhoto()" function on the ImageCapture object

What is the expected behavior?
It will return a blob containing the image.

What went wrong?
selfiesite.html:54 takePhoto() error: DOMException: setOptions failed
imageCapture.takePhoto.then.catch.error @ selfiesite.html:54

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 59.0.3071.86  Channel: stable
OS Version: 10.0
Flash Version: 

This only seems to occur on this one machine, but is common to all example sites using this new API.
 
selfiesite.html
1.8 KB View Download
 Issue 732040  has been merged into this issue.

Comment 2 by hdodda@chromium.org, Jun 12 2017

Cc: hdodda@chromium.org
Labels: -Type-Bug -Pri-2 M-60 Pri-1 Type-Bug-Regression
Owner: mcasas@chromium.org
Status: Assigned (was: Unconfirmed)
Tested the issue on windows 10 using chrome M59 #59.0.3071.86 and issue is reproduced.

This is a regression issue broken in M60 and fixed in latest beta , dev and canary versions and is reproduced only in windows 10.

Using the old bisect  script providing the reverse bisect results,
Good build: 60.0.3100.0(Revision: 471639).
Bad build: 60.0.3098.0 (Revision: 471507).

You are probably looking for a change made after 471619 (known good), but no later than 471627 (first known bad).

CHANGELOG URL:

 https://chromium.googlesource.com/chromium/src/+log/dbbb4e564b1412421f3a7b70cd8fa267581b3dea..d688239189bd18103150f9135931cc632ec3d308

From the CL's above, suspecting the below change and assigning the issue to the concern owner 

Suspect CL:

 https://chromium.googlesource.com/chromium/src/+/7bda7a4b1a6b2866538f903e06824500894d7d61

@mcasas- Could you please merge this fix to the stable M59.

Review-Url: https://codereview.chromium.org/2884513002

Thanks!

Comment 3 by phistuck@gmail.com, Jun 12 2017

@mcasas - was takePhoto() ever tested on Windows 7 using Chrome 59 beta? Or is this issue specific to certain types of system configurations?

Comment 4 by phistuck@gmail.com, Jun 12 2017

> This is a regression issue broken in M60 and fixed in latest beta , dev and canary versions and is reproduced only in windows 10.

I can reproduce on Windows 7 Enterprise using Chrome 59.

Comment 5 by mcasas@chromium.org, Jun 12 2017

this was probably introduced during wiring of setPhotoOptions() in
Windows, that happened during M60 and after M59 when the whole Image
Capture API was shipped as stable.
Most of my tests were conducted with a Logitech C920 on a Win10, but
I've received reports of |camera_control_| and/or |video_control_|
misbehaving [1] -- but I'm surprised they affect takePhoto() (there 
is a round of getPhotoCapabilities() gathering upon ImageCapture 
construction though).

[1] https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_device_win.cc?q=video_capture_device_win.cc+camera_control_&dr=C&l=489

Comment 6 by 00st...@gmail.com, Jun 12 2017

fwiw my system is also a Logitech C920 on Win10.

Comment 7 by mcasas@chromium.org, Jul 11 2017

Status: WontFix (was: Assigned)
We have landed elsewhere some fixes and merged back to M60 
so I'm marking this issue as WontFix since there's nothing we
can do about M59 now.

Sign in to add a comment