Introduce MsgProtocolInfo.sys.mjs to reuse code between nntp/pop3/imap protocol info modules.
Differential Revision: https://phabricator.services.mozilla.com/D158739
--HG--
extra : moz-landing-system : lando
When possible, we redirect to the AB tab and let that code handle the dialogs.
Otherwise we open a subdialog from where we are.
Differential Revision: https://phabricator.services.mozilla.com/D158357
--HG--
extra : moz-landing-system : lando
The problem was that NntpClient was handling escaping the "." message
termination, but that nsNewsFolder::NotifyDownloadedLine() was scanning for
"." lines to finish messages. So the folder would screw up when a message
body contained a lone "." line.
The changes in detail:
- Adds notifyDownloadBegin()/notifyDownloadEnd() calls to nsIMsgNewsFolder.
- In NntpClient.jsm:
- Now calls notifyDownloadBegin()/notifyDownloadEnd() to denote message
boundaries.
- No longer sends a "." final line to the folder.
- Tries to call notifyDownloadEnd() with an error code if an error occurs.
- adds an status param to nsMsgDBFolder::EndNewOfflineMessage(), and a code
path to clean up upon errors. News folder now uses this to handle rolling
back if an error occurs, but IMAP still relies on magic (checking the size
of the message written so far).
- nsNewsFolder::NotifyDownloadedLine() no longer looks for a lone "." to
denote the end of a message. The relevant code was split out into
NotifyDownloadBegin() and NotifyDownloadEnd().
- Added some comments to try and clarify the offline message writing vars in
nsMsgDBFolder.
Differential Revision: https://phabricator.services.mozilla.com/D158486
--HG--
extra : absorb_source : 14534b426ccbe4239cb916c35c057ed46f3f6a4e
Also renames nsDelAttachListener to AttachmentDeleter. The old name is
technically accurate, but it derives from nsIUrlListener purely as an
implementation detail, rather than something a caller should need to be aware
of.
Differential Revision: https://phabricator.services.mozilla.com/D157064
This patch addresses a couple of issues in nsImapMailFolder::CopyMessagesOffline(),
which handles copying messages to IMAP folders when in Offline mode:
1) It uses nsIMsgFolder.HasMessageOffline() to see if a full local copy of a
message is available in the source folder. But the local folder implementation
of HasMessagesOffline() would always return false. So copy operations from
a local folder would never copy the full message across to the msgStore of
the destination IMAP folder. This patch adds a local folder implementation
of HasMessageOffline().
(The roots of this issue is down to pointless differences between the way
local folders and IMAP folder handle message storage on disk).
2) The CopyOfflineMsgBody() routine used to actually copy the message between
the local folder msgStore and the IMAP folder msgStore would corrupt the
message data. I've replaced it with a much simpler dumb copy.
The upshot is that after the offline copy, a full message will appear in the
destination IMAP folder. It's a required first step, but it doesn't fix the
rest of the bug - the moved message disappearing during the IMAP sync after going
back into online mode.
Differential Revision: https://phabricator.services.mozilla.com/D156269
--HG--
extra : amend_source : ecd95fb9c75652659f2542b79a2f4ff5dbe5c863
The bug is server.hostname should be server.hostName.
Take the chance to refactor MsgIncomingServer and MailAuthenticator a bit to prevent showing multiple auth dialogs for the same server.
Differential Revision: https://phabricator.services.mozilla.com/D155534
--HG--
extra : amend_source : 67039c16f44a4c3bb2062fd67b50c32b99e9d7b9
These modules don't need to be loaded with the module that imports them. Some don't need loading at all.
Differential Revision: https://phabricator.services.mozilla.com/D154028
--HG--
extra : rebase_source : f5237f1d748397e2d74591755d509608352f57f1
extra : histedit_source : 18ecbb0b9e89caf6acbf7b049a87873bf672ef9a%2C4a1330d1e866d3f43ca5bf1cb67a0ce5cde2eedb
These two modules are loaded at profile-after-change to add some listeners/observers. AFAICT, none of the things they are listening for will happen this early, so we can initialise them later.
Differential Revision: https://phabricator.services.mozilla.com/D154026
--HG--
extra : moz-landing-system : lando