Google Meet and Hangouts stopped working in Firefox 63

RESOLVED FIXED

Status

()

P2
normal
RESOLVED FIXED
7 months ago
5 months ago

People

(Reporter: petcuandrei, Assigned: drno)

Tracking

(Blocks: 1 bug, {nightly-community, site-compat})

63 Branch
nightly-community, site-compat
Points:
---
Dependency tree / graph
Bug Flags:
webcompat ?

Firefox Tracking Flags

(firefox61 unaffected, firefox62 unaffected, firefox63+ fixed, firefox64+ fixed)

Details

(Whiteboard: [webcompat])

Attachments

(1 attachment)

(Reporter)

Description

7 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180830220110

Steps to reproduce:

I created a new browser profile from about:profiles.
I tried to join hour company's Google Meet meeting. I cannot share the URL but it's something like this https://meet.google.com/xxx-yyyy-zz


Actual results:

I got an error as you can see in the print screen I attached.


Expected results:

It should have worked. I tried in Firefox stable and it works fine. I'm on Ubuntu 18.04. Both NIghtly and Stable are from Mozilla's web site not from Ubuntu's package manager and PPAs. This started happening yesterday and I keep my Nightly up to date.
Keywords: regression, regressionwindow-wanted
Keywords: nightly-community
Nils, I can repro this by simply creating a room on meet.google.com.
Status: UNCONFIRMED → NEW
Component: Untriaged → WebRTC
Ever confirmed: true
Flags: needinfo?(drno)
Priority: -- → P2
Product: Firefox → Core
(Assignee)

Comment 2

7 months ago
Yes. It fails because Hangouts changes the MID between createOffer() and setLocalDescription(). Firefox Nightly creates the offer with 'a=mid:0', but then the SDP in setLocalDescription() has 'a=mid:mid_0' in it. Unfortunately Firefox doesn't recognize that. But when setRemoteDescription() gets called with the SPD answer also with 'a=mid:mid_0' then Firefox complains about the answerer changing the MID which is a spec violation.

I'll reach out to the Hangouts team.
Flags: needinfo?(drno)
(Assignee)

Updated

7 months ago
Summary: Google Meet stopped working in Nightly → Google Meet stopped working in Nightly 63
(Assignee)

Updated

7 months ago
status-firefox61: --- → ?
status-firefox62: --- → unaffected
status-firefox63: --- → affected
(Assignee)

Comment 3

7 months ago
I'm pretty sure that Hangouts was still working at the beginning of this week. My guess is that Hangouts has deployed some new code which causes this problem.
status-firefox61: ? → unaffected
Tracking for 63 as the affected site is a major site
status-firefox64: --- → affected
tracking-firefox63: --- → +
Whiteboard: [webcompat]
Keywords: regression, regressionwindow-wanted
Duplicate of this bug: 1488818
(Assignee)

Comment 6

7 months ago
Closing as dupe of bug 1488818 because that bug contains more details.
(Assignee)

Updated

7 months ago
Depends on: 1483338
Summary: Google Meet stopped working in Nightly 63 → Google Meet and Hangouts stopped working in Nightly 63 (soon to be beta)
(Assignee)

Comment 7

7 months ago
Ignore my comment #6. Jib was faster closing the other bug.
(Assignee)

Updated

7 months ago
tracking-firefox64: --- → ?
(Assignee)

Updated

7 months ago
Blocks: 1347055
Hangouts is rewriting the mids in the local description, which is not supported either in the spec, or by the code we have now.
Nils -- I need to assign this to you to make sure we have an answer for this before 63 goes into late Beta. I and others will help to make the right call here. (I realize Hangouts is violating the spec; so the solution should be a fix on their side, but one way or another, we need to resolve this.)
Assignee: nobody → drno
Flags: needinfo?(drno)
(Assignee)

Comment 10

7 months ago
Yes we are in contact with the Hangouts team. And it looks like they are going to be able to fix this on their end. I'll keep this bug report here updated.
Flags: needinfo?(drno)
(Assignee)

