HTML Media Capture: update capture attribute to use string.

Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.
The spec changes have landed in
https://github.com/w3c/html-media-capture/issues/4

iOS also implemented the functionality in
https://trac.webkit.org/changeset/204312/webkit

BUG=698853
Review-Url: https://codereview.chromium.org/2735633004
Cr-Commit-Position: refs/heads/master@{#470881}
Committed: https://chromium.googlesource.com/chromium/src/+/08c2a170239dae6559f696d033fa1baf8bbef4ac

[mcasas, 2017-03-06 22:55:28]

Description was changed from

==========
[WIP] HTML Media Capture:

Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.

Logs all around
==========

to

==========
[WIP] HTML Media Capture:

Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.

Logs all around

BUG=698853
==========

[riju_, 2017-04-06 13:32:20]

Description was changed from

==========
[WIP] HTML Media Capture:

Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.

Logs all around

BUG=698853
==========

to

==========
Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.
The spec changes have landed in
https://github.com/w3c/html-media-capture/issues/4

iOS also implemented the functionality in
https://trac.webkit.org/changeset/204312/webkit

BUG=698853
==========

[riju_, 2017-04-06 13:32:38]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 13:32:49]

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

[riju_, 2017-04-06 13:32:59]

Patchset #3 (id:40001) has been deleted

[commit-bot: I haz the power, 2017-04-06 13:34:11]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[riju_, 2017-04-06 13:35:51]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 13:36:03]

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, 2017-04-06 13:59:25]

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

[commit-bot: I haz the power, 2017-04-06 13:59:26]

Dry run: 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...)

[riju_, 2017-04-24 11:09:13]

Patchset #3 (id:60001) has been deleted

[riju_, 2017-04-24 11:10:52]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-24 11:11:06]

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, 2017-04-24 11:32:32]

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

[commit-bot: I haz the power, 2017-04-24 11:32:33]

Dry run: 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...)

[riju_, 2017-04-24 12:42:15]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-24 12:42:37]

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, 2017-04-24 14:16:31]

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

[commit-bot: I haz the power, 2017-04-24 14:16:32]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[riju_, 2017-04-26 10:45:15]

rijubrata.bhaumik@intel.com changed reviewers:
+ mcasas@chromium.org

[riju_, 2017-04-26 10:45:16]

Hi Miguel,

The spec will transition to Candidate Recommendation on 04 May 2017.
It will be good to have chromium align to the spec, even though Android does not
support
this officially
(https://bugs.chromium.org/p/chromium/issues/detail?id=698853#c11). 

Would you be able to have a look at this CL ?

Web-platform-tests are at
https://github.com/w3c/web-platform-tests/tree/master/html-media-capture.

Shall I unskip
this(https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/W3CImportExpectations?q=third_party/WebKit/LayoutTests/W3CImportExpectations+file:%5Esrc/+package:%5Echromium$&l=277)
in this CL only ?

[mcasas, 2017-04-26 19:27:35]

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

[mcasas, 2017-04-26 19:27:37]

Couple of comments.  It kinda troubles me that
we are landing code that won't work, i.e. the user
commanding user/environment won't be respected,
for the sake of aligning to the Spec. I'd like to hear
foolip@s opinion on this.


Re. the wpt-tests import (that are now in [Pass]),
I think it's best to do it in another CL (might need
some mods orthogonal to this CL).

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1685: String capture =
FastGetAttribute(captureAttr).DeprecatedLower();
DeprecatedLower() looks deprecated, perhaps you can
use LowerASCII() instead?
Also, make |capture| const.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1691: return
"environment";
This is implied by l.1686. What about:

if (capture == "user")
  return capture;
