av9ash/GitBugs huggingface dataset:
Bug: [Meta] Attachment icon in message list not shown until message is selected/displayed (but message has attachments) or falsely shown (but message does not have attachments)
Status: NEW
Priority: --
Created: 2021-02-06 12:00:43+00:00
Resolved: 2023-02-28 21:44:15+00:00

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

This is a meta bug to link all bug reports related to "attachment icon in message falsely shown/not shown in message list" in spite of the actual "has-attachment" status of the message. Underlying message Mime structures might differ, so it's not easy to dupe these bugs correctly. But we should have a central access point.

E.g., if you receive a message with an attachment, "attach icon" is showed only after click on this message. Or, message shows attachment icon, but the message does *not* have attachments.

Steps to Reproduce:

1. Receive a message with an attachment
2. Don't select/display it. Message does not have an attachment icon in the list.
3. Select it. Now you can see the "attachment icon".

OR

1. Receive a message without an attachment.
2. Don't select/display it. Message has attachment icon.
3. Select message - attachment icon disappears because message does not have attachments.
Bug: Mac OS Big Sur hangs when using Hebrew edtion plus ARM. English plus ARM works fine.  Hebrew plus Intel is fine.
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-06 18:28:42+00:00
Resolved: 2021-11-10 13:35:22+00:00

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

Steps to reproduce:

Mac OS Big Sur 11.2 M1 processor
Try to open Thunderbird preference ==> got stack



Actual results:

Thunderbird got stack.

Please note : 
At my home same version , same Mac Os system (11.2) BUT 
INTEL Processor ==> NO ISSUE
Work Perfect.


Expected results:

Open Thunderbird preference window
Bug: folder pane not displayed on osx
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-02-06 18:30:55+00:00
Resolved: 2021-02-06 19:38:31+00:00

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

Steps to reproduce:

Run TB 60.9.1 on OSX Big Sur


Actual results:

Folder pane is not displayed. See screenshot.


Expected results:

Folder pane should be displayed
Bug: Quickfilter: no search results when search is extended with 'Body' scope (regular results disappear)
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-07 05:52:26+00:00
Resolved: 2023-08-29 02:18:24+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.152 Safari/537.36

Steps to reproduce:

Quick Search a folder.


Actual results:

When the "Body" filter is enabled, search results that were returned for "Subject" are lost.
See the attached pic. When "Body" is enabled, the results which were returned in the Subject are not returned.


Expected results:

Additional results should appear if the search term was in found the body of any of the email in the folder.
Bug: compose.beginNew() API turns insignificant newlines in HTML body into <br>
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-07 11:28:01+00:00
Resolved: 2021-06-17 07:34:01+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.63

Steps to reproduce:

When the HTML passed to `compose.beginNew()` contains insignificant newlines in HTML body, these are turned into into <br> in the compose window.


Actual results:

To many empty lines displayed in the compose window.


Expected results:

Insignificant newlines should have been ignored.

Workaround: Call `compose.beginNew()` only with an object containing `isPlainText`, then use `compose.setComposeDetails()`.
Bug: Once a recipient has been entered, unable to edit that recipient or to copy-paste from it
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-07 11:54:04+00:00
Resolved: 2021-02-07 19:46:28+00:00

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

Steps to reproduce:

1. Click "Write" to compose a new message
2. Enter a recipient (alain@me.li)
3. Click into message area to enter a message
4. Click into To: field again to fix a typo (should be alain@me.lu)


Actual results:

Recipient is framed with a weird box that prevents me from doing any edit on it.

I can't select parts of the address using standard UI (i.e. swiping it with mouse) either.

I can only select the entire address (using right-click->copy), or delete the entire address


Expected results:

- I should still be able to click inside the recipient address to fix a typo
- I should still be able to swipe over parts of the address to select parts of it (such as only the domain)


N.B. A much older bug exists with almost the same symptoms: #218269

