Closed Bug 1525209 Opened 5 years ago Closed 5 years ago

WebRTC video playback doesn't work in Firefox while working in other browsers

Categories

(Core :: Audio/Video: Playback, defect, P2)

65 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
geckoview66 --- wontfix
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- verified
firefox68 --- verified

People

(Reporter: mershtein, Assigned: pehrsons)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36

Steps to reproduce:

http://umediaserver.net/umediaserver/demohtml5WebRTCplayer.html

"ICE failed" - bug in Firefox

Actual results:

doesn't play

Expected results:

Should play like any other browser.
It did work in Firefox in previous versions, like 6 months ago.
There is no reason for ICE to fail - a valid candidate is offered, but Firefox doesn't use it for some reason.

It would be useful if you could find the regression range.
https://mozilla.github.io/mozregression/quickstart.html

Has Regression Range: --- → no
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core

This works for me on nightly. Can you attach a saved about:webrtc to this bug? This is likely to be related to the ip-handling draft because there is no getUserMedia request.

Flags: needinfo?(mershtein)

Yeah, you aren't using a STUN server here either.

Also, what version of Firefox are you using here?

Sorry guys, this appears to be not easy to reproduce.
Happened yesterday consistently, but doesn't happen today. Not sure what to tell you.
My internet connection might have glitched yesterday; although, at the same time other browsers worked.
I will post more info if I have it to reproduce again.

Flags: needinfo?(mershtein)

Worked for me as well right away. If it happens again please attach a copy of about:webrtc here.

Any progress on reproducing?

Flags: needinfo?(mershtein)

Hi guys,

So the actual error that everyone should be able to reproduce is:
open that webpage and it plays; then click on pause button.

Then click on Play button again, and here you see the problem.
That functionality works in any other browser.

Here are console messages:

Firefox can’t establish a connection to the server at ws://65.23.154.147/webrtc_playnow/singleport/tcp/livedemocam. unrealwebrtcplayer.js:120:17
AbortError: The fetching process for the media resource was aborted by the user agent at the user's request. unrealwebrtcplayer.js:20
The connection to ws://65.23.154.147/webrtc_playnow/singleport/tcp/livedemocam was interrupted while the page was loading.

I have the same error happening on local webpages instantly, right after page loads, when it communicates to local server,
so that connection is established very fast. So it seems like there are some race conditions, or something of that nature.

Flags: needinfo?(mershtein)

Byron, I just reproduced this on my desktop machines following the steps in comment 8.

Flags: needinfo?(docfaraday)

Yeah, the steps in comment 8 don't result in video playing again, but hitting pause closes the PeerConnection, and hitting play again does not open a new one. This does not look like a webrtc problem to me.

Flags: needinfo?(docfaraday)

Byron,

Did you care to look in the console after you click on Play button?

The problem is line 20 of unrealwebrtcplayer.js:
remoteVideo.srcObject = null;

When you hit the play button, that line throws an exception, and therefore, no new PeerConnection is created, and you see this message in the console:
AbortError: The fetching process for the media resource was aborted by the user agent at the user's request. unrealwebrtcplayer.js:20

However, if you set a breakpoint on that line 20, then everything works fine! No exceptions, and stream plays.

There are definitely some timing issues/race conditions there; it all works in all other browsers than Firefox.

I looked in the console, but this is not a webrtc issue. The first error I see is where the websocket is created in DoSignaling. That's the error you probably need to be looking into.

No that's not the first error.

The first error is line 20, and it happens before websocket connection is created:
AbortError: The fetching process for the media resource was aborted by the user agent at the user's request. unrealwebrtcplayer.js:20

Then the websocket connection is simply interrupted by Firefox because of line 20 exception.

You can't get to the DoSignaling call (on line 26, the only place that function is called) if line 20 throws and there's no catch. Also, the first error reported in the console is from inside the DoSignaling call.

Byron,

The real cause for this issue is line 20 of the script:
remoteVideo.srcObject = null;

I just removed that line from the script (on my local script here) and everything works fine.
Put this line back and issue starts to appear again.

So that line must be doing something very evil in Firefox.

