1277984 - Jitsi Meet does not work in Firefox 47

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P1)

Description

[Adam Roach [:abr]]

Using Firefox 47, calls with Jitsi Meet appear to reliably fail.

STR:
1. Go to https://meet.jit.si/z9hg4bk
2. Grant access to microphone
3. Grant access to camera

At this point, note the lack of self-view.

4. On a different machine, go to https://meet.jit.si/z9hg4bk
5. Grant access to microphone
6. Grant access to camera

Note that neither side can see the other.

If you twiddle the "mute camera" button a few times, you can cause a self-view to appear. Sometimes this will cause media to be transmitted to the far end.

Bug 1247244 would imply that this is a regression that occurred in the past couple of versions of Firefox.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Tried with Window 47 final-beta (buildid 20160604121506), linux inbound from a few days ago (local debug build), Mac Nightly from 5/20 and from 6/6.  All worked for me (and for mreavy on Windows, and bar on nightly (mac)).  Other people have persistent failures (abr on 47, ekr on 49).  Others see mostly success (jib)

clearly there's something timing/perf/environment dependent here.  I strongly suspect timing holes with assumptions about DOM event ordering or signaling timing.  Self-view failure for some and not others also clearly points in this direction - especially when it sends video and doesn't show the self-image.

We see many errors and warnings on a debug build on the console about DOM event issues and XML parsing problems, and other interesting messages on the Browser Console.

Since "mute camera" likely is just doing track.enabled=false/true, that should have no real likelihood of fixing this problem, if it was a bug in the underlying code. 

It's possible we're violating the spec on event timing/ordering, or haven't implemented some aspect they're indirectly relying on now, but we'll need more info to make such a claim.

We should see if Jitsi can repro and what their debugging tells them about what happened or didn't - much easier to debug your own code.

Comment 2

[Nils Ohlmeier [:drno]]

This sounds to me like a dupe of bug 1273652, just that Adam seems to be able to trigger the black video a lot more often. I have never seen black video on the self view.

Comment 3

[Maire Reavy [:mreavy]]

I think there's more going on than what's observed in bug 1273652 to cause what's abr is seeing, but until we get to the root cause, we don't know.

Randell, Nils -- I'd like you both to do a deeper dive on this and bug 1273652 this week.  I'm going to try to get Emil and his folks to come to irc later today.

Comment 4

[Nils Ohlmeier [:drno]]

It turned out that Adam had media.autoplay.enabled set to false (default is true) and therefore had to manually click each video player element manually to start playing the content.

Comment 5

[Adam Roach [:abr]]

(In reply to Nils Ohlmeier [:drno] from comment #4)
> It turned out that Adam had media.autoplay.enabled set to false (default is
> true) and therefore had to manually click each video player element manually
> to start playing the content.

And the way the jitsi page is laid out, you can't actually perform these clicks.

Note that Fennec exposes this as a user-visible switch, so websites should at least be capable of working correctly when it it set to "false":

https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/xml/preferences_advanced.xml#63

The way to make this happen correctly is to call play() on the video element rather than using the "autoplay" attribute.