Closed stanio closed 3 years ago
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).
Sorry I missed this, it seems like quite a nasty bug. Let me take a look this weekend and get back to you!
@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.
@stanio
https://github.com/JohnDDuncanIII/messagefaces/releases https://github.com/JohnDDuncanIII/messagefaces/releases/download/1.3.1/messagefaces-1.3.1.xpi
http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/ http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/download/messagefaces1_3_1.xpi http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/history.html
The issue is not apparent if the message has already been preloaded locally – that is using the default Syncronization & Storage account setting (checked):
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.