av9ash/GitBugs huggingface dataset:
Bug: MailExtension: Error closing a window using windows.remove with WINDOW_ID_CURRENT
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-11 05:57:02+00:00
Resolved: 2020-06-21 01:07:35+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

1. Install the Snippets add-on (requires Thunderbird 77 beta 3 or newer): https://github.com/aecreations/snippets
2. Open a new message composer window. Locate the "Snippets" button on the composer toolbar and click it to open the Snippets extension page in a popup window
3. Try to close the popup window by clicking the "Close Window" button on the bottom right corner of the extension page


Actual results:

The popup window does not close.

The MailExtension code is attempting to close the window by calling `messenger.windows.remove(messenger.windows.WINDOW_ID_CURRENT);`.  But the following error appears in the error console when that line is executed:

Error: Type error for parameter windowId (Integer -2 is too small (must be at least 0)) for windows.remove. snippets.js:39:23
    makeError resource://gre/modules/Schemas.jsm:507
    throwError resource://gre/modules/Schemas.jsm:2494
    fixedArgs resource://gre/modules/Schemas.jsm:2562
    map self-hosted:240
    checkParameters resource://gre/modules/Schemas.jsm:2555
    stub resource://gre/modules/Schemas.jsm:2661
    init moz-extension://6393dedc-d3c2-bc43-8315-a57999500e7f/pages/snippets.js:39
    checkParameters resource://gre/modules/Schemas.jsm:2555
    stub resource://gre/modules/Schemas.jsm:2661
    init moz-extension://6393dedc-d3c2-bc43-8315-a57999500e7f/pages/snippets.js:39


Expected results:

The popup window should close.
Bug: Crash in [@ shutdownhang | nsThread::Shutdown | nsThreadManager::Shutdown]
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-11 12:52:33+00:00
Resolved: 2020-06-16 13:56:33+00:00

This bug is for crash report bp-9fff1a31-8b53-4e52-8db6-4875a0200313.

Top 10 frames of crashing thread:
```
0 ntdll.dll NtWaitForAlertByThreadId 
1 ntdll.dll RtlSleepConditionVariableSRW 
2 kernelbase.dll SleepConditionVariableSRW 
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
4 xul.dll mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::EventQueue> >::GetEvent xpcom/threads/ThreadEventQueue.cpp:149
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1108
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:881
8 xul.dll nsThreadManager::Shutdown xpcom/threads/nsThreadManager.cpp:284
9 xul.dll mozilla::ShutdownXPCOM xpcom/build/XPCOMInit.cpp:649
```
I had this bug for at least since beginning of 2019, I can see the old crashreports have since been cleared but 2019-01-05 is the first one my current installation of Thunderbird tracks (id bp-5cdc7f10-b99a-47cd-9d70-5741d0190105)

It only occurs when exiting, around 1minute after I shut it down. Otherwise no stability issues.
Bug: Shutdown crash in [@ md_UnlockAndPostNotifies] (nss) via ldap_msgdelete (ldap60.dll)  use-after-free - part 2
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-06-11 18:25:51+00:00
Resolved: 2021-10-31 04:23:48+00:00

+++ This bug was initially created as a clone of Bug #1625677 +++

Bug  1625677 helped in a significant way, with md_UnlockAndPostNotifies crashes down ~30% https://crash-stats.mozilla.org/signature/?product=Thunderbird&signature=md_UnlockAndPostNotifies&date=%3E%3D2020-05-11T18%3A13%3A00.000Z&date=%3C2020-06-11T18%3A13%3A00.000Z#graphs  and Mac crashes down 50% https://crash-stats.mozilla.org/signature/?signature=ldap_msgdelete&date=%3E%3D2020-05-11T18%3A21%3A00.000Z&date=%3C2020-06-11T18%3A21%3A00.000Z#graphs

But there is clearly more wok to be done.  Hadrian's crash md_UnlockAndPostNotifies bp-b0c56082-0939-4607-8d0f-7a04b0200611
 0 	nss3.dll	static void md_UnlockAndPostNotifies(struct _MDLock*, struct PRThread*, struct _MDCVar*)	nsprpub/pr/src/md/windows/w95cv.c:86
