Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck loading IMAP message #4

Closed
stanio opened this issue Apr 24, 2018 · 4 comments
Closed

Stuck loading IMAP message #4

stanio opened this issue Apr 24, 2018 · 4 comments

Comments

@stanio
Copy link

stanio commented Apr 24, 2018

The issue is not apparent if the message has already been preloaded locally – that is using the default Syncronization & Storage account setting (checked):

☑ Keep messages for this account on this computer

Unchecking this causes any new (not preloaded locally) message to get stuck loading ("Downloading message...") while selecting it to view, given the MessageFaces extension has been installed and enabled. Preloading the message by other means like using the "Download Now" button from the Folder Properties / Synchronization tab also enables it to be viewed along side with the MessageFaces shown. Keeping all messages loaded locally may not be feasible for some IMAP usages (like with the "All Mail" folder of Gmail).

This is all using SeaMonkey 2.49.3 but happens with previous versions, also. Can't really say about Thunderbird as the extension doesn't appear to function properly with the current version 52.7.0 for me – no face images, and enlarged message header with blank area. Loading IMAP messages doesn't get stuck using this version of Thunderbird, though.

Note, after a message gets stuck loading the SeaMonkey process doesn't exit normally and should be forced to stop.

@stanio
Copy link
Author

stanio commented Apr 25, 2018

Looking into it a bit further – the problem happens just with the latest MessageFaces 1.3, and doesn't happen with version 1.2.6 (changes).

@JohnDDuncanIII
Copy link
Owner

Sorry I missed this, it seems like quite a nasty bug. Let me take a look this weekend and get back to you!

@JohnDDuncanIII
Copy link
Owner

JohnDDuncanIII commented Dec 14, 2020

@stanio I believe that I've figured this out.

var inputStream = new (
	Components.Constructor(
		"@mozilla.org/scriptableinputstream;1",
		Components.interfaces.nsIScriptableInputStream
	)
);
inputStream.init(messageStream);

var content = "";
inputStream.available();
while (inputStream.available()) {

in chrome/content/headerOverlay.js fires before the imap message can complete its download, which means that the XPCOM call leads to lock contention/deadlock on the network thread responsible for completing the imap message download.

I took the advice outlined here and added

document.getElementById("messagepanebox").addEventListener(
	"load",
	function messagePaneLoader(e) {
		mfO_UpdateMessageHeaders();
		mfDisplayFace();
	},
	true
);

which fixes the problem.


It also looks like mailcheck.js broke due to http://mozilla.6506.n7.nabble.com/Upcoming-change-to-fixIterator-function-in-iteratorUtils-jsm-td367711.html (dead link — see https://groups.google.com/g/tb-planning/c/lbQIuLNv_2s), so I've fixed that as well.

I will draft a release and let you know when it's ready for download.

As an aside, I have recently moved back to the Firefox/SeaMonkey/Mozilla platform and plan on cleaning this project up a bit as I wrote this when I was initially learning javascript/html/css/xul back in college. Now that I have almost three years of professional experience, I have made a list of infrastructural and stylistic improvements that I would like to add to this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants