Calendar prompts for password without specifying username
Categories
(Calendar :: General, defect)
Tracking
(Not tracked)
People
(Reporter: om, Unassigned)
References
Details
Steps to reproduce:
Create new CalDAV calendar with Properties of the form
Username: username@server.domain
Location: https://server.domain/dav/username/Calendar/
And then synchronize the calendar.
Actual results:
You are presented with a generic username/password popup prompt without the username part being filled in.
Unless you fill in the full username@server.domain part exactly as specified in your CalDAV calendar Properties you will be re-prompted for this value the next time Thunderbird starts up, in spite of giving a username/password combo that works (for example, by just entering your username without the server.domain part), and selecting to remember the data you entered.
Expected results:
The username/password prompt should have the CalDAV Username value from the Properties pre-filled, so that the password ends up getting stored with the correct username value in the password manager, and you won't be (somewhat confusingly) re-prompted for it the next time Thunderbird starts.
|
Reporter | |
Comment 1•10 months ago
|
||
The prefill you ask for is fixed in bug 1991785, patch D319397, in review. Its commit message does not mention it yet - I will add that - but the change is there: the username from the calendar properties is set on the auth info even when no saved login was found.
The second half of your report, being re-prompted at the next start, has a separate cause and is not fixed by that patch. The lookup filters on the username in the calendar properties, the save uses the name you type into the dialog. Type anything else and the entry is written but never found again. That is bug 2007933, which I am taking.
Both halves of this are fixed in Thunderbird 158:
- The prompt now fills in the username from the calendar properties (bug 1991785).
- If you type a different username and the server accepts it, it is written back to the calendar properties, so the saved password is found at the next start (bug 2007933).
Closing as fixed by those two. On 140 ESR this arrives with the next ESR unless it gets uplifted.
Description
•