1 	nss3.dll	_PR_MD_UNLOCK	nsprpub/pr/src/md/windows/w95cv.c:363
2 	nss3.dll	PR_Unlock	nsprpub/pr/src/threads/combined/prulock.c:328
3 	prldap60.dll	static int prldap_mutex_unlock(void*)	comm/ldap/c-sdk/libraries/libprldap/ldappr-threads.c:209
4 	ldap60.dll	ldap_msgdelete	comm/ldap/c-sdk/libraries/libldap/result.c:1205
5 	ldap60.dll	static int do_abandon(struct ldap*, int, int, struct ldapcontrol**, struct ldapcontrol**)	comm/ldap/c-sdk/libraries/libldap/abandon.c:160
6 	ldap60.dll	ldap_abandon_ext	comm/ldap/c-sdk/libraries/libldap/abandon.c:98
7 	xul.dll	AbandonExtRunnable::Run()	comm/ldap/xpcom/src/nsLDAPOperation.cpp:614
Bug: Links in Account Manager open in browser window but also replace the Tab content
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-06-12 01:40:43+00:00
Resolved: 2020-06-16 02:13:11+00:00

Click one of the many links in the `Resources` section at the bottom of the new Account Manager.
The link opens correctly in the default browser, but also gets loaded in the tab itself, replacing the entire content.

This is a regression as it never happened before, and surely it didn't used to happen when first implementing the Account Manager.