// |capture| is equivalent to 'environment' if unspecified.
return "environment";

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.h (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.h:249: void
SetCapture(const AtomicString& value);
l.253-254 have lowercase the first 's' so
s/SetCapture/setCapture/ for consistency?

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.idl (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.idl:26: enum
CaptureFacingMode { "user", "environment" };
nit: please add a link to the Spec relevant Section.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.idl:109: //
https://crbug.com/698853
Remove the TODO() with the CL.

[foolip, 2017-04-27 08:31:46]

On 2017/04/26 19:27:37, mcasas wrote:
> Couple of comments.  It kinda troubles me that
> we are landing code that won't work, i.e. the user
> commanding user/environment won't be respected,
> for the sake of aligning to the Spec. I'd like to hear
> foolip@s opinion on this.

Which is the problematic bit? In general, we should push back against any spec
we don't think make sense, and just expose the bits that we actually support. I
saw that a status transition is imminent, but that in itself isn't something we
should care about, what should constrain us is what others have shipped or want
to ship.

> Re. the wpt-tests import (that are now in [Pass]),
> I think it's best to do it in another CL (might need
> some mods orthogonal to this CL).

What changes are those? I can't see a W3CImportExpectations change. I've sent
out https://codereview.chromium.org/2848533002, PTAL. No need to wait for the
tests to actually be imported, though.

[riju_, 2017-04-27 08:36:53]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-04-27 08:37:19]

Dry run: CQ is trying da patch.

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

[riju_, 2017-04-27 08:48:36]

On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> On 2017/04/26 19:27:37, mcasas wrote:
> > Couple of comments.  It kinda troubles me that
> > we are landing code that won't work, i.e. the user
> > commanding user/environment won't be respected,
> > for the sake of aligning to the Spec. I'd like to hear
> > foolip@s opinion on this.
> 
> Which is the problematic bit? In general, we should push back against any spec
> we don't think make sense, and just expose the bits that we actually support.
I
> saw that a status transition is imminent, but that in itself isn't something
we
> should care about, what should constrain us is what others have shipped or
want
> to ship.

There is a Note in the spec which says:
If the user agent is unable to support the preferred facing mode, it can fall
back to the implementation-specific default facing mode.

Since Android API (using intents) is currently not allowing us to open the
camera is "user" mode in a standard way,
we choose to open camera in implementation-specific default mode , i.e.
"environment".

> > Re. the wpt-tests import (that are now in [Pass]),
> > I think it's best to do it in another CL (might need
> > some mods orthogonal to this CL).
> 
> What changes are those? I can't see a W3CImportExpectations change. I've sent
> out https://codereview.chromium.org/2848533002, PTAL. No need to wait for the
> tests to actually be imported, though.
Thanks. I did not know if the wpt enabling has to be done in the feature
implementation CL or not.

[foolip, 2017-04-27 09:09:39]

On 2017/04/27 08:48:36, riju_ wrote:
> On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> > On 2017/04/26 19:27:37, mcasas wrote:
> > > Couple of comments.  It kinda troubles me that
> > > we are landing code that won't work, i.e. the user
> > > commanding user/environment won't be respected,
> > > for the sake of aligning to the Spec. I'd like to hear
> > > foolip@s opinion on this.
> > 
> > Which is the problematic bit? In general, we should push back against any
spec
> > we don't think make sense, and just expose the bits that we actually
support.
> I
> > saw that a status transition is imminent, but that in itself isn't something
> we
> > should care about, what should constrain us is what others have shipped or
> want
> > to ship.
> 
> There is a Note in the spec which says:
> If the user agent is unable to support the preferred facing mode, it can fall
> back to the implementation-specific default facing mode.
> 
> Since Android API (using intents) is currently not allowing us to open the
> camera is "user" mode in a standard way,
> we choose to open camera in implementation-specific default mode , i.e.
> "environment".

In other words, we don't really support the CaptureFacingMode and just ignore
it?

> > > Re. the wpt-tests import (that are now in [Pass]),
> > > I think it's best to do it in another CL (might need
> > > some mods orthogonal to this CL).
> > 
> > What changes are those? I can't see a W3CImportExpectations change. I've
sent
> > out https://codereview.chromium.org/2848533002, PTAL. No need to wait for
the
> > tests to actually be imported, though.
> Thanks. I did not know if the wpt enabling has to be done in the feature
> implementation CL or not.

Needs an L-G-T-M to land, if someone is willing :)

[commit-bot: I haz the power, 2017-04-27 10:15:44]

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

[commit-bot: I haz the power, 2017-04-27 10:15:45]

Dry run: This issue passed the CQ dry run.

[riju_, 2017-04-27 10:31:34]

