Bug 246363 - www/firefox: 76.0 breaks videoconferencing (no audio-video tx/rx)
Summary: www/firefox: 76.0 breaks videoconferencing (no audio-video tx/rx)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gecko (Nobody)
URL:
Keywords:
Depends on: 246690
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-10 18:19 UTC by Tomasz "CeDeROM" CEDRO
Modified: 2020-05-24 09:51 UTC (History)
4 users (show)

See Also:
jbeich: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomasz "CeDeROM" CEDRO 2020-05-10 18:19:44 UTC
Helo world,

After update to Firefox 76.0 a videoconferencing stopped working. It works fine with 75.0_2,1 I have downgraded to verify.

Tested on Google Hangouts, Google Meet, JITSI Meet.

I can see my camera and microphone bar jumps when talking but noone can see my audio-video and I cannot see other people audio-video.

This may be an upstream problem. Will also report to Mozilla bugtracker.

Best regards :-)
Tomek
Comment 1 Tomasz "CeDeROM" CEDRO 2020-05-10 18:32:39 UTC
Bugzilla Mozilla report: https://bugzilla.mozilla.org/show_bug.cgi?id=1636781
Comment 2 Jan Beich freebsd_committer freebsd_triage 2020-05-10 19:25:01 UTC
I don't have a camera/microphone, so this needs more users to confirm. Maybe also try https://mozilla.github.io/webrtc-landing/
Comment 3 Tomasz "CeDeROM" CEDRO 2020-05-10 20:02:00 UTC
Thank you Jan for quick response. All tests on the provided page seems to pass. I have the camera preview and I can see myself. I have microphone detected and the bar is jumping as I speak. Locally it works fine. The problem with 76.0 is that both other side cannot receive my audio-video and I cannot receive their audio-video. This seems some sort of regression since 75.0 all works fine on exact the same machine and setup. I have tested on different platforms and the problem is exactly the same, while there is no problem on 75.0.
Comment 4 Sean Farley freebsd_committer freebsd_triage 2020-05-11 02:28:11 UTC
I think this is related to my issue as posted in the mailing list:  https://lists.freebsd.org/pipermail/freebsd-gecko/2020-May/010263.html

I am not certain if it is related to this or not.
Comment 5 Roman 2020-05-11 09:03:35 UTC
I have a same problem. 
My system is FreeBSD 12.1-RELEASE-p3 GENERIC  amd64, FireFox 76.0.1_1,1 from latest pkg.
If I run https://mozilla.github.io/webrtc-landing/canvas_demo.html then in section "Remote Video" I see nothing.
If i run https://mozilla.github.io/webrtc-landing/pc_test.html then in "Remote" section I see a green square.
https://mozilla.github.io/webrtc-landing/canvas_filter_demo.html then in "Remote Video" section I see nothing.
Comment 6 Tomasz "CeDeROM" CEDRO 2020-05-11 09:49:01 UTC
Thank you guys, this problem seems to be confirmed, the "remote" parties are cut off the communications. Maybe Mozilla team can report some hints, it showed up in 76, so it looks like a regression in Frefox..?
Comment 7 Roman 2020-05-11 10:35:32 UTC
In Chromium JITSI Meet and https://mozilla.github.io/webrtc-landing/pc_test.html works normal.
In MS Win 10 Firefox 76.0.1 https://mozilla.github.io/webrtc-landing/canvas_demo.html (I have no webcam on that machine) and JITSI Meet works normal.
Comment 8 Jan Beich freebsd_committer freebsd_triage 2020-05-11 10:44:51 UTC
(In reply to Roman from comment #5)
> If I run https://mozilla.github.io/webrtc-landing/canvas_demo.html then in
> section "Remote Video" I see nothing.

I can reproduce on Firefox 76.0.1 but not on Firefox 78 (nightly).
Comment 9 Roman 2020-05-11 11:18:22 UTC
(In reply to Jan Beich from comment #8)

Does in Firefox 78 work Audio Worklets? I do not know if this issue is related to this change in FF76, but as far as I understand, these are close things.
Comment 10 commit-hook freebsd_committer freebsd_triage 2020-05-11 14:17:35 UTC
A commit references this bug:

Author: jbeich
Date: Mon May 11 14:17:24 UTC 2020
New revision: 534914
URL: https://svnweb.freebsd.org/changeset/ports/534914

Log:
  www/firefox-esr: backport NSS 3.52 support after r533597 (like r534912)

  PR:		246363
  Reported by:	Tomasz "CeDeROM" CEDRO, Roman

Changes:
  head/mail/thunderbird/Makefile
  head/mail/thunderbird/files/patch-bug1624128
  head/www/firefox-esr/Makefile
  head/www/firefox-esr/files/patch-bug1624128
Comment 11 commit-hook freebsd_committer freebsd_triage 2020-05-11 14:19:38 UTC
A commit references this bug:

Author: jbeich
Date: Mon May 11 14:18:51 UTC 2020
New revision: 534915
URL: https://svnweb.freebsd.org/changeset/ports/534915

Log:
  MFH: r534912 r534914

  www/firefox: backport NSS 3.52 support after r533597

  PR:		246363
  Reported by:	Tomasz "CeDeROM" CEDRO, Roman
  Approved by:	ports-secteam blanket

Changes:
_U  branches/2020Q2/
  branches/2020Q2/mail/thunderbird/Makefile
  branches/2020Q2/mail/thunderbird/files/patch-bug1624128
  branches/2020Q2/www/firefox/Makefile
  branches/2020Q2/www/firefox/files/patch-bug1624128
  branches/2020Q2/www/firefox-esr/Makefile
  branches/2020Q2/www/firefox-esr/files/patch-bug1624128
Comment 12 Jan Beich freebsd_committer freebsd_triage 2020-05-11 14:38:56 UTC
Tomasz, can you still reproduce with the above fix? Binary packages would get it only in ~2 days.
Comment 13 Tomasz "CeDeROM" CEDRO 2020-05-12 00:12:02 UTC
Thank you Jan, building from ports.. but it takes a while :-) When its ready will report back :-)