But that one had long been fixed, and it only recently re-appeared (with the last few weeks, can't tell exactly when).


The elaborate boxes drawn around the recipient addresses hint to me that this is intentional. Please revert that back. There are people who use thunderbird for work, and don't need such clowneries :-(
Bug: Choosing the same color for text and background leads to unusable options/config editor dialogs/tabs - color selection can't be reverted
Status: NEW
Priority: --
Created: 2021-02-07 12:04:27+00:00
Resolved: 2021-02-07 13:48:24+00:00

Steps to reproduce:
In Options > General > Colors choose black color for both Text and Background.
Activate the additional option "Always".
Close options dialog and reopen it.

This combination leads to unusable options and config editor dialogs because of no contrast and invisible UI elements. There is nearly no chance to revert this fateful color/options combination.

Users have to create a new profile or to edit the prefs.js file, if possible. Therefore I would classify this problem as a serious bug.

Safe mode doesn't help.
Bug: automatically mark messages as read after N seconds unreliable
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-02-07 12:30:01+00:00
Resolved: 2021-11-07 16:29:52+00:00

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

Steps to reproduce:

I have the setting 
automatically mark messages as read after 8 seconds 

But when scrolling through a folder (eg inbox, junk) then messages start marking as read if highlighted for <<8secs


Actual results:

But when scrolling through a folder (eg inbox, junk) then messages start marking as read if highlighted for <<8secs


Expected results:

Which obv they shouldn't

It's been like this for some weeks now
Bug: Crash in [@ nsMsgCompose::SendMsg::<T>::operator()]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-07 15:25:01+00:00
Resolved: 2021-06-25 16:02:36+00:00

Random corruption?  
Signature first appears with 85 beta

Crash report: https://crash-stats.mozilla.org/report/index/defd90f3-9de6-4e03-8ae8-849930201220

Reason: ```EXCEPTION_ACCESS_VIOLATION_READ```

Top 10 frames of crashing thread:
```
0 xul.dll nsMsgCompose::SendMsg::<unnamed-tag>::operator const comm/mailnews/compose/src/nsMsgCompose.cpp:1355
1 xul.dll xul.dll@0xdf6bf 
2 xul.dll mozilla::dom::DomPromiseListener::RejectedCallback dom/promise/PromiseNativeHandler.cpp:52
3 xul.dll mozilla::dom::`anonymous namespace'::PromiseNativeHandlerShim::RejectedCallback dom/promise/Promise.cpp:391
4 xul.dll mozilla::dom::NativeHandlerCallback dom/promise/Promise.cpp:337
5 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:594
6 xul.dll js::Call js/src/vm/Interpreter.cpp:664
7 xul.dll PromiseReactionJob js/src/builtin/Promise.cpp:1904
8 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:594
9 xul.dll js::Call js/src/vm/Interpreter.cpp:664
```

bp-34491f8b-6ed6-4c5f-a5fc-729da0210207
bp-b84cd473-9ac4-496e-bcc4-82c110210207
Bug: High memory usage caused by high number of attachments
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-07 16:18:03+00:00
Resolved: 2021-07-20 15:44:47+00:00

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

Steps to reproduce:

Click (single click) on a mail with 113 attachments (16kB each, forwarded Outlook messages) in the mail frontend window. The size of the mail is approximately 8MB.

System: 
Opensuse Leap 15.2
Thunderbird: 78.7.1
Mem: 6GB +  4GB swap


Actual results:

The memory usage increased dramaticaly from 300MB to 4,5GB --> Thunderbird froze for several minutes, until the memory was allocated (swap space)


Expected results:

Memory usage should not increase that much, Thunderbird should not freeze.
Bug: my email is sent with spam subject
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-02-07 18:30:02+00:00
Resolved: 2021-03-22 11:13:57+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36

Steps to reproduce:

The recipient receives my email with the subject spam.
Bug: tag and 'mailing lists' list in global search has scrollbar because 'None' label is missing
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-07 19:49:34+00:00
Resolved: 2021-02-10 09:23:33+00:00

The tag list in the global search sidebar has a scrollbar because the 'None' label is missing. 

Steps to reproduce:
1. Tag several message: Select message, press a number 1-5 (forces the tag selector in the global search to be shown).
2. Click "Get Messages" button at top left (rebuilds search database with the tags).
3. In the global search bar, search e.g. for the host of your email.

Actual result:
Tag list in sidebar of search results has scrollbar because 'None' tag for messages without tags is missing.

Expected result:
'None' tag shown + no scroll bar.

This is from bug 1637136. ariasuni, do you want to investigate?
Bug: label for included tags and mailing lists in global search is 'None', should be about mandatory labels
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-02-07 20:46:41+00:00
Resolved: 2021-02-10 09:23:33+00:00

Latest central (87.0a1 20210207) and beta (86.0b2).

The label for included tags in global search is 'None', should be about mandatory labels.

Steps to reproduce:
1. Tag several message: Select message, press a number 1-5 (forces the tag selector in the global search to be shown).
2. Click "Get Messages" button at top left (rebuilds search database with the tags).
3. In the global search bar, search e.g. for the host of your email.
4. In the left sidebar, click on a tag and choose "must be tagged <tag name>".

Actual result:
Tag get moved to new group "None".

Expected result:
[gloda.message.attr.tag.includeLabel=tagged any of:](https://searchfox.org/comm-central/rev/ae31858548231b2df85bd69253827bf7db9f5126/mail/locales/en-US/chrome/messenger/gloda.properties#132) used.

This is from bug 1637136. ariasuni, do you want to investigate?
Bug: Previously selected text remains highlighted when text is selected in another window
Status: VERIFIED
Priority: --
Resolution: WONTFIX
Created: 2021-02-07 21:24:09+00:00
Resolved: 2021-06-09 12:22:35+00:00

Selection is still shown, even after lost (i.e. something else selected in another application, or even in another window of thunderbird itself. Or even in a different entry field (such as "Subject") in same thunderbird window!).

How to reproduce:
1. Click "Write" to compose a new message
2. Enter random text into message field.
3. Select some text (by dragging mouse over it, or by doubleclicking on a word) => text is highlighted
4. Attempt to paste text elsewhere => selected text appears
5. Select some text in another application => that text is highlighted. But text in thunderbird is *still* highlighted!
6. Attempt to paste text elsewhere => newly selected text appears

What did happen:
3. Text selected in thunderbird is pasted => good
5. Text in thunderbird stays highlighted even when no longer selected => not good
6. Text selected elsewhere is pasted => good

What should have happened:
5. Text should no longer be highlighted when it is no longer the active selection.


This is a bug which slowly, over the years, has invaded almost all applications on the Linux desktop :-(  Only barebones X applications such as xterm seem to stay immune to this.

The bug is annoying whenever distractions happen during work. When getting back to my desktop after a distraction, I might see "hey, the text I wanted to copy is (already / still) selected", so I copy it, to only see something unrelated appear... Also, some applications (even in the Mozilla suite: Firefox, Thunderbird, ...) on occasion do spurious selections, and by continuing to show old selections, the problem is masked until I attempt to paste my selection.
Bug: Mail Toolbar too high as of 78.3.1 when using "Icons and Text"
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-07 21:48:37+00:00
Resolved: 2021-05-11 02:26:05+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Activate Mail Toolbar under VIEW TOOLBARS, and select "Icons & Text" so the labels display under the respective icons.
Compare main screen of current TB (78.3 and later) with 78.2.2 and earlier.


Actual results:

Following upgrade to 78.3.1 (standard user release, via HELP/ABOUT), the Mail Toolbar was little bit taller.  Not such a big deal on my PC screen, but QUITE SIGNIFICANT on the laptop or other small screens!


Expected results:

Toolbar height should not have been changed on a whim -- I am not aware of any issues with previous height.  (And it's not always desirable for users to implement the obvious work-around which is to use "Icons Only"...)
Bug: early loaded .ftl localization files used in English for German Thunderbird, e.g. menu 'OpenPGP Key Manager'
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-07 22:04:58+00:00
Resolved: 2021-11-16 17:01:00+00:00

Windows 8.1, Thunderbird 78, 86.0b2, 87.0a1 20210207

Strings from early loaded .ftl localization files are used in English for German Thunderbird.

Steps to reproduce:
1. Install Thunderbird in German (= locale code "de").
2. Open the menu 'Tools'.

Actual result:
menu item "OpenPGP Key Manager"

Expected results:
menu item "OpenPGP-Schlüssel verwalten": https://hg.mozilla.org/l10n-central/de/file/b796c49c98113d9046cbb7a5ae14c6d5cde37fdf/mail/messenger/openpgp/openpgp-frontend.ftl#l6

The same issue applies to the notification footer for new profiles and the texts loaded from menubar.ftl (Text encoding, texts and tooltips for junk and delete buttons).

[Every .ftl file](https://searchfox.org/comm-central/rev/ae31858548231b2df85bd69253827bf7db9f5126/mail/base/content/messenger.xhtml#75-83) at the start of the `<head>` of the main window seems affected.

This reproduces with local repacks. Repacks for French work as expected with the texts translated. The repack log for German doesn't mention errors and the `omni.ja` contains the translated files

The error console mentions these messages on startup but they are also shown for the successful French Thunderbird:

[l10nregistry] Attempting to synchronously load file
            resource:///chrome/en-US/locale/en-US/calendar/messenger/otr/otrUI.ftl while it's being loaded asynchronously. L10nRegistry.jsm:597:19

[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]"  nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)"  location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 692"  data: no] L10nRegistry.jsm:692:19
Bug: Filter Log and Adaptive Junk Mail Log dialog size incorrectly persisted, log itself appears only after manual resizing.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-07 22:09:13+00:00
Resolved: 2024-09-18 08:55:22+00:00

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

View a few of the Filter Log files (under Message Filters), and view the Junk spam log (under Options).  Resize the window to accommodate long lines and minimize lines per entry (ie - so you can see more at once AND visually align similar messages).

(I think this is a regression.  I first noticed & documented it in October 2020 -- surprised, actually -- because I'm pretty sure the size used to persist.)


Actual results:

Each and every time I set the window size to something appropriate for me (very wide), the size reverts to the default small size when I choose the next log.


Expected results:

The resized window should maintain its settings for as long as I'm in the MESSAGE FILTERS area or in OPTIONS.  My preference is for the window settings to persist long-term *between* sessions, but I can live with persisting *within* a given session.
Bug: address lists and address folders, except the very oldest addresses, disappeared from my address book.
Status: UNCONFIRMED
Priority: --
Created: 2021-02-07 23:34:40+00:00
Resolved: 2025-02-23 18:28:03+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36

Steps to reproduce:

I didn't do anything.  I went to use the address book and the vast majority of my individual addresses, address lists, the address folders and address information had disappeared.  Only the really old lists and folders (10+ years old) which I still use occasionally, remain, all the new things seem to be gone.  I need all of those back.


Actual results:

person, folders, lists disappeared


Expected results:

All of the names, contacts, lists, folders and information should have been in place.
Bug: Thunderbird 86 beta 1 fails to load
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-08 13:35:09+00:00
Resolved: 2021-02-12 17:02:34+00:00

I'm getting an error when loading Thunderbird 86b1 (or b2 for that matter), the error in the JavaScript console is:

```
Uncaught TypeError: this._tree is null / folderPane.js:2917:5
    toggleCompactMode chrome://messenger/content/folderPane.js:2917
    _updateMenuItems chrome://messenger/content/folderPane.js:464
    get activeModes chrome://messenger/content/folderPane.js:390
    _rebuild chrome://messenger/content/folderPane.js:1863
    load chrome://messenger/content/folderPane.js:204
    InitPanes chrome://messenger/content/msgMail3PaneWindow.js:1346
    LoadPostAccountWizard chrome://messenger/content/msgMail3PaneWindow.js:848
    _delayedStartup chrome://messenger/content/msgMail3PaneWindow.js:760
    toggleCompactMode chrome://messenger/content/folderPane.js:2917
    _updateMenuItems chrome://messenger/content/folderPane.js:464
    get activeModes chrome://messenger/content/folderPane.js:390
    _rebuild chrome://messenger/content/folderPane.js:1863
    load chrome://messenger/content/folderPane.js:204
    InitPanes chrome://messenger/content/msgMail3PaneWindow.js:1346
    LoadPostAccountWizard chrome://messenger/content/msgMail3PaneWindow.js:848
    _delayedStartup chrome://messenger/content/msgMail3PaneWindow.js:760
    _delayedStartup self-hosted:1177
```

Note that starting in safe mode fixes this issue for me so I'm guessing it is some sort of customization that I have causing the issue? I have no add-ons installed.
Bug: Crash in [@ shutdownhang | nsThread::Shutdown | mozilla::DataStorage::Observe]
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-02-08 15:23:52+00:00
Resolved: 2021-10-01 17:01:05+00:00

Crash report: https://crash-stats.mozilla.org/report/index/a9e8c82d-c950-47a0-8098-475cb0201117

MOZ_CRASH Reason: ```MOZ_CRASH(Shutdown hanging before starting.)```

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>::GetEvent xpcom/threads/ThreadEventQueue.cpp:207
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1129
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:501
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:891
8 xul.dll mozilla::DataStorage::Observe security/manager/ssl/DataStorage.cpp:1197
9 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:65
```
Bug: 78.7.1 broken since update
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-08 16:03:52+00:00
Resolved: 2022-10-26 02:09:55+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36

Steps to reproduce:

after update to 78.7.1 (64-Bit) Windows 10 (64Bit) it is not possible to send an email.
adressbook does not show any books. it is not possible to add a new adressbook.
can't even reply to an email.
Bug: Header info of Bcc shows full email address of recipient instead of showing showing as undisclosed-recipient;
Status: VERIFIED
Priority: --
Resolution: INVALID
Created: 2021-02-08 16:32:13+00:00
Resolved: 2021-05-05 14:40:13+00:00

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

Steps to reproduce:

Nothing really, checked my Inbox for a new message and clicked on it.


Actual results:

I received a work email from a person at my org. The email arrived showing in the header of the To: field as "undisclosed-recipients;" and the Bcc: field shows my full work email address instead of "undisclosed recipient;" as, I think, it should. Or at least that's how I've always remembered it.

As a test, I drafted an email message from one of three GMail IMAP accounts I have on TB. Let's call them Account 1, Account 2 and Account 3. I drafted an email using Account 2 and sent and email to Account 1 using the To: field and Bcc'ed Account 2 and Account 3.

Results:

1. The email that arrived to Account 1 shows From: as coming from Account 2. It does not display any Bcc field or info. That seems odd.

2. The email that arrived to Account 2 shows From: as coming From: Account 2. It does display in the Bcc field the full email address for Account 2 and Account 3 and not Undisclosed-recipients;.

3. The email that arrived to Account 3 shows From: as coming From: Account 2. It does not display any Bcc field or info. That seems odd.


Expected results:

I think any Bcc field/header info isn't supposed to display the full email address of Bcc recipients. That's why it's called blind carbon copy, no?
Bug: Disfunctional auto resizing of the addressing header area
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-02-08 17:50:08+00:00
Resolved: 2021-02-11 07:05:45+00:00

The addressing header area resizes its height a little bit too aggressively, disregarding entirely the user's manual resizing.

Example:
- Create a lot of pills in order to trigger the scrollable header area (you can drag a bunch from the contacts sidebar to make it quick).
- Resize the header area to see all addresses.
- Add another address (by typing or dragging from the contacts sidebar).

Notice how the header area suddenly collapses at every interaction, ignoring the user's resizing.
To make things worse, this also happens when reordering pills by drag & drop.
Bug: Many (imported) sent mails showing blank body and empty from/to addresses
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-02-08 17:51:04+00:00
Resolved: 2021-12-01 10:33:32+00:00

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

Steps to reproduce:

Open a random mail from my POP sent mails folder


Actual results:

Mail opens as blank: No text, no real from and to addresses (only from and to names!).
When I select "Edit as new message", I see the blank mail again, but with an attachment named "GpgOL_MIME_structure.txt". This contains the body and headers...

I do have a MailStore import. When I look at the mails there, they have the same problem. This seems to hint at a serious database problem instead of a frontend only problem.


Expected results:

Mail should appear with all content.