1896361 - www.facebook.com / messenger.com - Missing video and audio call buttons in encrypted chat

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[Sky Schubert [:skyschub]]

Environment:
Operating system: Windows 10
Firefox version: Firefox 121.0

Steps to reproduce:
Firefox 121 Desktop Windows 11: In encrypted Facebook Messenger chats at https://www.facebook.com/messages/e2ee/t/ the phone and video call buttons are missing, see image below.
In non-encrypted Messenger chats such as group chats located at https://www.facebook.com/messages/t/ the phone and video call buttons are still present. I have not tested to see if the buttons actually work.

Firefox 121 Mobile Android 13: While in desktop site mode, in encrypted Facebook Messenger chats at https://www.facebook.com/messages/e2ee/t/ the phone and video call buttons are missing.
In non-encrypted Messenger chats such as group chats located at https://www.facebook.com/messages/t/ the phone and video call buttons are still present. I have not tested to see if the buttons actually work.

Chrome 120 Desktop Windows 11: In both encrypted and non-encrypted Facebook Messenger chats at https://www.facebook.com/messages/e2ee/t/ and https://www.facebook.com/messages/t/ the phone and video call buttons are there. I have not tested to see if the buttons actually work.

Actual Behavior:
Facebook Messenger encrypted chats do not allow voice or video calling on desktop and mobile Firefox

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/131826

Comment 1

[Sky Schubert [:skyschub]]

I've sent them a message and asked for details, but I'm leaving this in needs-diagnosis so we can have a look, too.

Comment 2

[James Heppell [:FormularSumo]]

From my testing Messenger now shows a greyed out call icons for end-to-end encrypted chats on Firefox with a message saying "Video Calls are not supported on this browser"

