Hello!

This morning I upgraded my Debian testing box, and firefox-esr
had the following upgrade:

  [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1

After the upgrade, I noticed that firefox-esr was no longer
able to find my microphone (mic input on the audio card integrated on
my motherboard). At first, I thought the issue was due to some
misconfiguration on my part (for instance on the ALSA side), but, no,
ALSA is able to see the CAPTURE ports and they are enabled and unmuted.
After going mad for quite some time, I saw that chromium was still
happily to able to find the microphone and use it...

Please note that the same configuration was working perfectly
yesterday (before the firefox-esr upgrade).

If I test on <https://www.onlinemictest.com/>, the response
is:

|  We can't find your microphone - that most probably means that it's
|  either not connected, broken, or you don't have the proper webcam
|  drivers

But no, it's not a webcam microphone (although I also have a webcam,
which is correctly found by firefox-esr, as a video input).
The issue is that firefox-esr can no longer find any microphone.

I have also tried with "firefox-esr -safe-mode" and I am able
to reproduce the issue, hence it does not seem to be caused by
some extension.

During these COVID-19 pandemic times, working from home, not being
able to use the microphone with the browser (for teleconferencing,
videocalls, and so forth) is a big regression.
I would even say that this bug should have severity "grave".
Please raise the severity, if you agree.

Please try to reproduce the bug, fix it, and/or forward the bug
report upstream, as appropriate.

Thanks for your time and dedication!

Did you try downgrading?

Mike

Hello Mike,
thanks for your followup.

Yes, I downgraded firefox-esr and the bug vanished.
This confirms that the issue is indeed caused by the new version of
firefox-esr.

I was going to add a comment to the bug report, just to let you know
about the downgrade test, but you were faster than me!  :-)

Or not. This could also be caused by some upgraded build dependency.
Do you have the resources to attempt rebuilding 68.7 against current
unstable?

Mike

[...]

Well, that's another possibility, I agree...

I can try inside a pbuilder-managed sid chroot.

I issued the following command:

 $ dget https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc

and obtained the unpacked source package.

Can you confirm that this the source I should attempt to build?

Sounds good.

Mike

Dear Maintainer,

I can confirm this bug.

