268866 - nsIScriptableInputStream hangs on IMAP messages with attachments, after first use

Status: RESOLVED EXPIRED

(Thunderbird :: General, defect)

Description

[tauberer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

I have the Thunderbird Sender Policy Framework Extension installed (because I
wrote the extension).  http://taubz.for.net/code/spf

Except for the first time I open an email in an IMAP folder, if the email has
attachments the extension hangs.  It hangs when trying to read the contents of
the email using nsIScriptableInputStream.  A call to either available() or
read() will do it.

The extension installs in Thunderbird 0.8 and 0.9, and it has this problem in
both versions.  I only have Linux to try it in.

Reproducible: Always
Steps to Reproduce:
1.  Install the extension.
2.  Open any email in an IMAP folder.
3.  Open another email in an IMAP folder with attachments.

Actual Results:  
Thunderbird freezes.  It's not using any CPU.

Expected Results:  
Not freeze. :)

Thanks for your hard work.  Thunderbird is a great application.

Comment 1

[David :Bienvenu]

can you be a little more specific about how you're attempting to read the
contents of an imap message using nsIScriptableInputStream, e.g., some sample code?

Comment 2

[InvisiBill]

WinXP SP2, version 1.0 (20041206)

I can duplicate this bug. I saved http://taubz.for.net/code/spf as spf.html and
sent it to a test IMAP account. Thunderbird/SPF worked fine, letting me open the
attached file in Firefox. I zipped up a SpamAssassin executable (the first
binary I had sitting around) and attached it to an email to the IMAP account.

Thunderbird freezes as reported. It does not use any CPU. The message pane is
blank (subject, email addresses, date, and UA show in header bar), and the email
is still marked as unread in the IMAP folder.

After killing and reopening Thunderbird, the message was marked read. Selecting
the email, the message text and the attachment name appeared in the preview
pane, but Thunderbird froze again.

Comment 3

[tauberer]

The relevant part of the code that leads to the freeze is:

var uri = GetFirstSelectedMessage();
var msgService = messenger.messageServiceFromURI(uri);
var consumer =
Components.classes["@mozilla.org/network/sync-stream-listener;1"].createInstance();
var consumer_inputstream =
consumer.QueryInterface(Components.interfaces.nsIInputStream);
var input =
Components.classes["@mozilla.org/scriptableinputstream;1"].createInstance();
var scriptableinput =
input.QueryInterface(Components.interfaces.nsIScriptableInputStream);

scriptableinput.init(consumer);
msgService.streamMessage(uri, consumer, msgWindow, null, false, null)

// This line freezes Thunderbird in IMAP accounts when loading emails with
attachments (except the first time).  Calls to read() would also freeze Thunderbird.
scriptableinput.available();

Comment 4

[David :Bienvenu]

Did you try creating an  async stream listener instead of a sync stream
listener?  Looking at the sync stream listener, I'm not surprised that it locks
the UI since it takes over the event queue...and the imap code runs on its own
thread and uses xpcom proxying to talk to the ui thread.

Comment 5

[tauberer]

I wasn't sure exactly what to do with the async stream listener.  I just tried
putting the async listener between streamMessage and the sync stream listener,
but that didn't help any.  (Without the sync stream listener I don't know how to
get access to the stream data...)

However, I found a workaround.  The code I posted was called through:

messagepane.addEventListener("load", spfGoEvent, true);

I noticed that the code runs without this bug when it's in response to a menu
item being clicked, so I added a window.setTimeout on the load event to delay
the message processing routine.  For the moment it seems that this fixed the
problem.

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.