Additionally, their help articles no longer list Firefox as a supported browser (I'm pretty sure they used to)
https://www.facebook.com/help/messenger-app/2322144494758524?cms_platform=www&helpref=platform_switcher
https://www.facebook.com/help/211644178877843/?helpref=faq_content

So it seems like this is an intentional change on behalf on Facebook :/

Comment 3

[James Heppell [:FormularSumo]]

Attachment: Greyed out call buttons in E2EE chats

Comment 4

[J. Bumblebee Extraordinaire]

Can we bypass this by tricking Facebook/Messenger into thinking we're using Chrome/Chromium, by using spoofing the user agent?

Comment 5

[Jim Mathies [:jimm]]

They have a page on this -
https://www.facebook.com/help/messenger-app/597429858389632

But they don't provide detail. Spoofing Chrome didn't help. Possibly due to the use of non-standard createEncodedStreams. (https://blog.mozilla.org/webrtc/end-to-end-encrypt-webrtc-in-all-browsers/)

Comment 6

[Back Aug 24 [:jib]]

https://blog.mozilla.org/webrtc/end-to-end-encrypt-webrtc-in-all-browsers/ should contain all the information facebook needs (including a shim) to support Firefox and Safari.

Comment 8

[Thomas Collin]

Since a few days the phone and video call buttons are now there. In my case the defect lasted about 10 days.

Comment 9

[James Heppell [:FormularSumo]]

I'm still getting the greyed out buttons and "calling not supported using this browser" on Firefox as before

Comment 10

[Pranav bhattarai]

It affects a lot of people as discussed here https://support.mozilla.org/tn/questions/1449261

Hope this get resolved soon.

Comment 11

[Masa Péter]

It has been a year since this started, and it seems facebook is entirely unwilling to switch to using the standardized API mentioned in the article above. Multiple friends have asked me why cant they do messenger calls in Firefox, and it seems theres not much I can do other than install a chromium browser for them, or a shady unofficial electron app, if I want to keep the reach of facebook limited on their computers.

Would it be possible to implement some kind of compatibility layer to appease messenger?
You shouldnt be the ones who needs to fix the crap facebook left behind, but if they have a hidden motive behind their (in)action, and they are benefitting from it, as some in the firefox community suggests, then we can expect that they will never fix it.

I, and a few others caring to dig to the bottom of this do understand that this is not the fault of Firefox, but the casual user doesnt care even if they know it. And however much we may want, we cant just tell them and their families to use a different chat service, even after all the other problems this one is burdened with.

Comment 12

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

Tom, Jan-Ivar - per comment 6, could we do an intervention that includes the shim mentioned in Comment 6?

Comment 13

[Back Aug 24 [:jib]]

It's a Chrome shim letting websites (like Facebook) use RTCRtpScriptTransform in Chrome today without turning it on in chrome://flags/#enable-experimental-web-platform-features.

• With shim: https://jsfiddle.net/jib1/wx3Lczrs/143/ works in Chrome (contains minor nits to make the shim work)
• Without shim: https://jsfiddle.net/jib1/wx3Lczrs/146/ works in Chrome with Experimental WebPlatform Features turned on

I'm updating MDN to document Chrome's support.

A Firefox intervention would be based on a reverse shim, but it's currently blocked on bug 1868223 — Support [Serializable] for RTCEncodedVideoFrame and RTCEncodedAudioFrame (with .data member transfer).

Comment 14

[Ina Popescu, Desktop QA]

I've tested this in the latest Nightly 142.0a1 and noticed that the issue reported here occurs when both users are on macOS devices. In this setup, the call buttons (audio/video) are disabled in Facebook Messenger chats.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Dropping Android from affected platforms because Facebook messenger requires using the App on Android

Comment 16

[Masa Péter]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)

Dropping Android from affected platforms because Facebook messenger requires using the App on Android

Does that artifical restriction of theirs also hold when the user loads messenger.com in "desktop site" mode?

Comment 18

[Pranav bhattarai]

(In reply to Masa Péter from comment #16)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)

Dropping Android from affected platforms because Facebook messenger requires using the App on Android

Does that artifical restriction of theirs also hold when the user loads messenger.com in "desktop site" mode?

I too want to know what Devs have to say about Messenger.com since I use it.

Comment 19

[Back Aug 24 [:jib]]

Attachment: Bug 1896361 - Interventions for some websites relying on createEncodedStreams(). r?twisniewski

Comment 20

[Phabricator Automation]

Comment on attachment 9520098 [details]
Bug 1896361 - Interventions for some websites relying on createEncodedStreams(). r?twisniewski

Revision D268638 was moved to bug 1913599. Setting attachment 9520098 [details] to obsolete.

Comment 21

[Thane K. Sherrington]

Any updates on this? I recently tried this in FF 146.0.1 and while I can start video/audio chats with groups of people (if I have a chat group set up in Messenger) I can't start an audio/video chat will one person (it tells me the browser isn't compatible). So FF works, it just fails some test in Facebook's code for one to one chats.

Comment 22

[smayer97]

@Thane That is because group calls are not encrypted, unlike one-to-one calls.

Comment 23

[Thane K. Sherrington]

@smayer97 Ok, that makes sense. Is Firefox unable to handle encrypted calls?

Comment 24

[Masa Péter]

It is perfectly able to do that, but facebook messenger decided to not be standards compliant, and went with using a chrome-only API for encrypting the audio.

This bug says the compatibility patch was implemented in Friefox 146: https://bugzilla.mozilla.org/show_bug.cgi?id=1913599
But according to comment 12, maybe you need to use Firefox Nightly to have this fix for now.

Comment 25

[Thomas Wisniewski [:twisniewski]]

Yes, we added a webcompat intervention in bug 1913599, but only for nightly builds for now.

If someone could help test with it to see whether it causes other unexpected issues, that would be great! I would be happy to ship it to more users if we can verify that it does not have any obvious bad side effects (on facebook.com and messenger.com).

Comment 26

[Thane K. Sherrington]

(In reply to Thomas Wisniewski [:twisniewski] from comment #25)

Yes, we added a webcompat intervention in bug 1913599, but only for nightly builds for now.

If someone could help test with it to see whether it causes other unexpected issues, that would be great! I would be happy to ship it to more users if we can verify that it does not have any obvious bad side effects (on facebook.com and messenger.com).

I will test it with my computer. What build should I use?

Comment 27

[Thomas Wisniewski [:twisniewski]]

The latest nightly build will do, thanks. You can get it here: https://www.firefox.com/en-CA/channel/desktop/

It should start up in a new browser profile, so your daily profile won't be impacted (of course that means you'll have to log in to test).

Comment 28

[Philippe]

Hello. Do you have some news ? This problem is not still fixed by the devs... Very weird.

Comment 29

[kanapa1]

If I may put my two cents in, given that audio and video calls in E2EE conversations in web versions of Facebook and Messenger have effectively been broken in Firefox from the very beginning (essentially since Meta started gradually rolling out E2EE chats in early 2024 and converting more and more existing conversations to E2EE every month, without any real per-chat opt-out for users), I honestly see absolutely zero risk in shipping the webcompat intervention from bug 1913599 to the entire Firefox userbase.

You can't really break something that already doesn't work, and with the intervention enabled, there's at least a chance that audio and video calls in E2EE conversations might finally start working as expected. It seems worth a try to me.

And for users who are "lucky" enough to still have some conversations that haven't been migrated to E2EE yet, those use a different, legacy code path for audio and video calls anyway, so this webcompat intervention shouldn't affect them at all, neither positively nor negatively.

One thing that would make testing much easier in situations like this would be to have some about:config pref for testing purposes (similar to cookiebanners.listService.testRules for the cookie banner blocking feature) that would allow selectively enabling specific webcompat interventions that are otherwise gated to a different release channel, or at least a global override to switch the effective intervention channel between release, beta, and nightly (defaulting to the browser's update channel, of course).

That would make testing these not-yet-fully-proven-in-the-wild interventions much easier, especially in cases where the other party also uses Firefox as their daily web browser but is not tech-savvy enough to install a non-standard Firefox edition to help with testing.

Comment 30

[Back Aug 24 [:jib]]

Hi kanapa1, is facebook calling in Nightly working reliably for you (real question)? If so then I'd agree.

But when I test Firefox (macOS) <-> Chrome (macOS): video works both ways, and sending audio works but receiving audio does not for me. This seems like a deal breaker for even a decent experience.

This being enabled in Nightly lets us keep an eye on whether it starts working. We could expand this to the beta population, but I don't see why. I think for most (even beta) users, wasting time engaging in a futile call attempt is worse than being told to use a different browser.

I don't think we should more broadly enable something that doesn't work.

FWIW, RTCRtpScriptTransform is now baseline, so Facebook has everything they need to fix this without any shim.

Comment 31

[Alexandre Demers]

Hi Jan-Ivar. I just installed Firefox nightly 149.0a1 on Linux (Arch using precompiled binaries).

I tried calling an iPad user who was using the Facebook Messenger app without success. I also tried calling a Chrome user on Windows, with the same result.

The audio and video call buttons are enabled either under facebook.com or messenger.com, but the call fails to send and receive any audio or video. I'll test under Windows with the same build to see if I get a different result.

Comment 32

[Alexandre Demers]

Also tested on Windows 11 with today's nightly (2026-01-17) and it also failed calling an iPad user.

Comment 33

[Alexandre Demers]

Here I have something interesting comparing a call made from messenger.com and one from facebook.com.

The following console log was copied after launching a call request from messenger.com. When I tried to call from messenger.com, I could not hear or see the person I was calling and the person called was not seeing or hearing me either.

When logging in, Firefox calls the Storage Access API on behalf of the site. See https://bugzilla.mozilla.org/show_bug.cgi?id=1934814 for details. messengerLogin.js:21:9
createEncodedStreams() is being shimmed for compatibility reasons. Please consider updating to the RTCRtpScriptTransform API for optimal performance! See https://bugzil.la/1913599 for details. bug1913599-shim-createencodedstreams.js:26:9
Empty string passed to getElementById(). xvwyX9Yh1DU9nyJf8tP0LcJlJRpav7jLAJfUcAdnU3tB_XZZ1CHcgANQYwOquFzemtcIF6mT0QN14e2CSiScz71-TYGIcn5AOnbZbiNffp6g1w1GpJmc3DiyvZlz9T4mrN6Z.js:2529:4100
Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://static.xx.fbcdn.net/rsrc.php/v4/yL/r/hVe2HmwMRpE.gif hVe2HmwMRpE.gif

Stop! RmFjEoSSIPN.js:253:965

This is a browser feature intended for developers. If someone told you to copy-paste something here to enable a Facebook feature or "hack" someone's account, it is a scam and will give them access to your Facebook account. RmFjEoSSIPN.js:253:965

See https://www.facebook.com/selfxss for more information. RmFjEoSSIPN.js:253:965

RmFjEoSSIPN.js:253:965
Content-Security-Policy: The page’s settings blocked a worker script (worker-src) at data:text/javascript,(function work() { … from being executed because it violates the following directive: “worker-src https://.messenger.com/static_resources/webworker_v1/init_script/ https://.messenger.com/static_resources/webworker/init_script/ https://.messenger.com/static_resources/sharedworker/init_script/ https://.messenger.com/static_resources/webworker/map_libre/ https://.messenger.com/static_resources/webworker/map_libre_rtl/ https://.messenger.com/sw/ https://*.messenger.com/sw” 2 ROOM:
Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://scontent-bos5-1.xx.fbcdn.net/v/t39.30808-1/271598765_10159496894876936_4369196736420772773_n.jpg?stp=c0.195.1536.1536a_cp0_dst-jpg_s40x40_tt6&_nc_cat=109&ccb=1-7&_nc_sid=e99d92&_nc_ohc=dKBGyhKvL0AQ7kNvwGwXMqV&_nc_oc=AdlsCwS60GK6R4loXInWAZ1FIFUvueIc0dCRqgdBl4gVVZNidxTZ_OXO0fjvOrFKj9Q&_nc_zt=24&_nc_ht=scontent-bos5-1.xx&_nc_gid=uMMAhxO08M_M1z9qlTNqxg&oh=00_AfrW91YoIr1ljkkvz3UDXX6lJD55INDBbr5537CeESmSyw&oe=6972071B 271598765_10159496894876936_4369196736420772773_n.jpg
Source map error: Error: URL constructor: is not a valid URL.
Stack in the worker:resolveSourceMapURL@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:56:22
getOriginalURLs@resource://devtools/client/shared/source-map-loader/source-map.js:75:24
workerHandler/</<@resource://devtools/client/shared/worker-utils.js:115:52
workerHandler/<@resource://devtools/client/shared/worker-utils.js:113:13

Resource URL: wasm:
Source Map URL: null
Content-Security-Policy: The page’s settings blocked a worker script (worker-src) at data:text/javascript,(function work() { … from being executed because it violates the following directive: “worker-src https://.messenger.com/static_resources/webworker_v1/init_script/ https://.messenger.com/static_resources/webworker/init_script/ https://.messenger.com/static_resources/sharedworker/init_script/ https://.messenger.com/static_resources/webworker/map_libre/ https://.messenger.com/static_resources/webworker/map_libre_rtl/ https://.messenger.com/sw/ https://.messenger.com/sw” ROOM:
Content-Security-Policy: The page’s settings blocked a worker script (worker-src) at data:text/javascript,(function work() { … from being executed because it violates the following directive: “worker-src https://.messenger.com/static_resources/webworker_v1/init_script/ https://.messenger.com/static_resources/webworker/init_script/ https://.messenger.com/static_resources/sharedworker/init_script/ https://.messenger.com/static_resources/webworker/map_libre/ https://.messenger.com/static_resources/webworker/map_libre_rtl/ https://.messenger.com/sw/ https://.messenger.com/sw” ROOM:
Source map error: Error: URL constructor: is not a valid URL.
Stack in the worker:resolveSourceMapURL@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:56:22
getOriginalURLs@resource://devtools/client/shared/source-map-loader/source-map.js:75:24
workerHandler/</<@resource://devtools/client/shared/worker-utils.js:115:52
workerHandler/<@resource://devtools/client/shared/worker-utils.js:113:13

Resource URL: wasm:
Source Map URL: null
MouseEvent.mozInputSource is deprecated. Use PointerEvent.pointerType instead. 2mRBs-OX6l0rrCxjEFdRGjot7SI5_UYu0DT_-yxjnTC4mun-aSim-r7P6-iuM7ke3OYY5w7mK_OWevrVfI719cH4t_VAQ8jmnOEKbh2As6zRDSGKU4lvpjmBBnMtx8bCvVYk.js:162:790

However, when I called from facebook.com, while I was still unable to hear or see the person I was calling, they were able to see and hear me. Here is the console log from facebook.com:

Content-Security-Policy: Ignoring ‘block-all-mixed-content’ because mixed content display upgrading makes block-all-mixed-content obsolete. ROOM:
createEncodedStreams() is being shimmed for compatibility reasons. Please consider updating to the RTCRtpScriptTransform API for optimal performance! See https://bugzil.la/1913599 for details. bug1913599-shim-createencodedstreams.js:26:9
Empty string passed to getElementById(). EOyejDU-KR4XsKn4_6MppsvYcx4jCohnVAtsn2hd0YV1FeHl247_u9dbasNDeBuyIl7jLibZBCeZ2Ues7uf9HjtNSelXRglTC1Wqq2dgD6nKJVnZ3uCtIe-9--wAFy9KJKvXR7CRWuR6ECl.js:2472:4100

Stop! RmFjEoSSIPN.js:253:965

This is a browser feature intended for developers. If someone told you to copy-paste something here to enable a Facebook feature or "hack" someone's account, it is a scam and will give them access to your Facebook account. RmFjEoSSIPN.js:253:965

See https://www.facebook.com/selfxss for more information. RmFjEoSSIPN.js:253:965

RmFjEoSSIPN.js:253:965
Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://static.xx.fbcdn.net/rsrc.php/v4/yL/r/hVe2HmwMRpE.gif hVe2HmwMRpE.gif
WebRTC: Using five or more STUN/TURN servers slows down discovery 2 EOyejDU-KR4XsKn4_6MppsvYcx4jCohnVAtsn2hd0YV1FeHl247_u9dbasNDeBuyIl7jLibZBCeZ2Ues7uf9HjtNSelXRglTC1Wqq2dgD6nKJVnZ3uCtIe-9--wAFy9KJKvXR7CRWuR6ECl.js:1114
Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://scontent-bos5-1.xx.fbcdn.net/v/t39.30808-1/271598765_10159496894876936_4369196736420772773_n.jpg?stp=c0.195.1536.1536a_cp0_dst-jpg_s40x40_tt6&_nc_cat=109&ccb=1-7&_nc_sid=e99d92&_nc_ohc=dKBGyhKvL0AQ7kNvwGwXMqV&_nc_oc=AdlsCwS60GK6R4loXInWAZ1FIFUvueIc0dCRqgdBl4gVVZNidxTZ_OXO0fjvOrFKj9Q&_nc_zt=24&_nc_ht=scontent-bos5-1.xx&_nc_gid=jJUZuMGlPaz3S6GyEcGjoQ&oh=00_AfqD8gfCECEjj5JZTWfZ6CAAHUMJR4qWJFlxxHKY-xCYwg&oe=6972071B 271598765_10159496894876936_4369196736420772773_n.jpg
Source map error: Error: URL constructor: is not a valid URL.
Stack in the worker:resolveSourceMapURL@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:56:22
getOriginalURLs@resource://devtools/client/shared/source-map-loader/source-map.js:75:24
workerHandler/</<@resource://devtools/client/shared/worker-utils.js:115:52
workerHandler/<@resource://devtools/client/shared/worker-utils.js:113:13

Resource URL: wasm:
Source Map URL: null
MouseEvent.mozInputSource is deprecated. Use PointerEvent.pointerType instead. AOgoFOvOYem.js:76:790
Source map error: Error: URL constructor: is not a valid URL.
Stack in the worker:resolveSourceMapURL@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:56:22
getOriginalURLs@resource://devtools/client/shared/source-map-loader/source-map.js:75:24
workerHandler/</<@resource://devtools/client/shared/worker-utils.js:115:52
workerHandler/<@resource://devtools/client/shared/worker-utils.js:113:13

Resource URL: wasm:
Source Map URL: null

As can be seen, in both scenarios, the shim is being used by the invitation to update to RTCRtpScriptTransform API. But then there is no mention of WebRTC when the call originates from messenger.com. The warning is replaced by a Content-Security-Policy error. Clearly from messenger.com, there is a mention that "The page’s settings blocked a worker script", probably stopping the worker from establishing the proper WebRTC context/connection.

This could explain a part of the problem.

Now, this doesn't explain why I was not seeing or hearing the person I called in both scenarios. However, the warning about the "Source map error: Error: URL constructor: is not a valid URL." could be our culprit.

Comment 34

[Monica Chiorean (OOO August 21st 5:30PM)]

Still reproducing on Firefox 148.0b4, and according to this page Firefox is not on the supporting browsers list https://www.facebook.com/help/597429858389632/

Comment 35

[Alexandre Demers]

I've been trying to figure out why www.messenger.com doesn't work at all. Definitively, "Content-Security-Policy: The page’s settings blocked a worker script (worker-src) at data:text/javascript,(function work() { …" is the part preventing createEncodedStreams() from going through. I don't know if using a blob in tandem with createObjectURL() could solve this problem. I've read many warnings about using data:text/javascript for this usage in a worker.

Comment 36

[kanapa1]

It's no secret that RTCRtpScriptTransform was part of Interop 2025 and that it has been baseline across browsers since late last year. So yes, technically Meta has everything they need to move away from the non-standard createEncodedStreams(), but will they actually want to do anything about it? That's the real question...

We've seen this movie before. Just look at how long Microsoft Teams relied on Plan B from WebRTC SDP. Only after Google finally officially announced the deprecation and planned removal of Plan B from Chromium, did Microsoft feel enough pressure to migrate to Unified Plan and bring Teams in line with where it should have been from the start.

I'd expect a similar pattern here. Meta will likely keep relying on createEncodedStreams() for as long as they can get away with it. Realistically, that probably means until Google formally deprecates it and puts it on a removal timeline in Chromium, which won't happen for several years at best, if at all.

That said, out of the two approaches being discussed here, the better one might actually be—somewhat counterintuitively—to lift the webcompat intervention restrictions and simply let it run, even if the experience leaves a lot to be desired.

A blunt message along the lines of "Voice and video calls are not supported in this browser" doesn't really do Firefox any favors. To the average non-technical user, that doesn't read as "Messenger is not standards-compliant". Instead, it reads as "Your browser is broken". And since everything supposedly works flawlessly everywhere else (at least according to the message), the natural conclusion is that Firefox is the problem. That's not an accurate reflection of reality, and it risks reinforcing a narrative that is both misleading and unfair.

By contrast, when there's no such message, the webcompat intervention is active, and certain one-to-one calls don't work reliably yet (based on other users' comments, as personally, I haven't had a chance to test this myself, more on that below), the same users are much more likely to attribute the issue to the website itself. And in this case, that attribution would actually be... correct. Because, objectively speaking, the responsibility lies entirely with Meta. That's it. User criticism directed at them is therefore fully justified.

Perhaps increased pressure from users of the web versions of Messenger and Facebook, and a steady stream of reports hitting Meta's support channels, might be exactly what's needed to elevate this from a low-priority "edge case" to something they finally treat as a real dealbreaker. Sometimes external pressure, especially at scale, is the only thing that moves the needle. This might be one of those cases, who knows?

As for my personal experience with E2EE calls in Messenger with the webcompat intervention enabled, I'm unfortunately unable to test this at the moment, for the reasons described in the final paragraphs of my previous comment last month. In the meantime, however, I've filed bug 2015894, so if all goes well, I may be able to get more involved in the near future.

Comment 37

[osakawebbie]

I just got a notification that makes this issue even more critical:

"Starting April 2026, messenger.com will no longer be available for messaging. The Messenger desktop app is also no longer available. You can use facebook.com/messages to continue messaging on web."

The difference between messenger.com and facebook.com/messages appears to be just a location change (the interface at facebook.com/messages looks identical, and the chat icons are still disabled), but discontinuing the desktop app is a big deal, because that was the primary recourse for Firefox users like me who want to answer or initiate a video/audio chat without logging into Facebook on a different browser or using their phone. Perhaps I'm a dinosaur, but when I'm home all day working at my computer, my phone is often in another room completely unused.

I hadn't noticed that the Messenger desktop app had stopped working - I don't know when that happened. But when I opened it now, it told me to install the Facebook app. That app is apparently not independent but running on Edge somehow - the Microsoft Store says, "This app requires the latest version of Microsoft Edge." Grrr! I have my Meta activity carefully separated from other things I do, using the "Facebook Container" extension to Firefox's wonderful container tabs feature. I almost never use Edge as a browser, but I wouldn't be surprised if logging into Facebook on that "app" will allow Microsoft and Meta to share information about my activity. I sure hope you guys can work something out, or Meta does the right thing and moves away from non-standard dependencies.

Comment 38

[Masa Péter]

Sorry if it is unwanted advice, but from a privacy point of view, you are better of having messenger in any web browser than using the messenger desktop app. The reason for that is that even on google chrome, what a website has access to is very limited compared to apps running on your computer. Contrary to webapps in a browser, the messenger desktop app had access to all your personal files, the list of running programs on your computer with the ability to track how does that change in time, access to microphone and webcamera without an effective permission dialog, and much more.

That being said, short of being able to leave facebook's services behind, the next best option would still be being able to use messenger for calls in Firefox.

Comment 39

[DNAKentang]

so til now, no fix yet? or on nighly/beta version the call already works?

Comment 40

[Alexandre Demers]

No fix yet. I've been trying a few things over here, but none gave me a good result. There seems to be a sync issue.

However, even if the current code were to be an easy fix, I'm pretty sure the current implementation is no optimal.

Comment 41

[DNAKentang]

(In reply to Alexandre Demers from comment #40)

No fix yet. I've been trying a few things over here, but none gave me a good result. There seems to be a sync issue.

However, even if the current code were to be an easy fix, I'm pretty sure the current implementation is no optimal.

i see, somehow it's wild seeing facebook now, they only support chrome and not the other.
imagine essential feature locked for other browser to use
this is wild

Comment 42

[osakawebbie]

Does this mean that there is nothing more that can be done from the Mozilla side of things? Several months ago, Jan-Ivar was working on it and had something in nightlies for people to try (I didn't try it, but others reported issues), then it got quiet, and now Jan-Ivar is off the case.

Comment 43

[Pranav bhattarai]

For such a popular website, according to global ranking and usage, the bug unfortuanately remaining open for more than 2 two years, prove why Firefox users had to migrate willingly or unwillingly. Or have to do courtesy by keeping an alternative browser standby just in case like these.

Comment 44

[Thane K. Sherrington]

I agree with Pranav. While the separate Messenger app hid this problem for a long time, now that Facebook as killed it, the only option for users is to run two browsers or give up on Firefox completely. Is there really no way to fix this?