The microphone was working fine in web pages just before the upgrade to
68.8.0esr-1 (in my case, I was using it with https://meet.jit.si/ ).
When tried to downgrade to 68.7.0esr-1 it started working again. There
have not been paralell dependency upgrades in my system related to
firefox-esr, the only ones were:

    libapt-pkg6.0 amd64 2.1.1 [985 kB]
    apt amd64 2.1.1 [1.439 kB]
    apt-utils amd64 2.1.1 [433 kB]
    groff-base amd64 1.22.4-5 [920 kB]
    cmake amd64 3.16.3-3 [3.674 kB]
    cmake-data all 3.16.3-3 [1.628 kB]
    firefox-esr-l10n-es-es all 68.8.0esr-1 [505 kB]
    libgtk-3-common all 3.24.20-1 [3.724 kB]
    libgtk-3-0 amd64 3.24.20-1 [2.671 kB]
    firefox-esr amd64 68.8.0esr-1 [48,2 MB]
    gir1.2-gtk-3.0 amd64 3.24.20-1 [256 kB]
    gtk-update-icon-cache amd64 3.24.20-1 [85,7 kB]
    libflite1 amd64 2.1-release-4 [12,8 MB]
    libfluidsynth2 amd64 2.1.2-1 [228 kB]
    libgtk-3-bin amd64 3.24.20-1 [122 kB]
    node-jquery all 3.5.1+dfsg-3 [309 kB]
    libjs-jquery all 3.5.1+dfsg-3 [3.548 B]
    make amd64 4.2.1-2+b1 [342 kB]
    pinentry-curses amd64 1.1.0-4 [64,9 kB]
    pinentry-gtk2 amd64 1.1.0-4 [71,0 kB]
    libvulkan1 amd64 1.2.135.0-3 [101 kB]

As you can see, nothing of these can be related to the bug, not even
libvulkan (that I don't use) or GTK+3. The only possible culprit is
firefox itself.

Mmmmh...

debian/control includes

  Build-Depends: [...]
                 libvpx-dev (>= 1.5.0),
                 [...]
  Build-Conflicts: [...]
                   libvpx-dev (>= 1.8.0),
                   [...]

but current sid has:

  $ rmadison libvpx-dev | grep unstable
  libvpx-dev | 1.8.2-1         | unstable     | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

How should I handle this conflict?

older.

Or if this condition doesn't hold:
ifneq (,$(filter testing% bullseye% unstable sid,$(DEB_DISTRIBUTION)))

(where DEB_DISTRIBUTION comes from /usr/share/dpkg/pkg-info.mk)

Mike

[...]

Could you please elaborate?


As I said, I used dget to obtain the unpacked source package.
In the unpacked source tree, I see a debian/control file with the above
mentioned content.

If I issue my usual

  $ pdebuild --configfile ~/.pbuilder/sid.conf

command, pbuilder uses my up-to-date sid chroot environment, parses
debian/control and attempts to satisfy the build dependencies.
But it doesn't install libvpx-dev.
I assume the reason is that the only version available in sid is >=
1.8.0 and thus in conflict...

And then, during the build process:

  [...]
  checking for vpx >= 1.7.0... no
  ERROR: Package vpx was not found in the pkg-config search path.
  ERROR: Perhaps you should add the directory containing `vpx.pc'
  ERROR: to the PKG_CONFIG_PATH environment variable
  ERROR: No package 'vpx' found
  make[1]: *** [debian/rules:243: stamps/configure-browser] Error 1
  [...]


Who is supposed to modify the debian/control file so that it doesn't
include the above mentioned conflict?

Please excuse my ignorance, but I thought debian/control files should
not be altered on the fly during the build process...

If I dget https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc, I get a debian/control that doesn't contain anything about libvpx. debian/control.in does, but that should be irrelevant.

Mike

Something else you could try is rebuild firefox-esr 68.8.0esr-1 with
this patch applied:
https://salsa.debian.org/mozilla-team/firefox/-/commit/87df541b27a0b012e843978a0343f2918e0f2f58

Mike

Dear Mike,

I can confirm the issue here.  Since the last upgrade of firefox, I'm
not able to use firefox for webRTC sessions anymore.  To be sure, I
checked with an old laptop: Before the upgrade it worked fine, after
the upgrade it doesn't.  Chromium works fine so far.

Best regards,

  Andi

the rebuilding against current sid and that stanza had distribution set
to UNRELEASED.

Does this explain why I obtained the wrong debian/control?

It does.

Mike

On Wed, 13 May 2020 14:31:58 +0900 Mike Hommey wrote:

[...]

I rebuilt firefox-esr/68.8.0esr-1, after modifying debian/rules as
shown in the above mentioned patch.

I tested this patched version of firefox-esr, but the microphone was
still unseen by the browser.
Hence, I would say that the patch does not change anything with respect
to the microphone bug.


By looking at the bug log, I see that at least two other users confirm
they also experience the issue.

Did you manage to reproduce the bug?
Have you found a fix or, at least, a workaround?
Could you please forward the bug report upstream?

Please let me know.
Thanks a lot for your time and dedication!

BTW, I've tested the official Linux-64 bit Mozilla 68.8-esr binary[*],
and the microphone is working (at least in my use case). You could try
to recompile without the Debian additional patches and see if that
helps.

[*] https://www.mozilla.org/en-US/firefox/68.0esr/releasenotes/

Can you test 68.8.0esr-1~deb10u1?
https://packages.debian.org/source/stable/firefox-esr

Mike

On Fri, 15 May 2020 09:04:00 +0900 Mike Hommey wrote:

[...]
included in stable-security:

  [INSTALL, DEPENDENCIES] libevent-2.1-6:amd64 2.1.8-stable-4
  [INSTALL, DEPENDENCIES] libffi6:amd64 3.2.1-9
  [INSTALL, DEPENDENCIES] libvpx5:amd64 1.7.0-3+deb10u1
  [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1~deb10u1

I tested again: the microphone was still unseen by the browser.

Hence, it seems that the current test situation is:

firefox-esr                         microphone
==============================================
68.7.0esr-1                              OK
68.8.0esr-1                             fails
68.8.0esr-1  w/force-PKCS11-patch       fails
68.8.0esr-1~deb10u1                     fails

Are you using pulseaudio? If not, can you try setting
security.sandbox.content.level to 5 in about:config?

Mike

Err, make that 1, rather. Or 0.

Mike

[...]

No, I am using jackd (JACK Audio Connection Kit), with the well known
ALSA configuration file ~/.asoundrc that redirects applications using
ALSA to the ports provided by JACK.

In case you need to see the details of my audio configuration, they are
[documented] on my website.

[documented]: <https://www.inventati.org/frx/doc/nanodocs/testing_workstation_audio.html>

Needless to say, the audio configuration is the same that works
perfectly with firefox-esr/68.7.0esr-1 ...

Let me see.

After upgrading again to 68.8.0esr-1:

  [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1

For each of the following values I set the level, restarted firefox,
and tested the microphone again on <https://www.onlinemictest.com/>.

The outcome was:

security.sandbox.content.level       microphone
===============================================
           0                              fails
           1             no page loading at all
       4 (default)                        fails
           5                              fails

[...]
[...]

Dear Mike,
is there any progress for this investigation?

Which Debian-specific patch could be responsible for breaking the
microphone support?
Any idea?

Hi Mike,

I reported problems with webRTC above (related or not with the
'microphone'-issue at hand).  However, somehow the problem has
disappeared here after one of the many upgrades (not the firefox-esr
package).  I tried to figure out the package that made the difference,
but there where to many changes.  So for me, anything works fine
again.

Thank you for your work,

  Andi

libnss3:

 - upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1636632
 - Firefox 76 bug (already closed): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959971

By the way, bug #961762 "firefox-esr: WebRTC broken"[1] should have been
merged with this one.

 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961762

The "culprit" is libnss3, which unstable has a new version of it since
saturday[2]. You can check it by downgrading to the 2:3.49.1-1 version
from testing and see if that undoes the fix.

 [2]: https://tracker.debian.org/pkg/nss

Can you test 68.9.0esr-1?

Mike

On Thu, 4 Jun 2020 17:35:20 +0900 Mike Hommey wrote:

[...]

I've just tried, after installing it from unstable.

No luck!
The microphone fails to work with firefox-esr/68.9.0esr-1

Hello again,
I've just tested firefox-esr/68.12.0esr-1 from unstable.

The microphone still fails to work, unfortunately.

I had to downgrade back to 68.7.0esr-1 in order to get it working
correctly.

Is there any progress on this bug?
It's preventing me from upgrading firefox-esr to the latest versions...

Firefox on the latest version of testing still doesn't detect my laptop's mic.
Seems like this is only a problem for systems without PulseAudio. I was able to
workaround this problem by wrapping firefox-esr around apulse, but I'd rather
have a true solution than a hack like apulse.

Students like me are going online for our classes, and it sucks that
Firefox out-
of-the-box won't detect our microphones. So please fix as soon as possible.

Job Bautista

Hello once again.
I've just tested firefox-esr/78.3.0esr-2 from testing (and unstable).

It behaves somehow differently with respect to previously tested
versions, but the microphone still fails to work.

If I test on <https://www.onlinemictest.com/>, the website finds the
microphone and asks me to allow its use.
After having allowed the use of the mic, I am able to see the line, but
the line does not move (it stays flat), as if the mic were broken.

But the same mic works on the same website with chromium and with
firefox-esr/68.7.0esr-1, hence the hardware is working and the audio
setup is correct.

I had to downgrade firefox-esr again...  :-(

Is there any progress on this bug?

On Sun, 4 Oct 2020 20:35:27 +0200 Francesco Poli wrote:

[...]
I've just tested firefox-esr/78.6.0esr-1 from unstable and
firefox-esr/78.6.0esr-1~deb10u1 from stable/updates.

They behave exactly as firefox-esr/78.3.0esr-2: after allowing the use
of the mic, the mic signal does not seem to reach the browser (as if
the mic were broken).

But the mic works perfectly with chromium.

And once again, I had to downgrade firefox-esr to version 68.7.0esr-1,
so that the mic works.

Is there any progress on this bug?
Has any developer been able to reproduce it?

Please recall that, according to another user, the [mic works] on
firefox-esr without Debian patches. Hence, it seems that the issue is
caused by one of the Debian patches.
Could you please investigate in this direction?

[mic works]: <https://bugs.debian.org/960301#85>

Please let me know.
I am more and more worried by the need to stay with an old firefox-esr
version!

On Sun, 20 Dec 2020 15:34:54 +0100 Francesco Poli wrote:

[...]

Another test: firefox-esr/78.6.1esr-1
No difference: after allowing the use of the mic, the mic signal does
not seem to reach the browser (as if the mic were broken).

But the mic works perfectly with chromium and with
firefox-esr/68.7.0esr-1 ...

Is there any news on this issue?
Could you please reply?

Thanks for your time!

On Mon, 18 Jan 2021 23:42:32 +0100 Francesco Poli wrote:

[...]

I have performed more tests on <https://www.onlinemictest.com/>:
no difference, after allowing the use of the mic, the mic signal does
not seem to reach the browser (as if the mic were broken).

package                                microphone
=================================================
firefox-esr/78.12.0esr-1                   fails
firefox-esr/78.12.0esr-1~deb10u1           fails
firefox/88.0.1-1                           fails


But the mic still works perfectly with chromium and with
firefox-esr/68.7.0esr-1 ...



This bug report has turned into a monologue.
Could anyone among the maintainers of Mozilla-related packages reply,
please?

Does anybody actually care about this issue?

This regression has been present in Debian testing since May 2020 and,
after some initial investigation (May and June 2020) there seems to
have been no further progress.

Can you reproduce the issue with a microphone?

It has been suggested in the past that the issue could be caused by one
of the Debian-specific patches, since upstream Firefox does not seem to
be affected.
Has anyone tried to pinpoint the patch causing the regression?

Or, in case the issue is reproducible with upstream Firefox as well,
has the bug report been forwarded upstream?


Thank you for your time and patience.

And:

firefox-esr/78.13.0esr-1                    fails

Really, is there anybody (who cares) out there?

And:

firefox-esr/91.4.0esr-1                     fails

Ping? ping? ping? ping? ping? ...