I'm setting P1 and S1 as it's pretty disruptive since it prevents the usage of the entire tab.
Bug: Leading spaces in signature text disappear
Status: NEW
Priority: --
Created: 2020-06-12 06:56:19+00:00
Resolved: 2022-05-16 13:30:12+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Edit a signature to have leading spaces or non-breaking spaces.
Thunderbird -- Tools menu -- Account settings item -- select an email address (in my case, an IMAP email address -- in Default Identity section of right-hand pane -- in Signature Text text box:
Enter leading spaces before the first printable character. e.g. I entered

    --Jim DeLaHunt  [That's four non-breaking spaces, then "--"]

Press the OK button to save the Signature Text and close the Account Settings Dialogue.
Then reopen the same dialogue: Tools menu -- Account settings item -- select an email address (in my case, an IMAP email address -- in Default Identity section of right-hand pane -- in Signature Text text box.

I am using Thunderbird 68.9.0 (64-bit) on macOS X High Sierra 10.13.6.


Actual results:

The leading spaces are gone. The first printing character of the signature is at the start of the text box, e.g. 

--Jim DeLaHunt [That's zero spaces before "--"]

As a consequence, these leading spaces are also absent from email messages which include this signature.

I see the same behaviour whether the leading space is  non-breaking spaces (U+00A0, option-space on Mac) or regular spaces (U+0020 space). I see the same behaviour whether "Use HTML" is checked or unchecked.


Expected results:

The leading space characters should be preserved when the Account Settings dialogue is re-opened. They also should be preserved when inserting the signature into an email message.

(Actually, I would concede that leading regular spaces get stripped, but leading non-breaking spaces should absolutely be preserved. Part of their function is to preserve their presence and spacing behaviour where regular spaces give way.)
Bug: problem saving multiple attachment on Mint
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-12 06:57:32+00:00
Resolved: 2020-06-16 13:58:02+00:00

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

Steps to reproduce:

From some time, When saving multiple attachments from email, when I choose path for the first attachment, the path is forgotten form for second one. The path is saved as default after saving the last attachment



Expected results:

The path of the first attachment should be a default for the next. You expect usually all attachemnts from one email to go in one directory
Bug: profile transfer issue between Thunderbird installation working in different languages
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-12 10:30:42+00:00
Resolved: 2020-06-16 14:00:26+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I have Thunderbird on PC 1 (windows 10 Pro) in language UK
I have another (laptop windows 10 Home in Dutch) with same TB v68.9 (32bit) in DUTCH 
-  Copied complete profile folder to new PC in  a newly create profile folder and selected that profile to be used


Actual results:

It crashed all the time when I was NOT in SAFE mode (even NO add-Ons)
Using the SHIFT key to start it in safe mode, all worked okay (exept no AddOns ofcourse)




Expected results:

Finally I decide to set the Language of TB on Laptop also to UK and then it started OK (with exact the same data in the profile)
Bug: browser.contacts.quickSearch fails when address books are invalid.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-12 11:41:20+00:00
Resolved: 2021-03-01 19:48:24+00:00

We've just started using `browser.contacts.quickSearch` in Conversations. I've just received two reports that this is busting Conversations when users have Exquilla installed. One of those had Exquilla with an out-of-date license.

The exception that gets thrown is:

```
[Exception... "JavaScript component does not have a method named: "Symbol.iterator"'JavaScript component does not have a method named: "Symbol.iterator"' when calling method: [nsISimpleEnumerator::Symbol.iterator]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "JS frame :: chrome://messenger/content/parent/ext-addressBook.js :: quickSearch :: line 556"  data: no] ext-addressBook.js:556:49
    quickSearch chrome://messenger/content/parent/ext-addressBook.js:556
    quickSearch self-hosted:1005
    result resource://gre/modules/ExtensionParent.jsm:1139
    withPendingBrowser resource://gre/modules/ExtensionParent.jsm:770
    result resource://gre/modules/ExtensionParent.jsm:1139
    withTiming resource://gre/modules/ExtensionParent.jsm:1100
    call resource://gre/modules/ExtensionParent.jsm:1138
    InterpretGeneratorResume self-hosted:1284
    AsyncFunctionNext self-hosted:839
{…}
```

That comes from here:

https://searchfox.org/comm-esr68/rev/c0efa7116ed4cbb1f313d6305b5650d6eba4d0d0/mail/components/extensions/parent/ext-addressBook.js#556-557

Whilst I've implemented a try/catch work around in Conversations, that stops the API working completely, so some functionality would be lost.

I think this just affects the 68 branch, the latest code seems different assuming that wouldn't throw on an error:

https://searchfox.org/comm-central/rev/83ae42aa38bc39143b0f6d93bb69a40094c4b515/mail/components/extensions/parent/ext-addressBook.js#554-572
Bug: Filters consistently stop working
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-12 16:07:36+00:00
Resolved: 2020-12-06 20:29:00+00:00

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

Steps to reproduce:

Created a number of filters (60+)
Created many folders
Start Thunderbird and see the messages being filtered properly into the respective folders
Filtering stops before completing filtering all messages in my inbox
Stop Thunderbird
Start Thunderbird
Manually apply filters 
Repeat previous three steps until all messages are filtered


Actual results:

Message filtering works but quits before finishing and then filters no more filtering happens until Thunderbird is restarted


Expected results:

Filters should just keep working. I should not have to restart Thunderbird multiple times to get the messages filtered from the inbox.

I am glad to assist with debugging if given direction on how to do so.
Bug: Right click instantaneously select and execute the first item on the contextual menu
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-06-12 19:25:36+00:00
Resolved: 2021-03-18 06:54:53+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15

Steps to reproduce:

Right click and release right click button on any text field with some text (e.g. compose email body, email subject line, search field). 


Actual results:

As the right click button is released, the contextual menu is displayed very briefly, the first item on the contextual menu is instantaneously selected and executed. (Note: This behaviour started about 2 to 3 release versions ago. If I right click and not release the right click button I can then read the contextual menu properly. Firefox does not have this problem.)


Expected results:

As the right click button is released, the contextual menu is displayed and wait for user selection.
Bug: Crash in [@ nsAbLDAPProcessReplicationData::Done]
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-06-12 20:41:05+00:00
Resolved: 2020-08-13 23:42:06+00:00

I've labeled this as version 78, but it goes back at least as far as 75.  Some other recent crashes
bp-83c745b3-a0e8-42b5-a93e-9d51c0200609 	2020-06-09 02:35:35 	Thunderbird 	79.0a1
bp-1ac46faf-c002-4516-addb-212e20200603 	2020-06-03 19:02:31 	Thunderbird 	77.0 

So far, a low rate crash of 1-2 crashes per week for beta.

Perhaps a duplicate?

This bug is for crash report bp-d9c11996-056a-494a-b7ba-337c50200605.

Top 10 frames of crashing thread:
```
0 xul.dll nsAbLDAPProcessReplicationData::Done comm/mailnews/addrbook/src/nsAbLDAPReplicationData.cpp:367
1 xul.dll nsAbLDAPListenerBase::OnLDAPInit comm/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp:65
2 xul.dll nsLDAPConnection::OnLookupComplete comm/ldap/xpcom/src/nsLDAPConnection.cpp:582
3 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/netwerk/dns/DNSListenerProxy.cpp:28:30'>::Run xpcom/threads/nsThreadUtils.h:574
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1211
5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:501
6 xul.dll mozilla::AppWindow::ShowModal xpfe/appshell/AppWindow.cpp:505
7 xul.dll nsWindowWatcher::OpenWindowInternal toolkit/components/windowwatcher/nsWindowWatcher.cpp:1309
8 xul.dll nsWindowWatcher::OpenWindow2 toolkit/components/windowwatcher/nsWindowWatcher.cpp:375
9 xul.dll nsGlobalWindowOuter::OpenInternal dom/base/nsGlobalWindowOuter.cpp:7075
```
Bug: Caret disappear or shown in wrong location when moved
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-13 01:19:03+00:00
Resolved: 2020-12-06 20:29:16+00:00

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

Steps to reproduce:

Start composing a new mail
Type a few words
Start moving (using the keyboard, e.g. press the left key) the caret as soon as it blinks on or off.


Actual results:

If the move happens when the caret is shown, it continues to be shown where it was before the move. This does not happen if moved using the mouse (immediate update).
If the move took place when it was off, no caret is displayed anywhere.
In both cases, when it's time to redisplay (blink on) the caret, it is displayed at the correct location.


Expected results:

The caret should start a new blink cycle at the correct location as soon as it is moved. This is, BTW, how Firefox is doing it.
Bug: Deleting an attachment from a message / Saving a new draft stops the message being accessed
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-13 13:11:28+00:00
Resolved: 2021-08-13 11:20:30+00:00

STR:

1) Have a message with a single attachment.
2) Access a message via the WebExtensions API (e.g. via query or something, as long as you get the id).
3) Open the email via the normal message reader (I opened one in a new tab).
4) Delete the attachment.
5) Try and get the message details via the API using the id.

