Closed Bug 1714071 Opened 5 years ago Closed 4 years ago

Google meet meeting joined but stucks without showing anything

Categories

(Core :: WebRTC, defect)

Firefox 89
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nishanpandit, Unassigned, NeedInfo)

Details

(Whiteboard: QA-not-reproducible)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Just need to join in the meeting in Google Meet.

Actual results:

Meeting is joined but no audios of other is heard.

Expected results:

Meeting to go without any lags.

not sure if it's the same bug, but I've just tried Meet since updating to Firefox 89: connection was ok, but after 10-20 seconds audio and video froze. I had to leave the meet, connect again and I was able to talk for another 10-20 seconds, before it froze again. Again and again. I had to switch to Brave to continue the call (flawlessly). I'm on macOS 11.4

I have a similar issue with things stopping working after ~10 seconds.

Firefox 89 on Ubuntu Linux 20.04. The same started happening on FF 88 too though, so I don't think this is specific to 89. I've had the issue only starting this week.

I have also run across this on Windows 10 19043.1023. It ran for a bit more than 10 seconds -- perhaps 2-3 minutes, but would then wrap itself around the axle hard to the point I had to reboot the machine. My final experiment I had only Firefox with that one tab open, and even after closing the window, the process persisted in the background and rendered the machine fairly unresponsive (several seconds to respond to mouse/keyboard actions). When I got task manager open, it didn't show a great amount of CPU/Mem usage, despite the slow response of the system.

I'm having the same issue as well. Running the latest Firefox 89 on OS X. Screenshare and audio would stop working after 10-20 seconds. It's a consistent behavior that I was able to reproduce every time. I had to switch to Brave for my meetings.

one more bit of information: I tried again yesterday (hoping it might have been a temporary Google problem), and it happened again. When everything froze, I started switching to Brave, but I left Firefox open: I was told by the other party that they were still hearing me while I was doing that. So perhaps it freezes only on one side.

I was not able to reproduce this issue along with 2 other colleagues that joined the same meeting, we were on MacOS, Windows, Linux devices.
Moving this over to WebRTC component so developers can also take a look and ask for further info that could help.
Can any of you please make sure this is not an add-on issue? Let us know if it is also reproducible with addons disabled.
Also, it would be good to know if there are any errors shown in the browser console when this issue happens.
Thanks!

Component: Untriaged → WebRTC
Flags: needinfo?(nishanpandit)
Product: Firefox → Core
Whiteboard: QA-not-reproducible

To respond to :tbabos' questions:

I am experiencing this issue as well - I connect to a call, and I can see there are other members on the call, but I cannot see their video or hear them (just the blank squares showing they exist).

I have disabled all my add-ons, and checked that I'm not part of any studies (about:studies). The issue is still reproducible.

If I open a private window and then join the call, it works once, and then if I refresh it does not work after that.

I tried deleting all my cookies and site data, and then it worked once (outside of private mode). However, when I tried that again afterward (deleting all cookies/site data), it didn't work.

In my personal profile (I have a work profile and a personal profile), it seems to work fine. I can connect, refresh and reconnect just fine. But for some reason my work profile doesn't want to work.

I'm pretty baffled. If there's any logs or anything I can help to investigate let me know.

UserAgent: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0"

I was able to fix this by clicking the "Refresh Firefox..." button under about:support. So something in my profile was causing issues? I don't know.

(In reply to Craig from comment #2)

I have a similar issue with things stopping working after ~10 seconds.

Firefox 89 on Ubuntu Linux 20.04. The same started happening on FF 88 too though, so I don't think this is specific to 89. I've had the issue only starting this week.

Update from my prior comment:
I just had a 30-minute Google Meet call that worked perfectly. The one thing that changed for me was that the new Google Meet UI (version?) showed up. I don't know if there were other changes deployed as part of that or if it's entirely unrelated, but this happens to be the first successful call I've had in a while with FF. Previously the issue described here happened 100% of the time.

Thanks everyone for reporting! - With so many reports, it sounds like something is up with Meet in Firefox, but we cannot reproduce in-house.

Unfortunately, sites like Google Meet are complicated, they make different decisions wrt WebRTC based on browser-sniffing, and may even have different servers with different versions in play. Thus things working in other browsers doesn't rule out this being a site bug.

We're not seeing reports of this problem with other services (which would have been a good indicator of a Firefox bug, though this doesn't rule it out). Comment 3 seems like a more serious bug but an outlier not observed by others (does it reproduce?)

The same started happening on FF 88 too ... The one thing that changed for me was that the new Google Meet UI (version?) showed up

This suggests site changes, which suggest site issues.

The most useful thing for us to determine if this is a bug in Firefox or Meet, if you can reproduce reliably, would be to ask you to use the mozregression tool to reproduce this in older versions of Firefox to narrow down a regression range. If you find one, this is most likely a Firefox bug. If Meet is equally broken in older versions of Firefox, it is most likely a Meet issue, and we would redirect this to Google to address.

I tried to do some testing yesterday: I wasn't able to reproduce it 100% of the times. Actually, it worked too well when I hoped it would freeze! Then as soon as I did an actual work call, it froze. :(

When you tested in-house, did you try adding participants with Chrome in the mix? At this point I'm not sure it has anything to do with it, but I got the worst results when I was testing it in a meet with Chrome + Firefox (and when it happens with my co-workers, most of them use Chrome).

I even tried disabling all extensions and enabling them again. I actually managed to do an uninterrupted call with all of them active, but it felt a like random act.

Console didn't report any significant error, although it always has these two warnings when opening a meet link (before you join the meet):

Content Security Policy: Impossibile elaborare la direttiva sconosciuta “require-trusted-types-for” (= "unable to process the unknown directive...")
webrtc.peerconnection.datachannel_created - Unknown scalar. (repeated 2-3 times)

Those "Unknown scalar" warnings are benign and can be safely ignored. I've filed bug 1715258 for the cleanup task to remove them.

(In reply to Harrison from comment #4)

I'm having the same issue as well. Running the latest Firefox 89 on OS X. Screenshare and audio would stop working after 10-20 seconds. It's a consistent behavior that I was able to reproduce every time. I had to switch to Brave for my meetings.

I am no longer having issues with Google Meet. I have had several meetings this week, long and short. Both audio and screen share are working as expected. I didn't change anything nor did I disable any plugin. It was likely a site issue.

I am no longer having issues with Google Meet

Same for me. I've been using it all week with no issues at all.

Seems like a transient site issue.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.