1082478 - Use application locale when showing OAuth window

Status: RESOLVED FIXED

(Calendar :: Provider: GData, defect)

Description

[Ed]

Attachment: ProviderGoogleCalendar-German-messages.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140923175406

Steps to reproduce:

Run TB. 


Actual results:

I see a medium size google (browser-like) window asking me to log-in to my account. This window, BTW, does not contain a toolbar with lastpass, which I use to store passwords and login. I logged in. This window starts speaking German to me (instead of English)...and I don't understand anything. I closed this window.

Result: I cannot use Calendar!


Expected results:

1. No question asking to log-in to my account, i.e. as before!
2. No any google-login-window. I hate pop-ups!
3. Even if this google-login-window appears, it should not change the language to German out of a sudden.

Probable reason of the wrong language: Google site chooses language of the page based on current location (Germany), which is totally wrong. I am afraid going to Japan in November ;-(

Comment 1

[Ed]

Guys, try to fix this ASAP as I even do not have access to today's list of planned things. In the future, think before changing anything!!!

Comment 2

[Stefan Sitter [:ssitter]]

Unfortunately this change is enforced by Google because they switch off the simple authentication using username+password next month and only accept authentication using OAuth2 afterwards. Don't know if anything can be changed in Provider for Google Calendar extension.

Comment 3

[Ed]

Is there alternative network calendar similar to Google and supported by lightenning? Honestly, I am getting fed up with google ignorance!

Comment 4

[Anton Derbenev]

Ed, you can switch language at bottom of logon page (scroll it), but even without that, there's really nothing to mess with. There's simple login & password query, and then request to confirm you're giving permission for Calendar and Tasks.

Though there are more problems after. See Bug 1079659

Comment 5

[Ed]

Anton, indeed even if I click "Akzeptieren" my calendars do not work, even If I refresh/synchronize. Two of them have a yellow triangular "!"-miniicon, the 3rd one does not. Calendar is empty. If I click synchronize, yellow mini-icon appears for a short time next to 3rd calendar, then disappears. Nothing works still. How can I see "What is the problem"? There are no messages or anything.

Apart from this, I still wanna write about initial issue.
1. I (or my TB.lightening) has/can ask my google login/password. What is the need to show this google pop-up window? Or, in the other words, can TB.lightening do login for me "behind the scene". I do not want to see all this windows. 

1a. BTW, I am also using our group's calendar with other (group's) login/account. How is this going to work?

2. Even if this login window is unavoidable, can TB.lightening make a hint to google to automatically show login page in THE SAME LANGUAGE as TB UI itself?

Comment 6

[Anton Derbenev]

Ed, 

> How can I see "What is the problem"?

It's not due to login window. Triangle and other is explained in Bug 1079659. I pointed it right away.

> What is the need to show this google pop-up window?

it's called oauth2. See http://en.wikipedia.org/wiki/OAuth. Google will deny direct usage of login/password for calendar access in about a month.

> can TB.lightening do login for me "behind the scene"

One of devs replied, that it wil be against Google rules. They can ban extension for that. Also, they will fight it, because it's feature of auth protocol, that user must exlicitly confirm permissions.

> our group's calendar

if your account has access to it (you see it in web Google Calendar), it should work normally.
But currently all calendars nearly broken (See Bug 1079659).

I'm not sure about developers plans, but for inaccessible calendars they can request another token, that will mean you'll be able to authenticate with different login and password for different calendars. Still, web UI will be used for that.

> Even if this login window is unavoidable, can TB.lightening make a hint to google to automatically show login page in THE SAME LANGUAGE as TB UI itself?

technically, that's what Thunderbird already do when displaying any web page (it's part of HTTP protocol). It's even configurable.
By default (if that setting isn't changed / displayed bold) Thunderbird uses its install language.
Did not find it in GUI, but In config editor (Tools → Options → Advanced → General → Config Editor), it's "intl.accept_languages", which is "en-gb, en" for me currently (though native lang for me is Russian, I'm using en-gb Thunderbird distributive).

So either you've got that setting changed (reset it then), or Google ignores that hint (I've seen many *.google.com pages in an incomprehensible language, despite my browser settings are telling Google to use Russian; my guess it that Google uses geolocation-by-ip to determine language).

Comment 7

[Anton Derbenev]

Ed, see temporary workaround there: https://bugzilla.mozilla.org/show_bug.cgi?id=1079659#c58

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The temporary issues should mostly be resolved. I cannot do much about the language issue as this is controlled by Google. Its a browser window that just follows the usual language selection process. It doesn't show your lastpass toolbar because its not a Firefox window.

Comment 9

[Ed]

Philipp, if you have access to URL, &hl=en should enforce english.

If it is not a Firefox window than what is this? Which_browser window?

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Its a window from Thunderbird. The term "browser" is in this case not the app, but the control element being used to display the website.

&hl=en seems to enforce english even on the OAuth urls, but which locale should I be choosing? I guess I could figure out the locale of the application and use that, I'm just not sure I should hardcode this. For example, what if the locale is not one supported by Google, or Google uses a different format (AB-CD vs AB). I believe the fallback locale is English, but for other users the Geolocation might just work out better than the fallback.

Comment 11

[Ed]

Philipp, the locale should be obviously the one of thunderbird UI. If not supported than fallback to english.

In NO WAY use geolocation. This is ABSOLUTELY wrong, and this is a big mistake that google does!!! Why? Because nowadays people are used to travel. The last thing that I wanna see after arriving to Japan is that login window is in Japanese.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Ok, I'll reconsider this.

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

On the technical side I might have to make some changes to the OAuth2.jsm module provided by Thunderbird. Luckily the Provider has its own copy to work with TB24, but this is just a reminder for me that I need to keep them in sync.

Comment 14

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Consider this FIXED, I will be pushing the code for this as part of bug 1079189. It was a one line fix.