Actual Results:

Error: "Message no longer exists"

Expected Results:

Receive details about the new message.
Bug: Links to Twitter from email messages not working
Status: UNCONFIRMED
Priority: --
Created: 2020-06-13 19:26:39+00:00
Resolved: 2020-10-06 07:19:38+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Received normal email messages from my Twitter account,complete with text and graphics and links.


Actual results:

Whenever I clicked on an email notification about a Twitter post, I would get an error message (see attached "Tbird Error Twitter.jpg"), and the linked Twitter feed would not open.


Expected results:

Normally when I click on one of these links, it would take me directly to the linked Tweet in my Twitter feed. Doing a right click/open in browser yields the same results. The only way around it was to copy the link location, then manually paste the link in a browser window.
Bug: C-C TB Performance regression? Please do not use mouseenter/leave events in chrome. They are slower than mouseover/out!: '!nsContentUtils::IsChromeDoc(d)', file  .../mozilla/dom/events/EventListenerManager.cpp, line 337
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-13 20:59:08+00:00
Resolved: 2020-08-20 12:30:54+00:00

I suddenly began seeing the following warnings in my local mochitest log (C-C TB FULL DEBUG version.)
```
32: Main Thread] WARNING: Please do not use mouseenter/leave events in chrome. They are slower than mouseover/out!: '!nsContentUtils::IsChromeDoc(d)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/events/EventListenerManager.cpp, line 337

```
32 at the beginning of the line is the number of occurrences.

I did not see the perf regression warning in a log of mochitest run on May 30.
But I found them in a log file from June 6th.
So this regression is rather new.

I also see the warnings on tryserver jobs.:
For example, benc's job:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=b36d20f09a11e8a3af3076d85ba00c5da913613b
See 
https://firefoxci.taskcluster-artifacts.net/bFrLNNFEQy26gjrJxSFYjg/0/public/logs/live_backing.log

