1623685 - getFull raises an error for IMAP folders

Status: RESOLVED DUPLICATE of bug 1550960

(Thunderbird :: Add-Ons: Extensions API, defect)

Description

[o.marce]

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

Steps to reproduce:

using getFull() from messages API on messages from IMAP folders

Actual results:

some of the messages raise an error :
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgMessageService.streamMessage]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource:///modules/gloda/mimemsg.js :: MsgHdrToMimeMessage :: line 238" data: no]
See : https://thunderbird.topicbox.com/groups/addons/T20ee81663653661e/new-message-event

Expected results:

No error expected.
In https://stackoverflow.com/questions/60277142/thunderbird-webextensions-messages-getfull-raises-exception-0x80004005-ns-er/60737934#60737934 it is said that this happens when another connexion is active on the IMAP account. Did not find such limitation in API description
This is not always the case, using Gmail account while Web interface open does not raise an exception. I got the problem mainly on a office365 account

Comment 1

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 2

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 3

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 4

[Firefox Bug Husbandry Bot]

The severity of these bugs was changed, mistakenly, from normal to S3.

Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.

Comment 5

[Jonathan P-H]

This is causing major problems for the Send Later extension as well. I'm just bumping this issue because radio silence here suggests that nobody is working on this bug at the moment. I don't have anything to add beyond what's already been stated in terms of debugging or solutions.

Comment 6

[Wayne Mery (:wsmwk)]

John and I were just chatting today about Send Later

Comment 7

[John Bieling]

Attachment: messageDisplay.xpi

A simple extension to trigger browser.messages.getFull()

Comment 8

[John Bieling]

We will not be able to fix this for TB68 as that is EOL. Do you still see this in TB78? I attached a small extension, which dumps getFull for each selected message to the console and I do not see that error in 78.4. I was not able to reproduce the error.

Comment 9

[Jonathan P-H]

I have personally not experienced this bug, but I have a number of users who have reported it: https://github.com/Extended-Thunder/send-later/issues/16

I'll ping one of those users to see if he's interested in helping debug.

Comment 10

[Tuitio]

This bug looks very similar (same streamMessage error), but is triggered when attempting getFull on a message with an attachment (or perhaps a very long message, not yet confirmed that):

https://bugzilla.mozilla.org/show_bug.cgi?id=1647656

In my tests it only happens when a message arrives with an attachment, but it seems related to whether Thunderbird has the whole message available locally or not at the time getFull() is called. In the legacy extension world MsgHeaderToMimeMessage wouldn't fire the callback until the message was available which would sometimes mean waiting while the message was downloaded from the server by the MsgHeaderToMimeMessage call.

Comment 11

[John Bieling]

Tuitio, to save me some time, could provide the steps I need to take to have a only partially downloaded imap message in my inbox, so I can check this specific case? In TB78 or above?

Comment 12

[max]

Do you consider 78.7 as a fresh enough version?

In my opinion, this issue is exactly the same as the similar aspect of the problem with new (NNTP) messages described in the Bug #1644027 comment 4.

• In an IMAP account settings disable synchronizing to local disk copy. I have limited number of connections to 1 as well, but I do not think it is relevant.
• Copy some message to an IMAP folder.
• Choose that folder.
• Do not do any actions that could cause fetching of the message, e.g. do not display it by left click.
• Invoke getFull though context menu for the item in the message list.

To be precise, I used extension from Bug #1644027 comment 2, not the one posted here.

Unlike NNTP issue, a workaround could be created for IMAP messages using experiment API. The drawback is that it predates idea of WebExtensions that should protect user from add-on authors.

Maybe additional options argument should be added to allow extension to control if fetch from remote server is allowed. On the other hand questions like support of abort controller arise.

Actually I had a problem trying to reproduce the problem for IMAP account. I got UI freeze with 100% CPU consumption when I changed login for a test IMAP account. I know, I should file a dedicated bug, maybe I will do it later since there are more bugs to file in my TODO list. In the development/test thunderbird profile I did not plan to use IMAP at all, but I needed to force creation of local messages. That is why I created an account with invalid user. That time I was a bit upset that there is no (at least apparent) option to bypass verification of IMAP server...

Comment 13

[max]

This bug could be considered fixed due to changes made for the Bug #1550960.

While invoking MsgHdrToMimeMessage, aLocalOnly argument now is set to false, so it is possible to obtain message even if synchronization is disabled or just have not run for the particular message.

I could reproduce the issue with thunderbird-87.0a1.en-US.linux-x86_64.tar.bz2 2021-02-22 10:06:12.137563808 +0000 but not with thunderbird-88.0a1.en-US.linux-x86_64.tar.bz2 2021-03-12 11:47:30.000000000 +0000