1994131 - calendar asking for changed password does not suggest/prefill the existing username

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Axel Fleischer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0

Steps to reproduce:

Changed a CamDAVs password, opened TB.

Actual results:

Calendars asks for the new password but does not provide the username or at least the calendar name. Its a new behaviour, did work in 128.
It's a problem, because if you are subscribed to multiple calendars and did change all the passwords, you wont know what calendar asks you for the password.

Expected results:

Provide the existing (in prefs.js) username while asking for the new password.

Comment 1

[Magnus Melin [:mkmelin]]

If you're sure it worked in 128, please try to get a regression range using mozregression - https://mozilla.github.io/mozregression/

Comment 2

[Nico D.]

The regression is bug 1965727, changeset c390ec39dc19, Target Milestone 140 Branch. Before it, the user name from the calendar properties was set on the auth info unconditionally; since then it is only set when a saved login was found, so the field is empty in exactly the case where you need it.

That part 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 user name is set even when nothing was found, so the dialog names the account instead of showing an empty field.

Two things this report asks for are not covered by it. The dialog still does not name the calendar, which I am looking at here. And a user name typed into the dialog is not written back to the calendar properties, so you are asked again on the next start - that is bug 2007933, which I am also taking.

Comment 3

[Nico D.]

Setting the regressor from code analysis, so it can be checked: bug 1965727 moved the assignment of the username into the branch that runs when a saved login was found. Before that, the caller set it unconditionally - including on the path where the login had just been dropped, which is the path you are on after a password change. That is why the field was filled in 128 and is empty now.

Bug 1991785 sets the username again in all cases. The calendar name in the dialog text, which you also asked for, is still missing.

Comment 4

[Nico D.]

Attachment: Bug 1994131 - Name the calendar in the dialog that asks for its password. r?#thunderbird-reviewers,#thunderbird-back-end-reviewers,#thunderbird-l10n-reviewers

The dialog named only the server it wanted credentials for. Several
calendars can sit on one server, so with more than one subscribed you had
to guess which one you were answering for.

The prompt is created once per provider and could have named it all along.
It was just never told which provider that is - mProvider has been in the
class since the beginning and nothing ever set it.

Comment 5

[Nico D.]

Attachment: Dialog after patch with username filled

Attached is what the dialog looks like with the patch in bug 1991785 and D320417 applied. The calendar name is quoted so it stays readable when the name itself contains brackets, and the user name is prefilled from the calendar's properties.

Comment 6

[Nico D.]

For the record: the prefill half of this landed with bug 1991785 (8fb75afa0d9e). What remains here, and what the patch on this bug does, is naming the calendar in the dialog so you can tell which one is asking.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/49da728dbc43
Name the calendar in the dialog that asks for its password. r=tobyp,mkmelin