Someone who is familar with Calendar code needs to check them since the perf regression warning messages are all from calendar tests.
(I attach a listing that shows the name of the test files created by the following command:
```
egrep "(TEST_START|TEST_END|Entering test|Leaving test|do not use mouseenter/leave)" /FF-NEW/log1236-older-mochitest.txt
```
Since the perf warning started appear very recently, I think the change that introduced it is relatively easily to catch, I suppose.

Related bugzilla entries that may offer hints about how to fix the CSS/HTML page used for Calendar.:
Bug 1138787 		Lots of "Please do not use mouseenter/leave events in chrome. They are slower than mouseover/out!" warnings during mochitest-dt runs 	
Bug 854075 		WARNING: Please do not use mouseenter/leave events in chrome. They are slower than mouseover/out!: '!nsContentUtils::IsChromeDoc(d)', file content/events/src/nsEventListenerManager.cpp, line 337
Bug: C-C TB mochitest - JavaScript error: resource://testing-common/mozmill/utils.jsm, line 363: uncaught exception: ParserError: Invalid parameters in 'email;internet:foo@bar.com'
Status: NEW
Priority: --
Created: 2020-06-13 21:27:40+00:00
Resolved: 2020-06-16 14:12:23+00:00

I see the following error during the execution of C-C TB mochitst, specifically the test
comm/mail/test/browser/attachment/browser_attachmentSize.js.

I did not see this error before May 23.
Actually, I ran two tests on May 23 and only the second test on the day started to show the error. So I suspect only after the M-C/C-C update on that day brought in the bug. I suspect the problems appeared in the tree in a very narrow range before May 23 inclusive.
 
I see the error on tryserver jobs as well. For example, benc's job
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=b36d20f09a11e8a3af3076d85ba00c5da913613b
See 
https://firefoxci.taskcluster-artifacts.net/ArJIMpbdTUyIehsBijKohQ/0/public/logs/live_backing.log

In both my local log and the tryserver log above, the error line is followed by 
a converter failure and stack dump.: my local log has the following line.
```
76:53.24 GECKO(918110) [918110, Main Thread] ###!!! ASSERTION: converter failure: 'NS_SUCCEEDED(rv)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/mime/src/nsSimpleMimeConverterStub.cpp, line 91
```
It is likely that the error led to the converter failure, but I am not sure.
Bug: Deleting pills with BACKSPACE (aka DELETE, ←) key sometimes fails on MAC, depending on prior focus
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-06-14 01:23:14+00:00
Resolved: 2020-06-19 19:58:16+00:00

+++ This bug was initially created as a clone of Bug #1602431 +++

78 beta. Mac. I don't often delete pills so I don't know when this changed, assuming it ever worked.

"fail" Reply to a message with two addresses. Click on a pill (either one), hit delete, nothing. And nothing in error console.

"works" Reply to a message with two addresses. Click after last pill, hit delete, last pill is selected, hit delete again, pill is deleted

"works" Reply to a message with two addresses. Click after last pill, click any pill, hit delete, pill is deleted

I don't have add-ons installed that would affect compose.
Bug: C-C TB mochitest - JavaScript error: chrome://messenger/content/virtualFolderProperties.js, line 287: TypeError: window.arguments[0].previewSelectedColorCallback is not a function
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-14 01:58:29+00:00
Resolved: 2020-06-26 20:27:19+00:00

I see the following error in my local mochitest log of C-C TB Full
DEBUG version.

```
JavaScript error: chrome://messenger/content/virtualFolderProperties.js, line 287: TypeError: window.arguments[0].previewSelectedColorCallback is not a function
```
I see the error also in tryserver.
For example, benc's job.:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=b36d20f09a11e8a3af3076d85ba00c5da913613b
https://firefoxci.taskcluster-artifacts.net/JA4NgwR_RSStM_hnZLcCrA/0/public/logs/live.log

The error in question happens on the following line:
```
function onCancel(event) {
  if (window.arguments[0].folder) {
    // Restore the icon to the previous color and discard edits.
    window.arguments[0].previewSelectedColorCallback(    <==== here
      window.arguments[0].folder,
      kCurrentColor
    );
  }
}
```
Maybe due to some debug macro and other setting, I don't see the stacktrace in
the tryserver log, so I am attaching the local log.
There are some debug dumps added locally, so it is a bit verbose than
the one on the tryserver.
Bug: Send button disappeared from the composition window.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-14 14:54:26+00:00
Resolved: 2021-07-14 10:40:18+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Checked all settings to no avail.  Under Help new start of T-Bird restores Send button. 


Actual results:

Send button restored, but only temporarily.  Later use of Thunderbird and Send button no longer on write page.  


Expected results:

Permanent restoration of Send button to transmit completed email text.
Bug: width of dialog to edit identity doesn't remember resize after close+reopen, also uses 'min-width: 75ch;' from English version
Status: NEW
Priority: --
Created: 2020-06-14 18:27:55+00:00
Resolved: 2020-08-15 21:07:29+00:00

Thunderbird 78.0b1 20200611220825 in German (de) on Windows 8.1

The width of the dialog to edit identity doesn't remember a resize after close+reopen, also it uses `min-width: calc(75ch + 41.6px);` - the 75ch seem to be from the English version while the German version uses 87ch. Due to the addition of the E2E encryption tab there, it might need further widening.