On 2017/04/27 09:09:39, foolip OOO until May 2 wrote:
> On 2017/04/27 08:48:36, riju_ wrote:
> > On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> > > On 2017/04/26 19:27:37, mcasas wrote:
> > > > Couple of comments.  It kinda troubles me that
> > > > we are landing code that won't work, i.e. the user
> > > > commanding user/environment won't be respected,
> > > > for the sake of aligning to the Spec. I'd like to hear
> > > > foolip@s opinion on this.
> > > 
> > > Which is the problematic bit? In general, we should push back against any
> spec
> > > we don't think make sense, and just expose the bits that we actually
> support.
> > I
> > > saw that a status transition is imminent, but that in itself isn't
something
> > we
> > > should care about, what should constrain us is what others have shipped or
> > want
> > > to ship.
> > 
> > There is a Note in the spec which says:
> > If the user agent is unable to support the preferred facing mode, it can
fall
> > back to the implementation-specific default facing mode.
> > 
> > Since Android API (using intents) is currently not allowing us to open the
> > camera is "user" mode in a standard way,
> > we choose to open camera in implementation-specific default mode , i.e.
> > "environment".
> 
> In other words, we don't really support the CaptureFacingMode and just ignore
> it?

Yes. 
There is a bug in the issue tracker
(https://issuetracker.google.com/issues/36924444)
Unfortunately, it is marked as WontFix, for reason not known publicly.

> 
> > > > Re. the wpt-tests import (that are now in [Pass]),
> > > > I think it's best to do it in another CL (might need
> > > > some mods orthogonal to this CL).
> > > 
> > > What changes are those? I can't see a W3CImportExpectations change. I've
> sent
> > > out https://codereview.chromium.org/2848533002, PTAL. No need to wait for
> the
> > > tests to actually be imported, though.
> > Thanks. I did not know if the wpt enabling has to be done in the feature
> > implementation CL or not.
> 
> Needs an L-G-T-M to land, if someone is willing :)

[riju_, 2017-04-27 12:30:20]

Thanks Miguel, fixed the comments.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1685: String capture =
FastGetAttribute(captureAttr).DeprecatedLower();
On 2017/04/26 19:27:36, mcasas wrote:
> DeprecatedLower() looks deprecated, perhaps you can
> use LowerASCII() instead?
> Also, make |capture| const.

Done.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1691: return
"environment";
On 2017/04/26 19:27:36, mcasas wrote:
> This is implied by l.1686. What about:
> 
> if (capture == "user")
>   return capture;
> // |capture| is equivalent to 'environment' if unspecified.
> return "environment";

Done.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.h (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.h:249: void
SetCapture(const AtomicString& value);
On 2017/04/26 19:27:36, mcasas wrote:
> l.253-254 have lowercase the first 's' so
> s/SetCapture/setCapture/ for consistency?

Was a bit confused by Blink-renaming, and git cl format did not complain.
so looks like we want it to be: capture() and setCapture()

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.idl (right):

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.idl:26: enum
CaptureFacingMode { "user", "environment" };
On 2017/04/26 19:27:37, mcasas wrote:
> nit: please add a link to the Spec relevant Section.

Done.

https://codereview.chromium.org/2735633004/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.idl:109: //
https://crbug.com/698853
On 2017/04/26 19:27:37, mcasas wrote:
> Remove the TODO() with the CL.

Done.

[mcasas, 2017-04-27 18:03:04]

On 2017/04/27 09:09:39, foolip OOO until May 2 wrote:
> On 2017/04/27 08:48:36, riju_ wrote:
> > On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> > > On 2017/04/26 19:27:37, mcasas wrote:
> > > > Couple of comments.  It kinda troubles me that
> > > > we are landing code that won't work, i.e. the user
> > > > commanding user/environment won't be respected,
> > > > for the sake of aligning to the Spec. I'd like to hear
> > > > foolip@s opinion on this.
> > > 
> > > Which is the problematic bit? In general, we should push back against any
> spec
> > > we don't think make sense, and just expose the bits that we actually
> support.
> > I
> > > saw that a status transition is imminent, but that in itself isn't
something
> > we
> > > should care about, what should constrain us is what others have shipped or
> > want
> > > to ship.
> > 
> > There is a Note in the spec which says:
> > If the user agent is unable to support the preferred facing mode, it can
fall
> > back to the implementation-specific default facing mode.
> > 
> > Since Android API (using intents) is currently not allowing us to open the
> > camera is "user" mode in a standard way,
> > we choose to open camera in implementation-specific default mode , i.e.
> > "environment".
> 
> In other words, we don't really support the CaptureFacingMode and just ignore
> it?

The changes in the Spec makes sense and the provision
to fall back to the old ways are senseful too.  My bit of a
question was that, since we have no guarantee that Android
will honour our user/environment request (per bug comment),
perhaps it wouldn't make more sense to not wire the String
"user"/"environment" beyond Blink at all, and instead
we should not propagate this said String beyond Blink.
Does it make sense?

> 
> > > > Re. the wpt-tests import (that are now in [Pass]),
> > > > I think it's best to do it in another CL (might need
> > > > some mods orthogonal to this CL).
> > > 
> > > What changes are those? I can't see a W3CImportExpectations change. I've
> sent
> > > out https://codereview.chromium.org/2848533002, PTAL. No need to wait for
> the
> > > tests to actually be imported, though.
> > Thanks. I did not know if the wpt enabling has to be done in the feature
> > implementation CL or not.
> 
> Needs an L-G-T-M to land, if someone is willing :)

Done :-)

[riju_, 2017-05-02 10:44:14]

On 2017/04/27 18:03:04, mcasas wrote:
> On 2017/04/27 09:09:39, foolip OOO until May 2 wrote:
> > On 2017/04/27 08:48:36, riju_ wrote:
> > > On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> > > > On 2017/04/26 19:27:37, mcasas wrote:
> > > > > Couple of comments.  It kinda troubles me that
> > > > > we are landing code that won't work, i.e. the user
> > > > > commanding user/environment won't be respected,
> > > > > for the sake of aligning to the Spec. I'd like to hear
> > > > > foolip@s opinion on this.
> > > > 
> > > > Which is the problematic bit? In general, we should push back against
any
> > spec
> > > > we don't think make sense, and just expose the bits that we actually
> > support.
> > > I
> > > > saw that a status transition is imminent, but that in itself isn't
> something
> > > we
> > > > should care about, what should constrain us is what others have shipped
or
> > > want
> > > > to ship.
> > > 
> > > There is a Note in the spec which says:
> > > If the user agent is unable to support the preferred facing mode, it can
> fall
> > > back to the implementation-specific default facing mode.
> > > 
> > > Since Android API (using intents) is currently not allowing us to open the
> > > camera is "user" mode in a standard way,
> > > we choose to open camera in implementation-specific default mode , i.e.
> > > "environment".
> > 
> > In other words, we don't really support the CaptureFacingMode and just
ignore
> > it?
> 
> The changes in the Spec makes sense and the provision
> to fall back to the old ways are senseful too.  My bit of a
> question was that, since we have no guarantee that Android
> will honour our user/environment request (per bug comment),
> perhaps it wouldn't make more sense to not wire the String
> "user"/"environment" beyond Blink at all, and instead
> we should not propagate this said String beyond Blink.
> Does it make sense?
I understand your concern, but I think having String on Blink side and
Boolean on content/Java side looks a bit odd.

> 
> > 
> > > > > Re. the wpt-tests import (that are now in [Pass]),
> > > > > I think it's best to do it in another CL (might need
> > > > > some mods orthogonal to this CL).
> > > > 
> > > > What changes are those? I can't see a W3CImportExpectations change. I've
> > sent
> > > > out https://codereview.chromium.org/2848533002, PTAL. No need to wait
for
> > the
> > > > tests to actually be imported, though.
> > > Thanks. I did not know if the wpt enabling has to be done in the feature
> > > implementation CL or not.
> > 
> > Needs an L-G-T-M to land, if someone is willing :)
> 
> Done :-)

[foolip, 2017-05-03 15:27:03]

https://codereview.chromium.org/2735633004/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.idl (right):

https://codereview.chromium.org/2735633004/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.idl:109: [Measure,
RuntimeEnabled=MediaCapture, Reflect] attribute CaptureFacingMode capture;
I've filed https://github.com/w3c/html-media-capture/issues/12 because
the supporting bits for this were recently removed from HTML.

[foolip, 2017-05-03 15:28:50]