Updated

7 months ago
Blocks: 1431543
No longer blocks: 1347055
tracking-firefox64: ? → +
(Assignee)

Comment 11

6 months ago
Sounds like a fix should get deployed on the Hangouts side soon.

Comment 12

6 months ago
Haven't tested it with actual people yet, but it now loads.
Meet is still not working, though...
Blocks: 1483338
No longer depends on: 1483338
(Reporter)

Comment 14

6 months ago
It's still broken for me also.
(Assignee)

Comment 15

6 months ago
Meet was still broken for me earlier today, but now it seem to be finally fixed for me.

To my surprise Hangouts still re-writes the MIDs, but now from '0 1 2' to '3 4 5'.
Byron do you think that is okay (besides still violating the spec), or is this going to cause problems later?
Flags: needinfo?(docfaraday)
(Reporter)

Comment 16

6 months ago
Works fine for me now.
(Assignee)

Comment 17

6 months ago
(In reply to andreip from comment #16)
> Works fine for me now.

Thanks Andrei for the initial report and verifying that it works again!
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
Summary: Google Meet and Hangouts stopped working in Nightly 63 (soon to be beta) → Google Meet and Hangouts stopped working in Firefox 63
(In reply to Nils Ohlmeier [:drno] from comment #15)
> Meet was still broken for me earlier today, but now it seem to be finally
> fixed for me.
> 
> To my surprise Hangouts still re-writes the MIDs, but now from '0 1 2' to '3
> 4 5'.
> Byron do you think that is okay (besides still violating the spec), or is
> this going to cause problems later?

If it has only changed the format of the mids it generates, I would expect this still to fail. Let me look at what it is doing...
Ok, I don't see any mid rewriting, although I do see Firefox selecting new mids when createOffer is called twice in a row. That's not intended, but not really harmful either.
Flags: needinfo?(docfaraday)

Comment 20

6 months ago
> To my surprise Hangouts still re-writes the MIDs, but now from '0 1 2' to '3 4 5'.

Nils, that's really weird. Are you seeing it in every Hangouts call? I thought we fixed all the cases around this :)

Comment 21

6 months ago
Oh, by the way, we do call createOffer() multiple times in some cases, so it's very possible that we are not using the original offer SDP, but a later one that Firefox generated. Could that be it?
(Assignee)

Comment 22

6 months ago
(In reply to Saeed Jahed from comment #21)
> Oh, by the way, we do call createOffer() multiple times in some cases, so
> it's very possible that we are not using the original offer SDP, but a later
> one that Firefox generated. Could that be it?

Yes after Byron looking into it turns out that I missed the fact that the API trace looks like this:

"2018-09-17T20:13:19.987Z createOffer":"([{}])"
"2018-09-17T20:13:20.022Z createOfferOnSuccess":{...
}
"2018-09-17T20:13:20.572Z getTransceivers":"([])"
"2018-09-17T20:13:20.572Z createOffer":"([{}])"
"2018-09-17T20:13:20.573Z - get remoteDescription":"{}"
"2018-09-17T20:13:20.575Z createOfferOnSuccess":{...
}
"2018-09-17T20:13:20.575Z setLocalDescription (offer)":{...
}

When I looked at the first offer I saw 0, 1, 2. And when I looked at the remote description I saw 3, 4, 5, so I thought that there was some rew-rite. But I missed that you had called createOffer() again and dropped the initial offer. So as Byron said it's fine.

Byron, do you think we should file a follow up bug for Firefox creating new MID's when the offer never was passed to sLD()?
Flags: needinfo?(docfaraday)
I've filed bug 1491957
Flags: needinfo?(docfaraday)
(Assignee)

Comment 24

6 months ago
It's fixed now, but might be still good for the webcompat folks to know about it.
Flags: webcompat?
status-firefox63: affected → fixed
status-firefox64: affected → fixed
Keywords: site-compat
You need to log in before you can comment on or make changes to this bug.