1543194 - Error message when User tries to set avatar image with Camera option.

Status: VERIFIED FIXED

(Core :: WebRTC, defect)

Description

[Luciana queirolo]

Attachment: CAMERA ERROR.PNG

Note

• Tested on a laptop Lenovo with integrated camera.

Affected versions

• Nightly 68.0a1 (2019-04-05)

Affected platforms

• Windows 10

Steps to reproduce

1. Click on Avatar icon.
2. When expanded, click on image icon.
3. Select Camera option.

Expected result

• User is able to set an avatar image using camera option.

Actual result

• Error message when User tries to set avatar image with Camera option.

Comment 1

[Dan Minor [:dminor]]

From https://bugzilla.mozilla.org/show_bug.cgi?id=1539220#c34 it sounds like the camera is working properly on https://mozilla.github.io/webrtc-landing/gum_test.html.

Comment 2

[Dan Minor [:dminor]]

:jib, do you mind having a quick look at this one? In Bug 1539220, I worked around a crash when Luciana is accessing the integrated camera on her laptop. It sounds like things are now working properly on the gum_test page, but not when she tries to set an avatar on a firefox account.

It is working as expected on my windows laptop, so I'm guessing there is still something specific to her camera that is causing problems.

Comment 3

[:Gijs (he/him)]

67 is marked as unaffected, what happens there? The crash that got reported elsewhere? Or something else?

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Having read through bug 1539220, it sounds like getUserMedia can no longer find a workable resolution after the fix, on some systems—this seems to all come down to what camera one has.

I'm a bit concerned the fix is overreaching:

    if (capability.videoType != VideoType::kRGB24) {
      hasNonRGB24Capability = true;
    }

Considering all the possible values of videoType—even kUnknown. It seems to me this might cause -1 to be returned on some systems where before it would succeed, which would match the new symptom I suppose? Or were constraints involved?

A narrower/safer fix might have been. e.g.:

if (capability.videoType != VideoType::kRGB24 && isAKnownGoodVideoTypeThatWontCauseAMinusReturnBelow(capability.videoType)) {
  hasNonRGB24Capability = true;
}

Comment 5

[Dan Minor [:dminor]]

I discussed this with :jib a bit on IRC and it sounds like what might be happening is that additional constraints being applied in the Firefox accounts case cause us to choose a non-functional format. That would explain why the webrtc-landing test works but not Firefox accounts.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I did a MOZ_LOG_MODULES=MediaManager:5 on the Firefox accounts page and it looks like an unconstrained gUM call to me, so now the difference between the two pages eludes me.

Luciana, can you confirm that your camera works in https://jsfiddle.net/jib1/r60bzmrs/ yet not in the Firefox accounts page?

Comment 7

[Luciana queirolo]

Hi Jan-ivar,

Tried to reproduce this issue on the latest Nightly 68.0a1 (2019-04-12)and I was not able to on FxA accounts page and on https://jsfiddle.net/jib1/r60bzmrs/

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This is marked as affecting 67. Does it work there as well? If so, we can close this.

Comment 9

[Luciana queirolo]

Hi Jan-Ivar

tried it on Beta 67.0b14 and it works fine :)

Comment 10

[Luciana queirolo]

Hi Dan Minor,

The issue is no longer reproducible on Nightly 68.0a1 (2019-05-03) and on Beta 67.0b15, I will change the flags accordingly and the status of this ticket.

Also discovered while changing the avatar picture using the camera on Nightly 68.0a1 (2019-05-03)that the browser console showed a warning.
Should I create an individual ticket for this??

nsLoginManager: searchLogins: formSubmitURL or httpRealm is recommended 2 LoginManager.jsm:406:13
Invalid chrome URI: /

Comment 11

[Dan Minor [:dminor]]

Hi Luciana,

Thanks for verifying this! I'm not sure if that warning is important or not, it is probably safest to create a new ticket in Toolkit::Password Manager and let them triage it.