Closed Bug 1413859 Opened 7 years ago Closed 7 years ago

On Nightly builds video is not working when using Facebook video calls

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

58 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox56 --- unaffected
firefox57 --- unaffected
firefox58 + fixed

People

(Reporter: mboldan, Assigned: pehrsons)

References

Details

(Keywords: regression, site-compat)

[Affected versions]:
- Firefox 58.0a1 (2017-11-01)

[Affected platforms]:
- Windows 10x64, macOS 10.12.6, Ubuntu 14.04x64

[Steps to reproduce]:
1. Launch a Nightly build.
2. Go to Facebook.com and login with a valid user.
3. Perform a video call.

[Expected result]:
- The video call is correctly performed and the user are able to see and hear each other. 

[Actual result]:
- The nightly user can't be seen by the other user.
- On latest builds, the nightly user is also not able to hear the other user(see the regression range section) and in the first phase, both, microphone and webcam are requested, and while loading, the request for microphone is displayed again, without the camera request.

[Regression range]:
- This is not a recent regression since the video for the nightly user is not displayed also on Firefox 47.0a1 (2016-02-04).  
- Here is the regression range for the build where only the microphone is requested and where the Nightly user is not able to hear the other users:
     - build_date: 2017-10-23 15:37:00.021000
     - pushlog - https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=62617c6d5534053189a8497fa4705d5b0466e771&tochange=1bbadf4957058dffcdf6efb74e03828ebc4487a6
     - build url - https://queue.taskcluster.net/v1/task/EheL0P66Q1eeEJV2e0RvqQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip

[Additional notes]:
- This issue is not reproducible on Firefox 56.0.2, or on Firefox 57.0b13
- Note that the Nightly user is able to see the other user when using Facebook video calls.
Component: Audio/Video: Playback → WebRTC
I can repro on Ubuntu with Nightly 58 from Nov 3rd. Nightly 58 from Oct 2nd was not affected. Thus I'd say this is a recent regression.

[Tracking Requested - why for this release]:
Camera doesn't function in Facebook video calls, seemingly across all platforms, in 58.
Rank: 3
Component: WebRTC → WebRTC: Audio/Video
Priority: -- → P1
Assignee: nobody → apehrson
They request gUM with constraints
> { audio: true,
>   video: {"height":{"min":180,"max":720,"ideal":480},
>           "width":{"min":320,"max":1280,"ideal":853.3333333333334},
>            "frameRate":{"min":10,"max":30,"ideal":30}
>          }
> }

This seems successful and fine. Then something happens and they drop the stream and request a new {audio: true, video: false} one.
(In reply to Mihai Boldan, QA [:mboldan] from comment #0)
> [Regression range]:
> - This is not a recent regression since the video for the nightly user is
> not displayed also on Firefox 47.0a1 (2016-02-04).  
> - Here is the regression range for the build where only the microphone is
> requested and where the Nightly user is not able to hear the other users:
>      - build_date: 2017-10-23 15:37:00.021000
>      - pushlog -
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=62617c6d5534053189a8497fa4705d5b0466e771&tochange=1bba
> df4957058dffcdf6efb74e03828ebc4487a6
>      - build url -
> https://queue.taskcluster.net/v1/task/EheL0P66Q1eeEJV2e0RvqQ/runs/0/
> artifacts/public%2Fbuild%2Ftarget.zip

I got a similar range for the video issue, but more narrow: Bug 1183495 - part3: Remove mozSrcObject usage. r=jwwang
It makes sense that it's broken with that push if they're relying on mozSrcObject.

Anthony, do you have a contact at Facebook you can reach out to?
Blocks: 1183495
Flags: needinfo?(ajones)
Keywords: site-compat
I've reached out to facebook with the details from Pehrsons (thanks!).
Flags: needinfo?(ajones)
let's track to make sure this gets addressed before we ship
Thanks for the report - fix should be out really soon :)
Thanks. I just tested and Messenger is working again for me. I'm closing this as WORKSFORME since it was not a Firefox issue.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
See Also: → 1413838
ACK, fixed on our side.
You need to log in before you can comment on or make changes to this bug.