1304067 - Google Hangouts messages are delayed by about 1-2 minutes

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

I get notifications about new messages in Google Hangouts (through GMail) on my Android phone (using the Hangouts app) but it takes about 1-2 minutes for the message to appear on the GMail website on my desktop.

GMail displays a warning message saying "Incoming messages may be delayed". I only started seeing this a day or two ago.

I'm running 52.0a1 (2016-09-19) (64-bit) on Windows 10.

Comment 1

[Adam Stevenson [:adamopenweb]]

Thanks Jared. 
Does the GMail website display the email in another desktop browser faster?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

I get the messages instantly when using Chrome Canary.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Note, comment #1 says "display the email" but this bug is specifically about the hangout messages which is Google's instant messaging/chat functionality built in to Gmail.

Comment 4

[Adam Stevenson [:adamopenweb]]

Oops, sorry I meant message. I am able to reproduce this issue in Firefox 52 on OSX and Windows 10. It doesn't reproduce in Firefox 51. The same issue occurs on https://hangouts.google.com.

I tested sending a message from an Android phone to the Gmail and Hangouts websites on desktop. They both took > 1 minute to receive the message (hangouts slightly before). 

When sending a message out from Hangouts website to the phone and watching Gmail as well, the phone receives the message instantly. But Gmail takes a couple minutes for it to get through, see screenshot.

Comment 5

[Adam Stevenson [:adamopenweb]]

Attachment: hangouts screenshot.png

Comment 6

[Adam Stevenson [:adamopenweb]]

Forgot to add a few things: 

- Changing the user agent to Firefox 51 has no effect.

- When the website is waiting for an incoming message from the phone, sending a message to the phone does not make the incoming message appear any faster.

- If you open hangouts.google.com in Fennec 52 and request desktop site the issue reproduces, but doesn't in 51

Comment 7

[Simon Lindholm]

mozregression points to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=facf5812faffa05e6037e96c92a5835d12937966&tochange=8639daa019b6c8efbcd773bd56bc7dd302984138, so bug 918719.

Toggling dom.fire_extra_xhr_loading_readystatechanges (the commit message lies; it's not dom.send_multiple_xhr_loading_readystatechanges) makes Hangouts work properly again.

I've seen old Etherpad installations break recently as well, and flipping the pref seems to fix that too.

Comment 8

[Chris Peterson [:cpeterson]]

@ Thomas: looks like Google Hangouts and Etherpad may be broken by your XHR readystatechange changes from bug 918719.

@ Adam or Jared: Can you reproduce the Hangouts delay if spoofing a Chrome UA in Firefox? The change Thomas made should have brought Firefox's XHR behavior more in line with Chrome's. Maybe Hangouts is expecting the previous Firefox behavior.

@ Simon: do you have STR or a bug for the old Etherpad problems?

Comment 9

[Simon Lindholm]

Create a new pad at https://edupad.ch/ and also open it in some other browser. Type something. Only the first letter or so will show up in the other browser, and after a while adding another letter will yield a "disconnected" message.

I haven't filed a bug for that, I just noticed that it was related when writing the last comment. I suppose I could file one if needed.

Comment 10

[Thomas Wisniewski]

Since that Etherpad still works in Chrome and Webkit, it seems that it's also probably doing something it shouldn't have to for Firefox. Assuming both Hangouts and Etherpad support standard XHR progress events for those browsers, they should also be using them for Firefox. If they have reasons not to, they should be encouraged to file a bug report explaining what forces them to use this obsolete method instead.

Comment 11

[Adam Stevenson [:adamopenweb]]

@ Chris: Spoofing the user agent to Chrome (or anything else) doesn't change the behaviour. I continue to get the delay.

Comment 12

[Kyle Repinski]

1 to 2 minutes is the best-case scenario for me at the moment. Average delay is more like 5 minutes.

Comment 13

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Bug 918719 has been backed out from inbound. Should be in either tomorrow's nightly build or the next day's depending on the timing of the next merges.

Comment 14

[Gerry Chang [:gchang]]

Hi Florin,
From https://bugzilla.mozilla.org/show_bug.cgi?id=918719#c50, it's also backed out in 51 aurora. Can we have some QA's help to verify this in latest nightly & aurora?

Comment 15

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Moving to Andrei/Cornel to assign this for investigation when we have the bandwidth.

Comment 16

[Alexandru Simonca [:asimonca], Release Desktop QA]

I have reproduced this issue using Nightly 52.0a1 (id: 20160928030201) and got about the same results as in Comment #0.

I have also verified the issue on Nightly 52.0a1 (id: 20161006030208) and Aurora 51.0a2 (id: 20161007004004) and the issue is not reproducible anymore. 

Note 1: This was verified on Windows 10 x64.

Comment 17

[Gerry Chang [:gchang]]

Per comment #16, mark 51 as fixed.

Hi Ryan,
Do we need to update the status of this bug?

Comment 18

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Fixed by backout.

Comment 19

[Alexandru Simonca [:asimonca], Release Desktop QA]

Updating the flags accordingly.