We need that line to clear the picture on the player, so we get a black window with a spinning loader.
That's how it works in all other browsers. Previously we tried to execute that line when terminating PeerConnection,
but that didn't work in Firefox either.

Maybe there is a MediaStreamGraph bug you're tripping over here, but that would be a separate bug. @pehrsons, are there any known problems with nulling out srcObject causing websocket connections to fall down, even when they aren't feeding that media element?

Flags: needinfo?(apehrson)

Well, I am thinking more of timing issues because you don't even need to remove that line -
just set a breakpoint on it, and things start working.

Sorry, cannot edit Comment 17:
You need to set a breakpoint somewhere past that line, for example on line 21, then everything works.
So clearly line 20 needs some time to execute, then all is good.

(In reply to Byron Campen [:bwc] from comment #16)

Maybe there is a MediaStreamGraph bug you're tripping over here, but that would be a separate bug. @pehrsons, are there any known problems with nulling out srcObject causing websocket connections to fall down, even when they aren't feeding that media element?

No known problems. I don't see how websockets and media element (or MediaStream) are even related.

(In reply to umedia from comment #15)

Byron,

The real cause for this issue is line 20 of the script:
remoteVideo.srcObject = null;

I just removed that line from the script (on my local script here) and everything works fine.
Put this line back and issue starts to appear again.

So that line must be doing something very evil in Firefox.

We need that line to clear the picture on the player, so we get a black window with a spinning loader.
That's how it works in all other browsers. Previously we tried to execute that line when terminating PeerConnection,
but that didn't work in Firefox either.

This cannot be. I suspect that the error you're seeing is bug 1507193, a js promise was rejected but not handled (we didn't expose it to js, just used it internally) so it got logged to the console.

If you tell the debugger to break on exceptions you'll see that it doesn't break on line 20.

If you tell the debugger to break after line 20, for instance on DoSignaling() on line 26 it does this despite of the logged error.

I started writing this comment after having tried the above and noticed that it did break on another exception later instead:
I got the response "H264|-|-|" on the websocket (line 129, strArr is ["H264", ""]), and ended up on line 171 calling JSON.parse("H264") which resulted in SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data. Perhaps this indicates a real problem?

Flags: needinfo?(apehrson) → needinfo?(mershtein)

Yes I also have seen the weird JSON.parse exception, and I think this is caused by previous problem
caused by line 20. The state is completely screwed when this JSON.parse exception happens; this code shouldn't even be executed.
Variable "state" has invalid value at this point.

So what leads to that situation is line 20. Yes it doesn't throw an exception. But it causes console error messages,
websocket errors and weird state, and not consistently the same way.

Again, what you should be checking is - put a breakpoint on line 21 and do the test. Everything works.
Run without the breakpoint and it breaks. That should give you some clues.

Flags: needinfo?(mershtein)

(In reply to Andreas Pehrson [:pehrsons] from comment #19)

(In reply to Byron Campen [:bwc] from comment #16)

Maybe there is a MediaStreamGraph bug you're tripping over here, but that would be a separate bug. @pehrsons, are there any known problems with nulling out srcObject causing websocket connections to fall down, even when they aren't feeding that media element?

No known problems. I don't see how websockets and media element (or MediaStream) are even related.

It seems super weird to me too, but the error that is showing up in the console:

"The fetching process for the media resource was aborted by the user agent"

This maps to NS_ERROR_DOM_MEDIA_ABORT_ERR:

https://searchfox.org/mozilla-central/rev/44a212460990ffffecf50a8e972d3cbde2e7216b/dom/base/domerr.msg#151

This error is thrown in not many places:

https://searchfox.org/mozilla-central/search?q=NS_ERROR_DOM_MEDIA_ABORT_ERR&redirect=false

Of particular suspicion is this instance, thrown from a function named "AbortExistingLoads"

https://searchfox.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp#1851

This function seems to be aborting network activity, presumably in order to not waste resources continuing to load media. I wonder if there's a bug in this code that causes the WebSocket to be closed?

^

Flags: needinfo?(cpearce)

I debugged your JS a bit further.

You're sometimes getting the event "play" followed by "pause" after play()ing the video element, for some reason. I need to dig deeper to understand why, but that "pause" makes your code Terminate() both peer connection and web socket, and your app gets into a bad state.

Component: WebRTC: Networking → WebRTC: Audio/Video
Flags: needinfo?(cpearce)

Andreas,

Correct, I observed the same: pause is called for some reason. The huge question, though, is - when you put a breakpoint on line 21 (or just remove line 20), that doesn't happen.

So yes, this call to pause is the root cause for websockets closing and the rest of weird exceptions.

Bumping this while triaging. Andreas, is further investigation required to confirm this?

Flags: needinfo?(apehrson)

Yes, we need to see where the "pause" event comes from and whether there's a bug involved. I haven't had time to look at this further.

Flags: needinfo?(apehrson)

Yes, the pause event is the cause of this issue, and it's definitely a bug. Firefox fires this pause event inconsistently,
timing is involved.

So, re-setting srcObject is supposed to run the media element load algorithm:

https://www.w3.org/TR/html52/single-page.html#location-of-the-media-resource

One of the steps of this algorithm is to pause the media element:

https://www.w3.org/TR/html52/single-page.html#media-element-load-algorithm

However, I do not see any language that says a pause event should be fired in this specific case.

Using the STR from comment 0, I have attempted to reproduce the issue to attempt to find it's regressor, but my results seem a bit different.

I have tried the following browsers: Chrome, EDGE, IE11, Opera, Firefox ESR (v60.6.1), Firefox Release (v66.0.2), Firefox Beta (v67.0b9) and Firefox Nightly (v68.0a1). Only one of all did load the streamed video consistently, EDGE. However, While giving every browser a minimum of 2 attempts, Firefox Beta, once showed the video; could not reproduce it after many other page reloads.

In conclusion, this issue seems somewhat INTERMITTENT. Do you have any idea what could have caused it to work ONCE in BETA?
Also, is this test page actually valid? (considering the low working rate on the several browsers and browser versions?

Please NI me if further testing is needed.

Flags: needinfo?(jib)
QA Whiteboard: [qa-regression-triage]

The link in comment 0 is pretty consistent for me in Nightly, but note that the reproducible STR is in comment 8, using the link from comment 0.

Flags: needinfo?(jib) → needinfo?(daniel.bodea)

(In reply to umedia from comment #8)

Hi guys,

So the actual error that everyone should be able to reproduce is:
open that webpage and it plays; then click on pause button.

Then click on Play button again, and here you see the problem.
That functionality works in any other browser.

Here are console messages:

Firefox can’t establish a connection to the server at ws://65.23.154.147/webrtc_playnow/singleport/tcp/livedemocam. unrealwebrtcplayer.js:120:17
AbortError: The fetching process for the media resource was aborted by the user agent at the user's request. unrealwebrtcplayer.js:20
The connection to ws://65.23.154.147/webrtc_playnow/singleport/tcp/livedemocam was interrupted while the page was loading.

I have the same error happening on local webpages instantly, right after page loads, when it communicates to local server,
so that connection is established very fast. So it seems like there are some race conditions, or something of that nature.

Considering the STR present in comment 8 copied above, it is supposed to play the streamed video at load. It does not do that in my case. It ONLY shows the streamed video in EDGE browser consistently.

@Andreas: Does the link from comment 0 actually play the streamed video for you in Nightly (on a clean profile)?

Flags: needinfo?(daniel.bodea) → needinfo?(apehrson)

Daniel Bodea:

It's not a first time I hear that people from softvision cannot play this webpage; people in your Henderson, Nevada office,
also can't play that webpage. So Daniel, it's your company issue, seems like your company policy involving proxy servers or some other policies, just prohibit WebRTC, and yes, some browsers work, others do not.

It does work for me. Perhaps what Byron said in comment 2 is complicating it for you Daniel, as there's no gUM request, the network paths we allow are limited. Byron, can he disable this easily somehow?

Flags: needinfo?(apehrson) → needinfo?(docfaraday)

There's no pref that can loosen the ip-handling rules, only prefs that can tighten them.

Flags: needinfo?(docfaraday)

After trying the LATEST version of Nightly (build ID: 20190410100020) it appears it is now loading the streaming video correctly. This considered, I have attempted to perform a mozrefression (find fix) between the build of 10th of April (good build) and 8th of April (bad build), the process stops with "Unable to bisect" error after only 2 builds. The relevant console messages:

"2019-04-10T17:28:17: INFO : Narrowed inbound regression window from [9982d52f, a1eb490b] (3 builds) to [d272180e, a1eb490b] (2 builds) (~1 steps left)
2019-04-10T17:28:17: DEBUG : Starting merge handling...
2019-04-10T17:28:17: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=a1eb490ba4480b756fcc4f92f8dbc753c66d7900&full=1
2019-04-10T17:28:18: DEBUG : Found commit message:
Merge inbound to mozilla-central. a=merge

2019-04-10T17:28:18: DEBUG : This is a merge from mozilla-inbound
2019-04-10T17:28:18: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=ea65b4513b3b38101fa2b18816e0284309df5831
2019-04-10T17:28:18: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=ea65b4513b3b38101fa2b18816e0284309df5831&tochange=0d9193a6224f7ac96209fa3d0824cf4a94fe8812
2019-04-10T17:28:18: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?startID=112734&endID=112742
2019-04-10T17:28:19: INFO : ************* Switching to mozilla-inbound
2019-04-10T17:28:19: DEBUG : End merge handling
...
2019-04-10T17:29:18: WARNING : Skipping build 6e0ac51de4d2: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-inbound.revision.6e0ac51de4d2738e105a1c9c97a07f605c624d69.firefox.win64-opt'
...
2019-04-10T17:30:08: INFO : Stopped
"

I don't think this helps much. If I can still help, please tell me how.

Considering comment 32, i will come back tomorrow with a report of a test done on an external network.

I have attempted to test this issue again on some other test machines that are linked to the internet through an external network that avoids the company-specific proxies. The results are the same. This issue seems NOT to be proxy-related AND it also seems intermittent. It WILL randomly connect to the streaming video and show it, but very rarely on a random browser version. It ONLY consistently shows the streaming video in EDGE browser.

As a conclusion, this issue may not behave the same way as it did for the reporter OR there's something wrong with the WebRTC.

P.S. Considering yesterday's tests it seems that the video worked for that build (20190410100020), but it does not anymore for the latest. Furthermore, I tried the exact same build (20190410100020) and it does not show the streaming video anymore today. This issue is certanly not testable from here so I will retire from this bug's discussion.

Daniel,

When the page doesn't load the video, per Comment 2, Can you attach a saved about:webrtc?

Also, Daniel, it would be nice if you attach a Wireshark capture. I don't understand much what Andreas means by
"as there's no gUM request, the network paths we allow are limited" so really wonder what can prevent your computer
from playing that feed, especially given that Edge plays consistently. And latest Chrome doesn't work as well?
Really a mystery. Maybe related to your particular computer that runs some strange firewall type protection software, or WebRTC blocking add-ons in browsers?

Attached file about-webrtc.txt

This is the about:webrtc log saved while accessing the page and attempting to play the video in the test link on both a test machine that is going through the company-specific proxies and on a test machine that is on the external network.

The behavior on my side is certainly NOT linked to add-ons since I always ran on clean profiles.
It is also not linked to a certain computer since the behavior is similar on different computers and on different networks.

I will have to refuse to attach a Wireshark capture because it is quite complicated and I need pointers.

NI me or the reporter of further testing is needed.

Your about-webrtc.txt is very weird.
How UDP socket is involved here? This webpage uses WebRTC via TCP, so no UDP should be involved at all.
And other messages about failure to create a passive TCP socket are also strange.

(In reply to umedia from comment #42)

Your about-webrtc.txt is very weird.
How UDP socket is involved here? This webpage uses WebRTC via TCP, so no UDP should be involved at all.
And other messages about failure to create a passive TCP socket are also strange.

The about webrtc is pretty normal. Just because your side of the PeerConnection only provides a TCP candidate doesn't mean that Firefox will not gather UDP ICE candidates.
And you can safely ignore the TCP error, they are an artifact of Firefox not gathering TCP passive candidates.

jya who is our expert on media element state machine and knows about differences in sending paused events between Chrome and Firefox?

Flags: needinfo?(jyavenard)

Trying to reproduce this in a local Nightly under rr I am not able to establish a connection.

From the websocket we first receive "H264|-|-|", then "Error: Initialization of peer connection failed". The second message leads to Terminate() and alert("Error: Initialization of peer connection failed").

It still works in my regular Ubuntu Nightly, so some timing issue is perhaps behind this?

I've debugged a bit by adding logs.

I see this sequence of events and actions:

  • pause() (1) happens, after user click from the STR in comment 8.
  • this leads to an async "pause" event, and in the handler there's another pause(), which is ignored since we're already paused.
  • in the "pause" handler, the peer connection is closed, so the MediaStreamTrack ends and the media element ends playback, fires "ended", and, readyState reaches HAVE_CURRENT_DATA.

Some time passes..

  • play() happens, after user click from the STR in comment 8.
  • this starts playback of the MediaStream, and fires an async "play" event
  • in the "play" handler the srcObject property is set to null, and signaling is initiated.
  • Setting srcObject to null runs DoLoad() at [1], which does AbortExistingLoads() at [2], which fires "pause" at [3] (sync with setting the srcObject).
  • in the "pause" handler, the media element is again pause()ed, and the peer connection is also closed.

This doesn't seem intuitively wrong, but I need to compare to spec. My first thought is whether setting srcObject to null should lead to aborting the existing loads, and firing "pause", synchronously or not.

[1] https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/dom/html/HTMLMediaElement.cpp#1677
[2] https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/dom/html/HTMLMediaElement.cpp#2037
[3] https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/dom/html/HTMLMediaElement.cpp#1850

(In reply to Andreas Pehrson [:pehrsons] from comment #46)

  • Setting srcObject to null runs DoLoad() at [1], which does AbortExistingLoads() at [2], which fires "pause" at [3] (sync with setting the srcObject).

The spec says this about the pausing in the load algorithm:

  1. If the paused attribute is false, then:
    1. Set the paused attribute to true.
    2. Take pending play promises and reject pending play promises with the result and an "AbortError" DOMException.

However, our code in addition to those two steps also fires "paused", [4]. This looks like a bug in our implementation.

This was added in [5] as part of bug 1461877. Chris, seeing that you added that, can you take a look? I don't see from that commit message why there was a need to dispatch "pause".

[4] https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/dom/html/HTMLMediaElement.cpp#1850
[5] https://hg.mozilla.org/mozreview/gecko/rev/d51aee3f128bb3984e3f50e466a03f74215bfe2c#index_header

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jyavenard) → needinfo?(cpearce)
Priority: -- → P2
Regressed by: 1461877

(In reply to Andreas Pehrson [:pehrsons] from comment #47)

This was added in [5] as part of bug 1461877. Chris, seeing that you added that, can you take a look? I don't see from that commit message why there was a need to dispatch "pause".

If I recall correctly, I added this because I thought it was weird that we'd change the paused state and not fire a paused event.

You're right that the spec doesn't call for the event to be fired in this case. I tested and removing that pause event doesn't regress the case I was concerned about in bug 1461877, so I think we can remove it.

Flags: needinfo?(cpearce)

Thanks! This should be an easy fix then.

Assignee: nobody → apehrson
Status: NEW → ASSIGNED
Component: WebRTC: Audio/Video → Audio/Video: Playback
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/46235152b24e
Revert spec-incompliant pause event from bug 1461877. r=cpearce
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Comment on attachment 9058884 [details]
Bug 1525209 - Revert spec-incompliant pause event from bug 1461877. r?cpearce

Beta/Release Uplift Approval Request

  • User impact if declined: Media applications can break unexpectedly
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 8
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is removing a js-observable event that was added by mistake in 62 and at that point diverged from other browser implementations. This restores behavior to spec and competition.
  • String changes made/needed:
Attachment #9058884 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-regression-triage] → [qa-regression-triage][qa-triaged]

Comment on attachment 9058884 [details]
Bug 1525209 - Revert spec-incompliant pause event from bug 1461877. r?cpearce

Low risk one-liner fix, uplift approved for 67 beta 13, thanks.

Attachment #9058884 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified, that the issue is no longer reproducible on Nightly 68(20190419094745). Tested on Win10 x64, MacOS 10.13 and Ubuntu 18.04 with STR from comment 8

Thank you for fixing this, guys.

One thing I would like to clarify is - why Daniel Bodea and other people from Softvision (both Romania and Nevada offices)
couldn't have this video playing at all. This question is more than Firefox - other browsers have problems too.
And it's not just this webpage, we occasionally hear the same complaints from some users, and it's not clear what's special on their computers that prevents them to play via WebRTC.

Byron and Andreas refer to "This is likely to be related to the ip-handling draft because there is no getUserMedia request."

So that draft:
https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-11
still allows direct peer connections in Mode 2 which should be used when there is no getUserMedia request.

This webpage receives via signaling a single candidate with server's public endpoint, so why a browser wouldn't connect to that endpoint?
So the signaling via websocket did connect to the same IP address (same server software handles signaling, no TURN/STUN servers are involved at all; it's the simplest of all situations), but WebRTC wouldn't connect to the same IP address? Howcome?
Why Edge consistently worked for Daniel while other browsers didn't?

Any ideas?

It could be related to VPN, but it is hard to say for sure. I would have to see packet captures.

I can also confirm that the error mentioned in comment 8 is not occurring anymore in Nightly v68.0a1 from 2019-05-13. I will say this because in about 8/10 times on 3 different test machines, the video would load and it could correctly be paused and resumed without any errors. The video loading or not is still somewhat intermittent.

Unfortunately, I can not say the same in the case of Beta v67.0b19 (64-bit) as the video does not load at all (Browser Console gives the error "AbortError: The fetching process for the media resource was aborted by the user agent at the user's request.") and the video does not load at all on 3 different test machines.

I am not confident enough to test this further. If I will receive guidance, I can continue. I have to mention, again, the fact that the issue does not seem to be related to the company proxy settings because the same behavior is seen on a test machine connected to the external network.

In conclusion, the fix can be verified in Nightly, but not in Beta.

Flags: needinfo?(apehrson)

I also tested this on beta (buildid 20190516215225) and it worked for me 3 of 3 times.

What you're seeing failing might be something else. If you can't load the video on beta but you can on Nightly on the same machine, perhaps run mozregression to identify the fix?

I deem this bug verified on Nightly 68 and beta 67.

Flags: needinfo?(apehrson)

I have attempted to find this fix using mozregression, but unfortunately, ALL BUILDS failed to open the streaming video. It appears as WebRTC does not work through mozregression builds. I don't know how to investigate this forward.

Status: RESOLVED → VERIFIED

(In reply to Bodea Daniel [:danibodea] from comment #61)

I have attempted to find this fix using mozregression, but unfortunately, ALL BUILDS failed to open the streaming video. It appears as WebRTC does not work through mozregression builds. I don't know how to investigate this forward.

Ah, I debugged this a bit. So when you start a build through mozregression on a fresh profile you don't have the OpenH264 plugin installed yet. The service relies on H264 for its broadcast but if missing sends an SDP with VP8 and VP9 in it only. The server dislikes this and sends an error back.

If you wait for OpenH264 to be installed (see about:addons) it works.

It's probably easiest to run mozregression on an existing profile, or re-use the one it installs OpenH264 into.

Flags: needinfo?(daniel.bodea)

That was it! The H264 video codec would take some time to get installed. After that, I could properly verify the fix in Beta, also. Thank you, Andreas, for clearing up this major confusion.

Flags: needinfo?(daniel.bodea)
QA Whiteboard: [qa-regression-triage][qa-triaged]
Flags: qe-verify+

This is definitely fixed in Firefox 67.
Thank you guys!

One more question - Firefox does not honor remote candidates with vEthernet (HyperV) addresses.
Is that by design? Why? Chrome can use these just fine.
If I provide a candidate with vEthernet address, then Firefox is unable to connect to it; I get "ICE failed" error.

Back when we implemented IPv6 support, we filtered out IPv6 link-local addresses. In bug 1219557, this filtering was expanded to include RFC 3927 addresses (IPv4 addresses in the 169.254/16 range).

Hmmm, that RFC doesn't say anything about 172.... addresses;
my vEthernet address is 172.26.112.97, and Firefox wouldn't honor a remote candidate with that address, while Chrome works fine.
On a local machine, the machine name, unfortunately, resolves to that address, not to my real NIC address.
I have a docking station, so I can't just disable vEthernet.

172.26 is part of a private address range, and Firefox will not pair it with addresses that are not within that range.

So Firefox does not generate local candidates of 172.26... and therefore will not pair with remote candidate of that range?
Do I understand you correctly? If so, why Firefox wouldn't generate local candidates of 172.26... range?
My "localhost" also resolves to 172.26.112.97, so when I browse to our web apps as localhost, I also bump into this issue.

Another issue is Firefox's autoplay policy (sorry that I bring all these things up in this thread; I am now testing a number of our WebRTC web applications (eLecture, uVMS), and while working fine in Chrome, I notice issues in Firefox.)
So, Chrome's autoplay policy is like this: if you already interacted with domain - for example, logged in, then the non-muted video elements can auto-play video with sound, no problem. And that's the right thing to do. However, in Firefox, even when I log in to the web app, the non-muted live video (WebRTC or MSE) does not play until I click on Play button in the player. Does this sound right to you?
Example: navigate to http://umediaserver.net/uVMSDemo.html
Click on "Enter Demo"
On the very top camera "BigBuckBunny RTSP", click on "HTML5 MSE player"

(In reply to umedia from comment #68)

So Firefox does not generate local candidates of 172.26... and therefore will not pair with remote candidate of that range?
Do I understand you correctly? If so, why Firefox wouldn't generate local candidates of 172.26... range?
My "localhost" also resolves to 172.26.112.97, so when I browse to our web apps as localhost, I also bump into this issue.

I would expect Firefox to gather those 172.26 local candidates, but only if audio or video capture permission has been granted. Fixing bug 1506219 would make this work without capture permissions if the web page is loaded with the 172.26 interface.

Another issue is Firefox's autoplay policy (sorry that I bring all these things up in this thread; I am now testing a number of our WebRTC web applications (eLecture, uVMS), and while working fine in Chrome, I notice issues in Firefox.)
So, Chrome's autoplay policy is like this: if you already interacted with domain - for example, logged in, then the non-muted video elements can auto-play video with sound, no problem. And that's the right thing to do. However, in Firefox, even when I log in to the web app, the non-muted live video (WebRTC or MSE) does not play until I click on Play button in the player. Does this sound right to you?
Example: navigate to http://umediaserver.net/uVMSDemo.html
Click on "Enter Demo"
On the very top camera "BigBuckBunny RTSP", click on "HTML5 MSE player"

My understanding is that we are deliberately being more restrictive with the blocking of autoplay than Chrome is.

So 172.26.112.97 doesn't currently work, but my real NIC's IP address: 10.200.0.128 works just fine in Firefox. Why is that?
172.26.112.97 doesn't have any default gateway, while 10.200.0.128 does. That's the only difference I can see.

(In reply to umedia from comment #70)

So 172.26.112.97 doesn't currently work, but my real NIC's IP address: 10.200.0.128 works just fine in Firefox. Why is that?
172.26.112.97 doesn't have any default gateway, while 10.200.0.128 does. That's the only difference I can see.

Probably because 172.26.112.97 is not the default route on your machine (ie; what your machine uses to reach the internet), and your app does not request capture permissions. A previous version of the ip-handling draft (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/) said that if no capture permissions are granted, the browser may only use the default route's IP address in its host candidates, as a privacy protection measure. That spec has since changed, and now says you use only the IP address that was used to load the webpage (that's what bug 1506219 is about).

Has Regression Range: no → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: