901329 - Thunderbird doesn't start when using master password and Google CalDAV OAuth2 authentication

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Stefan Sitter [:ssitter]]

Follow up for Bug 853236 Comment 10:

1. setup a master password
2. connect to Google Calendar using the new CalDAV endpoint 
   https://apidata.googleusercontent.com/caldav/v2/{calid}/events
3. fill in the OAuth prompt and allow Lightning to access Google Calendar
4. restart Thunderbird

Actual error:
Thunderbird will not startup anymore, the master password prompt will appear partially but is not operable and Thunderbird uses 100 % CPU cycles.

Comment 1

[Stefan Sitter [:ssitter]]

Google will will shut down CalDAV via http authentication in September 2013. If many user switch to CalDAV via OAuth authentication and Lightning 2.6 they might be affected by this bug.

Comment 2

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

I see this is an issue that needs fixing, but I won't have time to take care before September 5th. Do you think you could spend a little time to debug this? I would be delighted!

Comment 3

[Matthew Mecca [:mmecca]]

Confirming on Ubuntu.

The master password dialog appears empty, but interestingly you can still type the password and press enter, and everything loads normally.

The master password is prompted when we call into Services.logins.findLogins() here:
http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calAuthUtils.jsm#123

Comment 4

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

I think we call the master passwords dialog blocking (which we have to), which might not play well with that dialog. Maybe we can force the master password retrieval before the dialog opens?

Comment 5

[Matthew Mecca [:mmecca]]

Attachment: Workaround v1

It seems like the master password dialog is having trouble because it's being loaded too early, maybe because the app window isn't loaded yet?

I'm not sure if this is the best way to go, but adding in a delay before setupAuthentication seems to get it working right, but I've only had time to test it briefly.

Comment 6

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

Comment on attachment 800769 [details] [diff] [review]
Workaround v1


>-            this.setupAuthentication(aChangeLogListener);
>+            let self = this;
>+            function doSetupAuthentication() self.setupAuthentication(aChangeLogListener);
>+            setTimeout(doSetupAuthentication, 1);

You can also do setTimeout(this.setupAuthentication.bind(this, aChangeLogListener), 0);


It sounds reasonable and from a brief look I don't think it will interfere. We just need to make sure this doesn't increase the number of master password prompts. f+, but I'd appreciate if Stefan could give this patch a test.

Comment 7

[Matthew Mecca [:mmecca]]

With a second calendar added using the v2 API I get 2 master password prompts with or without this patch applied. Without the patch applied the original issue went away, I suspect the initialization code on the additonal calendar provided enough of a delay on its own to avoid the problem.

Comment 8

[rigius]

I have worked around the probem activating the StartupMaster plugin (asks for master password at startup). This is on TB Windows v24 with Lightning v2.6.

Comment 9

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

I've been toying around with this a bit. One easy solution is to follow what StartupMaster does and load the master password prompt early, i.e remove the isSunbird condition in calCalendarManager. This only postpones the problem though: if you cancel the first dialog, you run into the same situation. 

I tried using msgAsyncPrompter, but this doesn't really work, as it expects the onPromptStart function to be synchronous. Using the thread manager to spin the event loop didn't work.

Using a timeout is rather random, values 0, 1 or 100 don't work for me on mac. I'm not sure how to solve this correctly unfortunately.

Comment 10

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

Attachment: Fix - v2

Ok, I've found a solution for this that sticks and also fixes a few more issues. First of all this fixes bug 921744 by using the async prompter from Thunderbird. Next up, when the browser window for authentication is just closed we used to not do anything about it. Then I'm geting rid of an extra error message in the console when the master password dialog is cancelled.

The fix for this bug is actually to wait until the main window is loaded. This makes the master password dialog show up correctly. I'm aware this can cause problems if there is no main window, but I'm not sure how to better fix this. As mitigation, maybe it makes sense to add a maximum timeout? Doesn't make me feel much better though.

Comment 11

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

Attachment: Fix - v3

Oops, missing qrefresh. Here it is.

Comment 12

[Matthew Mecca [:mmecca]]

Comment on attachment 812567 [details] [diff] [review]
Fix - v3

Looks good. r=mmecca

Comment 14

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

Please push to all branches: c-c, c-a, c-b and comm-esr24.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/d3e6499acad3
https://hg.mozilla.org/releases/comm-aurora/rev/64a0823dc132
https://hg.mozilla.org/releases/comm-beta/rev/e60119b64401
https://hg.mozilla.org/releases/comm-esr24/rev/f95ff97a359b