Google Talk has been gone for some time, and as far as I can tell, this functionality no longer does anything -- the server it talks to(possibly used for Hangouts now) just throws an "Error during SRV: Lookup failed." in the error console.

If it can no longer be used as I suspect, we should remove it as it's misleading to have it listed.

Google Talk works fine for me, I chat with people everyday over it...

Sounds like there might be a more specific issue here to file.

(In reply to Patrick Cloke [:clokep] from comment #1)

Google Talk works fine for me, I chat with people everyday over it...

Sounds like there might be a more specific issue here to file.

This comment really baffled me, as Google shut this service off years ago and deleted the Windows app. But apparently there is still some way for 3rd party clients to use the old server to talk to Hangouts users with very limited functionality. It seems you need to make an app password to sign in, I'm not even sure it's possible to make oauth work with this as bug 1238631 needs. And it is pretty confusing for this to be labeled Google Talk, since the service is called Hangouts now and has a different logo.

Also, I do think this system is still going to be turned off in 2020 with the "classic hangouts" deprecation(see: https://support.google.com/a/answer/9197126). But I am clearly wrong that it was turned off already, it hasn't been.

(In reply to Andrei Hajdukewycz [:sancus] from comment #2)

(In reply to Patrick Cloke [:clokep] from comment #1)

Also, I do think this system is still going to be turned off in 2020 with the "classic hangouts" deprecation(see: https://support.google.com/a/answer/9197126). But I am clearly wrong that it was turned off already, it hasn't been.

Google Hangouts for GSuite users is shutting down, Hangouts for consumers will probably never shut down.

(In reply to Andrei Hajdukewycz [:sancus] from comment #2)

This comment really baffled me, as Google shut this service off years ago and deleted the Windows app. But apparently there is still some way for 3rd party clients to use the old server to talk to Hangouts users with very limited functionality. It seems you need to make an app password to sign in, I'm not even sure it's possible to make oauth work with this as bug 1238631 needs.

Oddly I do have 2FA enabled on my account and can login OK! I do seem to have an app password set, however. It is likely a legacy app password that has full permission on my account. (I'm not sure you can create those anymore.)

And it is pretty confusing for this to be labeled Google Talk, since the service is called Hangouts now and has a different logo.

I can't really argue with this, you're right. :)

Also, I do think this system is still going to be turned off in 2020 with the "classic hangouts" deprecation(see: https://support.google.com/a/answer/9197126). But I am clearly wrong that it was turned off already, it hasn't been.

I'd suggest we lave it for now and revisit if/when it breaks!

Looks like Google Talk might actually be shutting down now, see https://support.google.com/talk:

Learn about Google Talk for third-party apps

We’re winding down Google Talk. On June 16, 2022, we'll end our support for third-party apps, including Pidgin and Gajim, as we announced in 2017.

To continue to chat with your contacts, we recommend using Google Chat. You can more easily plan with others, share and collaborate on files, and assign tasks with Chat's enhanced Spaces feature. You also have the same strong phishing protections we build in Gmail and accessibility features like screen reader support.

Switch to Google Chat

Important: If you try to sign in to Google Talk on or after June 16, 2022, you'll get a sign in error.

We recommend switching to Google Chat.

• You can access Google Chat on the web and mobile, or you can add it to your Gmail inbox to collaborate in one place.
• Learn more about how you can export your data and hide or delete your conversations in Google Chat.

Talking with Martin our plan is going to be to land a string on 102 which talks about Google Talk being disabled. Once we confirm things stop working we can uplift a patch disabling things.

Here is something somebody is working on as an alternative in Pidgin: https://github.com/EionRobb/purple-googlechat

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/f2503a5e00ee
Include a localized string for Google Talk being disabled. r=freaktechnik

It feels a bit weird setting the milestone, given how little landed, but that's what we do…

I put up attachment 9279923 [details] for review in preparation for Google disabling the XMPP gateway on June 16, 2022. I think we should wait to confirm that happens before landing, but I wanted a patch ready. We might need to slightly tweak it for ESR if removing strings is not allowed.

I think we should probably combine the implementations for dead protocols, but wanted to keep this patch more straightforward than that since I wouldn't want to uplift that to ESR.

The attached patch is approved, from my point of view, this is safe to land once verification that Google Talk is actually disabled is done. We'll need to update the patch for backport to 102 beta, unfortunately. I'll try to do that soon.

Looks like Google Talk might finally be offline? I'm now getting the following with a valid password (and also with OAuth2):

<failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
 <not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
 <sta:service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xmlns:sta="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</failure>

This results in being unable to login.

This results in an error:

No authorized. (Did you enter the wrong password?)

Which is non-sense, I wonder if we're not properly parsing the error returned to us...or if that's the best we can do.

(In reply to Patrick Cloke [:clokep] from comment #14)

This results in an error:

No authorized. (Did you enter the wrong password?)

Which is non-sense, I wonder if we're not properly parsing the error returned to us...or if that's the best we can do.

presumably that's our error string for <not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

Also seeing this error on my account now, it might be time to land the patch for this. Patch doesn't apply to c-c for me anymore.

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/9de180b6e21f
Remove Google Talk. r=freaktechnik

Comment on attachment 9279923 [details]
Bug 1645217 - Remove Google Talk. r=freaktechnik

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Google Talk will fail to connect with an obscure error message: "No authorized. (Did you enter the wrong password?)"
Testing completed (on c-c, etc.): Landed on c-c
Risk to taking this patch (and alternatives if risky): Low, most changes are within the Google Talk protocol implementation, but it does also touch the generic XMPP code slightly and the OAuth2 code, mostly to back out bug 1238631. I think there's a risk to not taking the OAuth2 changes in case the scopes disappear (potentially breaking Gmail access itself).

Comment on attachment 9279923 [details]
Bug 1645217 - Remove Google Talk. r=freaktechnik

[Triage Comment]
Approved for beta

If this is easily backported to version 91 I think we should do so. Although official support ends in ~3 months, it will in practical terms be actively used by many users for much longer.

I think the issue with 91 might be the string to show as connection error. Unless you're fine with showing a more generic connection error and handling it on the support side?

Thunderbird 103.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/1486ba991767

(In reply to Wayne Mery (:wsmwk) from comment #21)

If this is easily backported to version 91 I think we should do so. Although official support ends in ~3 months, it will in practical terms be actively used by many users for much longer.

As Martin said, the code itself should be fairly easy to backport, but we would need some sort of string to show, some options which exist are:

• Unavailable
• The server closed the connection
• Received unexpected data
• Received an incorrect response
• This server does not support XMPP

(Those are all XMPP strings which have existed forever. There might be others in other parts of the app that would be usable too.)

I plan to uplift this to ESR 102, which does have the expected string on it already.

Backport for ESR 102. The changes are due to how modules are imported / lazy imports.

The ESR 91 patch is different enough that it should probably go under re-review. It is very slimmed down since it doesn't need to back out bug 1238631. It uses the string: "This server does not support XMPP" instead of a Google Talk specific string.

Comment on attachment 9284736 [details] [diff] [review]
ESR 102 patch

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Google Talk will fail to connect with an obscure error message: "No authorized. (Did you enter the wrong password?)"
Testing completed (on c-c, etc.): Landed on comm-central and comm-beta. This patch is mostly identical.
Risk to taking this patch (and alternatives if risky): Low, most changes are within the Google Talk protocol implementation, but it does also touch the generic XMPP code slightly and the OAuth2 code, mostly to back out bug 1238631. I think there's a risk to not taking the OAuth2 changes in case the scopes disappear (potentially breaking Gmail access itself). Not taking this to ESR 102 will likely cause support burden.

Comment on attachment 9284739 [details] [diff] [review]
ESR 91 patch

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Google Talk will fail to connect with an obscure error message: "No authorized. (Did you enter the wrong password?)"
Testing completed (on c-c, etc.): Landed on comm-central, comm-beta.
Risk to taking this patch (and alternatives if risky): Low, almost all changes are contained within the Google Talk protocol implementation. It slightly touches the generic XMPP code. I think this is fairly safe to backport (worst case the protocol doesn't work anyway, but it can't connect so...)

I should note -- I was unable to build either ESR 102 or ESR 91 in order to test this patch, I think they'll be OK, but not 100% positive.

Comment on attachment 9284736 [details] [diff] [review]
ESR 102 patch

[Triage Comment]
Approved for esr102

Comment on attachment 9284739 [details] [diff] [review]
ESR 91 patch

[Triage Comment]
approved for esr91

Thunderbird 102.0.3:
https://hg.mozilla.org/releases/comm-esr102/rev/2a1d5f33ec98

Thunderbird 91.12.0:
https://hg.mozilla.org/releases/comm-esr91/rev/718976203b44