Closed Bug 1304067 Opened 4 years ago Closed 4 years ago
Google Hangouts messages are delayed by about 1-2 minutes
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.
Thanks Jared. Does the GMail website display the email in another desktop browser faster?
I get the messages instantly when using Chrome Canary.
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.
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.
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
Version: unspecified → Firefox 52
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.
@ 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?
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.
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.
@ Chris: Spoofing the user agent to Chrome (or anything else) doesn't change the behaviour. I continue to get the delay.
1 to 2 minutes is the best-case scenario for me at the moment. Average delay is more like 5 minutes.
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.
4 years ago
platform-rel: --- → ?
Whiteboard: [needsdiagnosis] → [needsdiagnosis][platform-rel-Google][platform-rel-GoogleHangouts]
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?
Moving to Andrei/Cornel to assign this for investigation when we have the bandwidth.
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.
Per comment #16, mark 51 as fixed. Hi Ryan, Do we need to update the status of this bug?
Fixed by backout.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Updating the flags accordingly.
4 years ago
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.