Maybe I should switch to ESR? :-)
Comment 14 Jan Beich freebsd_committer freebsd_triage 2020-05-12 01:27:29 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #13)
> Maybe I should switch to ESR? :-)

For WebRTC services developed by Google when WebRTC code in Firefox is forked from an old version of Chromium (64 for FF76/68)? Besides, ESR was also affected due to --with-system-nss passed via Mk/bsd.gecko.mk.
Comment 15 bugs_fbsd20 2020-05-12 07:32:51 UTC
The issue was fixed with the latest build of firefox (firefox-76.0.1_1,1), which already landed in the quarterly pkg repository.

Thanks for responding so quickly!
Comment 16 Tomasz "CeDeROM" CEDRO 2020-05-12 11:10:55 UTC
I have finally built and tested firefox-esr-68.8.0_4,1.txz the problem is fixed THANK YOU! :-)
 
On the other hand it would be really nice to push Mozilla Firefox to remove their totally dirty Profile Downgrade Protection that was implemented recently and effectively prevents us from using our own data in that Open-Source software. Sick! :-(
Comment 17 Tomasz "CeDeROM" CEDRO 2020-05-12 11:18:05 UTC
The problem still occurs in firefox-76.0.1_1,1. I am using 'latest' pkg repository. I can see there is port verion 2 in the ports tree, will try to build it and verify :-)

% pkg info firefox|head
firefox-76.0.1_1,1
Name           : firefox
Version        : 76.0.1_1,1
Installed on   : Tue May 12 12:48:39 2020 CEST
Origin         : www/firefox
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : www

So that was out local bug not the upstream issue?
Comment 18 Tomasz "CeDeROM" CEDRO 2020-05-12 12:35:56 UTC
I had to release my Kraken with 24 CPU 128GB RAM to speed things up :-)

I can confirm that firefox-76.0.1_2,1 fixes the issue THANK YOU!!! :-)
Comment 19 Jan Beich freebsd_committer freebsd_triage 2020-05-12 13:20:16 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #18)
> remove Profile Downgrade Protection that was implemented recently

Do you prefer subtle profile corruption over time? With ZFS snapshots restoring profile(s) from backup is very easy.

https://old.reddit.com/r/firefox/comments/fxv4mt/firefox_doesnt_let_me_use_my_profile_when_i/

(In reply to Tomasz "CeDeROM" CEDRO from comment #17)
> So that was out local bug not the upstream issue?

No, it's an upstream issue related to NSS API/ABI of a specific feature. Many other distros use --with-system-nss.

See also https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html
Comment 20 Tomasz "CeDeROM" CEDRO 2020-05-12 13:35:31 UTC
Thank you Jan for ulta-rapid action! :-)

Also I am sorry for misquoting your response out of context on FF report! Hope you forgive me :-)

Regarding this downgrade I saw on reddit that --allow-downgrade is possible thanks for reference! I would prefer not to have anything blocking use of my own data in the open-source world. If they enforced silent upgrade then they should also provide a way to downgrade safely. Just in case of situation like this where downgrade seems the quickest solution (other bugs like this may not solve in two days). Modern browser keeps all of our everyday work data. I hope there are no either-or situations in future.

ONCE AGAIN BIG THANK YOU!! :-)