Set the front camera as the default for video media requests

[Alexandre Abreu]

At the moment, the selected camera (in form factors having multiple ones) defaults to the back camera which does not work very well for cases like hangouts, the container and the browser should default to the front camera.

[Pat McGowan (pat-mcgowan)]

We should also provide a way to select the camera in settings, or better by dynamically adding an option to the menu

[Peter Bittner (peter-bittner)]

This is a useful default (probably for everything apart from photo shooting apps), and will hopefully land in OTA-11 for real.

Pat, Olivier:
The feature that offers control over which camera an app should use may not need to be hidden inside the browser's settings menu, buried three levels deep in a hierarchy as now. The alternative to a browser "Settings" menu option is of course the "camera" icon in the address bar, as desktop browsers do it. Firefox also has an overlay in the middle of the top edge of the page, in addition. This is something that could appear (and fade away) in both the webbrowser-app and the webapp-container. Maybe. Or something that appears when swiping in with a gesture from one of the edges (bottom edge)?

Alexandre:
For what I see appear.in does not handle switching cameras via app logic on the mobile web interface. Only native apps seem to do. (Their FAQ even specifically notes a similar problem with Windows Surface tablets. See "I have a Microsoft Surface and it only shows the back camera. Help!" at https://appear.in/information/faq/)

Comments related to by Alexandre and Olivier are in:
- https://lists.launchpad.net/ubuntu-phone/msg19515.html
- https://lists.launchpad.net/ubuntu-phone/msg19517.html
- https://lists.launchpad.net/ubuntu-phone/msg19510.html

[Olivier Tilloy (osomon)]

From https://appear.in/information/faq/:

« How do I switch between front and rear facing cameras on mobile?
On iPhone and Android, you can swap the camera by tapping on your own video. This will switch between the cameras. »

It’s not clear whether this refers to native apps on Android/iOS, or if it’s the mobile website. The fact that they mention iPhone and Android explicitly seems to suggest the former though.

@Peter: have you tried tapping on your own video in the mobile website? Does it have any effect? (if you can try in e.g. chrome on android, that would be perfect).

[Pat McGowan (pat-mcgowan)]

why is this on hold? was under the impression it was complete

[Peter Bittner (peter-bittner)]

I had the impression that this feature/change would make it into OTA-11. I updated yesterday and the rear camera is still the default.

Canonical could have cheering from technology press with sweet working video chat via the Appear.in webapp. You guys don't seem to want that. Why? What's wrong?

[David Barth (dbarth)]

Peter, we couldn't land pre-release builds of Oxide 1.15, which is the release where those fixes were developed and tested.

Oxide is on a 6 weeks release cadence, in sync with Blink upstream, and that not always allows us to make it into the target OTAs. Between features and stability / security, we always opt for the latter.

Oxide 1.15 builds are available at https://launchpad.net/~oxide-builds/+archive/ubuntu/oxide-next
Next is generally ok on a developer's phone, whereas trunk is not really recommended unless you develop on Oxide itself.

With Oxide 1.15 you get the getUserMedia API that lets apps change the capture devices dynamically. This is what we expect WebRTC applications to use in the future.

The case of appear.in is that they don't use this API (yet?) and rely on the "user agent" to switch between cameras. There is such a feature already in webbrowser-app, where you can switch cameras, the same way the FAQ advises to workaround the problem on Microsoft Surface.

We definitely want all new WebRTC apps to run great on Ubuntu, ie not just Google Hangouts. T

[David Barth (dbarth)]

Thanks for raising again the importance of that feature.

[Peter Bittner (peter-bittner)]

This task is "In Progress" for more than 2.5 months. Is the status still correct?

Will this feature be finished for and shipped with OTA-12?

[Peter Bittner (peter-bittner)]

Oops, sorry for my inconsiderate follow-up. I somehow overlooked the progress in the meantime. (I don't get all - some I do! - notifications from Launchpad anymore since I had to silence Gmail notifications on the phone using filters in Gmail.)

I still don't fully understand: Will the front-camera be the default in the web browser app and webapp container for OTA-12? This would be sufficient as a work-around for now.

P.S.: I'm pretty sure we all understand that neither Appear.in nor Google (not even any other known company) will care much about what API Canonical wants them to use. It's good that there is some available but for now sensible default should produce the optimal outcome for our mainstream users.

[Olivier Tilloy (osomon)]

@Peter: yes, this is targeted at OTA-12, the change that makes the front camera the default for the browser app and webapp container is currently in a silo, has been tested and approved, and should be landing this week.

[David Barth (dbarth)]

Just confirm that the silo is on its way to the release now, having passed
QA. I listed your appear.in webapp in the testcase.

Note that there is still an annoying issue we are aware of, related to
inverted rotations which are not being exposed by the Qt API. See bug:
535820 for reference.

On Wed, Jun 22, 2016 at 12:48 PM, Olivier Tilloy <
<email address hidden>> wrote:

> @Peter: yes, this is targeted at OTA-12, the change that makes the front
> camera the default for the browser app and webapp container is currently
> in a silo, has been tested and approved, and should be landing this
> week.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1563398
>
> Title:
> Set the front camera as the default for video media requests
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1563398/+subscriptions
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+16.10.20160620-0ubuntu1

---------------
webbrowser-app (0.23+16.10.20160620-0ubuntu1) yakkety; urgency=medium

  * Set the front camera as the default for video media requests (LP:
    #1563398)
  * Handle theme color change and properly update browsing widgets (LP:
    #1567430)
  * Properly propagate touchscreen detection flag (LP: #1585689)
  * Print help when no app-id is present (LP: #1591306)

 -- Alexandre Abreu <email address hidden> Mon, 20 Jun 2016 15:08:41 +0000

[Peter Bittner (peter-bittner)]

@David: You wanted to refer to bug 1535820 (the leading 1 slipped away in your email). The video image orientation is a hard bug now, which makes it impossible to use WebRTC services on Ubuntu Touch. :-(

Hope we get this fixed in OTA-14 somehow.

[Pat McGowan (pat-mcgowan)]

@peter we are fixing the E5 orientation problem as we speak for ota13

[Peter Bittner (peter-bittner)]

@pat OTA-13 is out, and unfortunately WebRTC applications such as Talky.io and Appear.in still suffer from an upside-down image displayed from the person using Ubuntu Touch. Tested with bq Aquaris E5 Ubuntu Edition. See also bug 1535820. Do you think this can be fixed for OTA-14?

Test drive:
- https://talky.io/ubuntu-phone
- https://appear.in/ubuntu-phone