On 2017/05/02 10:44:14, riju_ wrote:
> On 2017/04/27 18:03:04, mcasas wrote:
> > On 2017/04/27 09:09:39, foolip OOO until May 2 wrote:
> > > On 2017/04/27 08:48:36, riju_ wrote:
> > > > On 2017/04/27 08:31:46, foolip OOO until May 2 wrote:
> > > > > On 2017/04/26 19:27:37, mcasas wrote:
> > > > > > Couple of comments.  It kinda troubles me that
> > > > > > we are landing code that won't work, i.e. the user
> > > > > > commanding user/environment won't be respected,
> > > > > > for the sake of aligning to the Spec. I'd like to hear
> > > > > > foolip@s opinion on this.
> > > > > 
> > > > > Which is the problematic bit? In general, we should push back against
> any
> > > spec
> > > > > we don't think make sense, and just expose the bits that we actually
> > > support.
> > > > I
> > > > > saw that a status transition is imminent, but that in itself isn't
> > something
> > > > we
> > > > > should care about, what should constrain us is what others have
shipped
> or
> > > > want
> > > > > to ship.
> > > > 
> > > > There is a Note in the spec which says:
> > > > If the user agent is unable to support the preferred facing mode, it can
> > fall
> > > > back to the implementation-specific default facing mode.
> > > > 
> > > > Since Android API (using intents) is currently not allowing us to open
the
> > > > camera is "user" mode in a standard way,
> > > > we choose to open camera in implementation-specific default mode , i.e.
> > > > "environment".
> > > 
> > > In other words, we don't really support the CaptureFacingMode and just
> ignore
> > > it?
> > 
> > The changes in the Spec makes sense and the provision
> > to fall back to the old ways are senseful too.  My bit of a
> > question was that, since we have no guarantee that Android
> > will honour our user/environment request (per bug comment),
> > perhaps it wouldn't make more sense to not wire the String
> > "user"/"environment" beyond Blink at all, and instead
> > we should not propagate this said String beyond Blink.
> > Does it make sense?
> I understand your concern, but I think having String on Blink side and
> Boolean on content/Java side looks a bit odd.

Having an enum in Blink that ends up being ignored is pretty unfortunate. IIUC,
it will still be enough that attribute exists, and effectively all that has
changed is how the attribute is reflected? If so, then I think it'd be best to
change how it's reflected at the same time as the lower layers are changed.

I'm not an expert in this area though, I'll defer to anyone who claims to be an
expert :)

[riju_, 2017-05-05 09:01:05]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-05-05 09:01:20]

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, 2017-05-05 10:25:38]

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

[commit-bot: I haz the power, 2017-05-05 10:25:39]

Dry run: This issue passed the CQ dry run.

[riju_, 2017-05-08 07:17:37]

String (capture) is now not propagated beyond Blink. PTAL.

[riju_, 2017-05-08 07:19:16]

Patchset #6 (id:140001) has been deleted

[foolip, 2017-05-08 08:10:25]

On 2017/05/08 07:17:37, riju_ wrote:
> String (capture) is now not propagated beyond Blink. PTAL.

PS6 in isolation looks good, but how will it be used outside of Blink? Did I
understand correctly that we regardless of the value, we'll do exactly the same
thing on Android?

[riju_, 2017-05-08 08:36:15]

On 2017/05/08 08:10:25, foolip wrote:
> On 2017/05/08 07:17:37, riju_ wrote:
> > String (capture) is now not propagated beyond Blink. PTAL.
> 
> PS6 in isolation looks good, but how will it be used outside of Blink? Did I
> understand correctly that we regardless of the value, we'll do exactly the
same
> thing on Android?

Yes. In Android, we still open the back camera regardless of the value.
As advised I am not even passing the String to content/Android side.

[foolip, 2017-05-08 13:25:31]

On 2017/05/08 08:36:15, riju_ wrote:
> On 2017/05/08 08:10:25, foolip wrote:
> > On 2017/05/08 07:17:37, riju_ wrote:
> > > String (capture) is now not propagated beyond Blink. PTAL.
> > 
> > PS6 in isolation looks good, but how will it be used outside of Blink? Did I
> > understand correctly that we regardless of the value, we'll do exactly the
> same
> > thing on Android?
> 
> Yes. In Android, we still open the back camera regardless of the value.
> As advised I am not even passing the String to content/Android side.

I'll defer to mcasas@ about what to do here since the details probably matter.

[mcasas, 2017-05-10 19:50:31]

