Closed Bug 1670464 Opened 4 years ago Closed 3 years ago

Newly Added Additional Identities not Listed in "Alias Identity" Dialog


(Thunderbird :: Account Manager, defect)



(thunderbird_esr78+ fixed, thunderbird82 affected)

87 Branch
Tracking Status
thunderbird_esr78 + fixed
thunderbird82 --- affected


(Reporter:, Assigned: mkmelin)



(Keywords: regression)


(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36

Steps to reproduce:

Account Manager -> Select Account -> Button "Further Identities" ("Weitere Identitäten...") on bottom right -> add additional identity

Actual results:

The new identity is not shown in the dialog. It looks as if creation of the new identity silently failed.

In fact, the new identity was created in the background, however, and the dialog has to be closed and re-opened - then the new identity will be shown. This caused me to create an identity over and over three times until I noticed... :-/

Expected results:

The newly created identity should be shown in the dialog after creation.

Summary: Regression: Newly Added Additional Itentities not Listed in "Alias Identity" Dialog → Newly Added Additional Identities not Listed in "Alias Identity" Dialog

Yep. Basically the End-to-end tab can't work without having an identity so things blow up quite a bit...

Assignee: nobody → mkmelin+mozilla
Ever confirmed: true

What do you mean Magnus?
There is no "end-to-end" tab in the "manage identities" dialog. Also, it was not said that there are no identities at the start (usually at least one is created at account setup), only that new ones do not appear immediately in the list.

This clearly worked in the past. What could have regressed this?

But I confirm it. There are some errors when creating the new identity:

Uncaught TypeError: can't access property "key", gIdentity is null
e2eInitializeFields chrome://messenger/content/am-e2e.js:99
e2eOnLoadEditor chrome://messenger/content/am-e2e.js:561
EventListener.handleEvent* chrome://messenger/content/am-identity-edit.xhtml:44
e2eInitializeFields chrome://messenger/content/am-e2e.js:99
e2eOnLoadEditor chrome://messenger/content/am-e2e.js:561
(Async: EventListener.handleEvent)
<anonymous> chrome://messenger/content/am-identity-edit.xhtml:44

Uncaught TypeError: can't access property "value", gTechChoices is null
e2eSave chrome://messenger/content/am-e2e.js:278
e2eOnAcceptEditor chrome://messenger/content/am-e2e.js:301
onOk chrome://messenger/content/am-identity-edit.js:215
_fireButtonEvent chrome://global/content/elements/dialog.js:487
_doButtonCommand chrome://global/content/elements/dialog.js:466
_handleButtonCommand chrome://global/content/elements/dialog.js:460
_configureButtons chrome://global/content/elements/dialog.js:361
connectedCallback chrome://global/content/elements/dialog.js:163
<anonymous> chrome://global/content/customElements.js:217
EventListener.handleEvent* chrome://global/content/customElements.js:209
<anonymous> chrome://global/content/customElements.js:862
<anonymous> chrome://messenger/content/customElements.js:14
<anonymous> chrome://messenger/content/customElements.js:37
observe resource://gre/modules/MailGlue.jsm:234

Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All

I was referring to the end-to-end tab of where you edit the identity. That tab simply can't work without an email. I checked an older version too and it didn't really work for S/MIME either (shows but couldn't actually set the certificates) but I guess nobody ever reported it.

And what email is it missing? When you create an identity, you input one.

When use Add, you get New Identity, that doesn't have an email yet before you add one - still the E2E tab is there, but can't work.

I noticed the same issue. I guess it is new in Thunderbird 78, it did not happen before. I am using Archlinux.

@magnus: I am not sure if you can reproduce the bug correctly, it seems you two are talking about different issues.

Let me try again:

  1. Open Account settings
  2. Click "Manage Identities..."
  3. Click "Add..."
  4. Enter a Name and a valid Email
  5. Click "Ok"
  6. The new identity is not show in the list
  7. Close the dialog
  8. Click "Manage Identities..." again
  9. The identity is now shown

Exactly the same issue for me, also using Arch Linux and Thunderbird 78.4.3. I have to re-open the "Manage identities"-window after creating the new identity.

Attached patch bug1670464_identity_mess.patch (obsolete) — Splinter Review

Successful try:

Something to look at when you get back :)
There was (and is still) a lot of really messy code in the e2e account/identity settings. I cleaned it up a bit.

The problem here is really that e2e always need an email to be connected to - which doesn't exist when we set up a new identity. Before we have that we can't really do anything for the whole tab. S/MIME has been broken in this regards forever as well... so in this patch I hide the e2e tab until we have an email. It would really be better to have the setup of new identities go through some flow instead of the current setup....

Attachment #9194192 - Flags: review?(alessandro)
Comment on attachment 9194192 [details] [diff] [review]

Review of attachment 9194192 [details] [diff] [review]:

Thanks for taking care of this, and indeed, the SMIME code is a bit messy.
This patch solves the problem when creating an identity, but it breaks a couple of things on the OpenPGP side of things.

I have 2 identities, both with some openPGP keys configured, but only the primary identity has a selected key while the other is set to "None".
Switching between the E2E pages of the 2 identities doesn't properly update the UI:
- The "None" radio button is not selected for the second identity. (It seems partially broken even without this patch, which means something regressed it)
- The description with the selected key above the key list is not visible.
- The description above the key list doesn't update when switching between E2E pages.

::: mail/extensions/am-e2e/am-e2e.js
@@ +612,4 @@
>    reloadOpenPgpUI();
> +
> +  // Update the identity with the key obtained from the key wizard.
> +  gIdentity.setUnicharAttribute("openpgp_key_id", keyId);

I think this should be set before we call the `reloadOpenPgpUI()` method as that method checks for the `openpgp_key_id` attribute.
Attachment #9194192 - Flags: review?(alessandro) → review-

Still broken on ESR 78. Any plans to get this fixed? It's very surprising that you add something and it's not there.

I updated the code but haven't had time to make the test test it yet.

Attached patch bug1670464_identity_mess.patch (obsolete) — Splinter Review

Updated. Will send it to try later.

Attachment #9194192 - Attachment is obsolete: true
Comment on attachment 9202808 [details] [diff] [review]

Review of attachment 9202808 [details] [diff] [review]:

This is good and it seems to work properly, nicely done.

One little issue is with the selection of the "None" radio button, which is not maintained when switching between accounts or when trying to select that option.
It seems that we need to manually set that radio button as selected when the current key is an empty string.

r+ with that fix.

::: mail/extensions/am-e2e/am-e2e.js
@@ +1157,5 @@
>      // If the currently used key was deleted, we might not have the
>      // corresponding radio element.
>      if (radio) {
>        radio.closest(".content-blocking-category").classList.add("selected");
>      }

Here we need to check if the key is == "", and select the "None" radio button since the reload of the UI clears that selection and it's not maintained when switching between accounts.
It should be `radio.setAttribute("selected", true);`, as `radio.selected = true;` doesn't seem to work.
Attachment #9202808 - Flags: review?(alessandro) → review+

Thanks. I did a bit of adjusting how the key selection works.

Attachment #9202808 - Attachment is obsolete: true
Attachment #9203296 - Flags: review+
Target Milestone: --- → 87 Branch

Pushed by
Newly Added Additional Identities not Listed in "Alias Identity" Dialog. r=aleca

Closed: 3 years ago
Resolution: --- → FIXED

Comment on attachment 9203296 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #): unknown, partly "always" was this way, but worse from openpgp
User impact if declined: per bug summary
Testing completed (on c-c, etc.): on beta
Risk to taking this patch (and alternatives if risky): medium risk as the code was very messy

Attachment #9203296 - Flags: approval-comm-esr78?

Comment on attachment 9203296 [details] [diff] [review]

[Triage Comment]
Approved for esr78
It's been on beta for about a week and I see no regressions reported

Attachment #9203296 - Flags: approval-comm-esr78? → approval-comm-esr78+
You need to log in before you can comment on or make changes to this bug.