On 2017/05/08 13:25:31, foolip wrote:
> On 2017/05/08 08:36:15, riju_ wrote:
> > On 2017/05/08 08:10:25, foolip wrote:
> > > On 2017/05/08 07:17:37, riju_ wrote:
> > > > String (capture) is now not propagated beyond Blink. PTAL.
> > > 
> > > PS6 in isolation looks good, but how will it be used outside of Blink? Did
I
> > > understand correctly that we regardless of the value, we'll do exactly the
> > same
> > > thing on Android?
> > 
> > Yes. In Android, we still open the back camera regardless of the value.
> > As advised I am not even passing the String to content/Android side.
> 
> I'll defer to mcasas@ about what to do here since the details probably matter.

I guess this is the least bad solution given the situation with the
Android Intent possibly ignoring the request for front/back, and 
the need to line up with the Spec and other browsers.

lgtm % bots happy  and a question: do we need to (trivially)
update the wpt tests [1] (or the expectations)?

[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/...

[riju_, 2017-05-11 06:14:44]

The CQ bit was checked by rijubrata.bhaumik@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-05-11 06:15:15]

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, 2017-05-11 07:53:16]

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

[commit-bot: I haz the power, 2017-05-11 07:53:17]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[riju_, 2017-05-11 08:07:21]

On 2017/05/10 19:50:31, mcasas wrote:
> On 2017/05/08 13:25:31, foolip wrote:
> > On 2017/05/08 08:36:15, riju_ wrote:
> > > On 2017/05/08 08:10:25, foolip wrote:
> > > > On 2017/05/08 07:17:37, riju_ wrote:
> > > > > String (capture) is now not propagated beyond Blink. PTAL.
> > > > 
> > > > PS6 in isolation looks good, but how will it be used outside of Blink?
Did
> I
> > > > understand correctly that we regardless of the value, we'll do exactly
the
> > > same
> > > > thing on Android?
> > > 
> > > Yes. In Android, we still open the back camera regardless of the value.
> > > As advised I am not even passing the String to content/Android side.
> > 
> > I'll defer to mcasas@ about what to do here since the details probably
matter.
> 
> I guess this is the least bad solution given the situation with the
> Android Intent possibly ignoring the request for front/back, and 
> the need to line up with the Spec and other browsers.
> 
> lgtm % bots happy  and a question: do we need to (trivially)
> update the wpt tests [1] (or the expectations)?
> 
> [1]
>
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/...

Thanks Miguel. The WPT tests were updated here:
https://github.com/w3c/web-platform-tests/commit/0da700ff06e5930dc3f9d348f705...

[riju_, 2017-05-11 08:09:46]

rijubrata.bhaumik@intel.com changed reviewers:
+ haraken@chromium.org

[riju_, 2017-05-11 08:09:47]

@haraken: PTAL for WebKit/Source/platform

[haraken, 2017-05-11 08:37:21]

LGTM

[riju_, 2017-05-11 08:46:55]

The CQ bit was checked by rijubrata.bhaumik@intel.com

[commit-bot: I haz the power, 2017-05-11 08:47:50]

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, 2017-05-11 09:00:54]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1494492415328350,
"parent_rev": "60c4e93feefc319b6f4daee43576a5906a971efd", "commit_rev":
"08c2a170239dae6559f696d033fa1baf8bbef4ac"}

[commit-bot: I haz the power, 2017-05-11 09:01:05]

Description was changed from

==========
Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.
The spec changes have landed in
https://github.com/w3c/html-media-capture/issues/4

iOS also implemented the functionality in
https://trac.webkit.org/changeset/204312/webkit

BUG=698853
==========

to

==========
Implement https://github.com/w3c/html-media-capture/issues/4

HTML Media Capture spec changes the `capture'
attribute from an boolean to enum FacingMode.
The spec changes have landed in
https://github.com/w3c/html-media-capture/issues/4

iOS also implemented the functionality in
https://trac.webkit.org/changeset/204312/webkit

BUG=698853

Review-Url: https://codereview.chromium.org/2735633004
Cr-Commit-Position: refs/heads/master@{#470881}
Committed:
https://chromium.googlesource.com/chromium/src/+/08c2a170239dae6559f696d033fa...
==========

[commit-bot: I haz the power, 2017-05-11 09:01:11]

Committed patchset #6 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/08c2a170239dae6559f696d033fa...