Folder now offers an "email-inserted" and "email-locally-inserted"
signal to indicate when email has been added (or discovered) but
is not added to the top of the message vector. SearchFolder and
ConversationMonitor may be able to use this better in the future.
Just experienced a crash in the SmtpOutboxEmailIdentifier
constructor trying to get its own type name. Past experience
has shown that calling into GObject (or GType) in the constructor
before calling base() is dangerous, so changing this to a flat
string.
Imap.Folder is now more paranoid about checking if the ClientSession
is available before performing an operation. The ReplayQueue does
a better job of flushing pending commands when closing the Folder.
This optimizes the search query itself, and also how we get the results:
instead of turning around and selecting the full row for each resulting
id, we simply pull out the id and internal date and that becomes the new
SearchEmailIdentifier. This new class also lets us more properly order
EmailIdentifiers everywhere else.
Missing mnemonics in composer context menu: Closes#7439
Context menu items need capitazliation: Closes#6862
No tooltip for remove button in Accounts window: Closes#6551
Print menu item needs ellipsis: Closes#7259
"Saving..." -> "Saving" in composer: Refs #7365
This was recently changed for the double-archive problem and now these
ReplayOperation calls can happen at any time, not just after the
location execution, so they need to do null checking every time.
I noticed the double-archive problem again just now. Looking at
the log, it took even longer than 250ms for Gmail to notify of the
EXPUNGEs after the append, so this patch increases the delay to a
full second.
It may be that this delay strategy is only pushing the timing hole
around, but until we can come up with a better solution, it'll have
to do.
Two bugs are fixed in this patch:
(a) Freemail's XLIST returns the Inbox's name in Ukranian. This
is a problem when doing a direct list (i.e. XLIST "" "Inbox") to
get folder properties. This is fixed by using LIST whenever listing
Inbox.
(b) Freemail returns FETCH BODY[] header fields back in an
indeterminate order. Previously the IMAP stack relied on a string
comparison to match up the response with the request. New code
now properly (but painfully) parses the BODY[] response, obviating
the need for FetchBodyDataIdentifier.
The slight pause (sometimes up to 2s on my machine) was due to some
CPU-intensive work occurring during folder normalization. Some of
the work can be done in a background thread (using the new
Nonblocking.Concurrent class), but some of the problem was simply
that the Deserializer's priority was too high, causing it to block
UI events when it was busy (such as requesting a lot of UIDs from
the server).
This was also developed while working on #7426. Before, the IMAP
implementation walked and built-up strings using unichars. However,
IMAP guarantees 7-bit ASCII in all data transfers (except in literal
data, which isn't processed at this level), so use old-style ASCII
processing of request and response strings, which is slightly more
efficient.
Because full folder normalization is avoided whenever possible,
need to go back to marking messages as removed in the database (vs.
just in memory) so if messages are not removed on the server (or
the response was not received for some reason), the folder is seen
as "dirty" and a full normalization is processed.
This is a tricky timing bug triggered by Gmail sending EXPUNGE and
EXISTS notifications in a particular order with a slight timing delay
between them.
Normally Gmail will send one or more EXPUNGE notifications followed by
EXISTS to finish up a list of removal notifications. Even if the
client sends an APPEND followed by STORE/EXPUNGE, the EXPUNGE
notifications are first.
However, if the client STORE/EXPUNGEs on one connection and a new
message arrives from another (or via SMTP), Gmail will issue an
EXISTS (append), wait 250 msec, then issue the EXPUNGE(s). In
that 250msec delay, Geary has already turned around and requested
the new message, which no longer exists at the reported position
because the EXPUNGEs (which have not arrived yet) have shifted it
downward.
The solution is to pause when notifications come in so all can
be accounted for, shifting positions as necessary.
This should take care of the problem, exacerbated by multiple Inbox
folders being allowed in the root of the FolderTable. Much more
strict in this patch about folders named "Inbox".
Vector expansion was broken in that the unfulfilled map was being
populated with EmailIdentifiers lacking a message_id, only a UID
(from Imap.Folder). More rigorous unfulfilled map now in
AbstractListEmail that requires a UID, not an EmailIdentifier.
Also guarantees that the email is fetched exactly once per
transaction by mapping UID -> fields, then "flipping" the map
back to fields -> UIDs, maximizing the number of emails requested
per FETCH.
A recent optimization for EmailStore was to only open a connection
to the remote folder if a command came in requiring it. If an
ImapEngine.GenericFolder is opened for monitoring, however, no command
may come in requiring a remote connection, meaning no folder
normalization or unsolicited notifications arrive.
This patch "forces" the remote to open after a timeout, which is
cancelled if it's opened by a command.
Folder normalization is now much simpler, faster, and requires
less resources than prior implementation. Normalization affects
the ReplayOperations, so an interface was changed here.
Two problems: (1) Error was being thrown while mutex was held, causing
the SearchFolder to forever be locked. (2) INCOMPLETE_MESSAGE Error
was causing list operation to abort prematurely (which in turn was
due to #6604).
We were erroneously going into the database to find UIDs for messages we
just did vector expansion on, and thus hadn't yet recorded in the
database. With this patch, we use the UID from the EmailIdentifier
itself in that case.
Previously, the EmailIdentifier key's hash value was sometimes changing
during the execution of the function, so when someone later went to look
up the flags, the hash map was returning NULL. This way we delay
hashing the EmailIdentifier till right before it's used, so its hash
value can't change.
Both these problems stemmed from conversations holding messages from
in-folder and out-of-folder, and that all messages in the search
folder are considered out-of-folder.
The problem was due a timing issue in ClientConnection FSM; it was possible
for the machine to still be in the IDLE or IDLING state when ready to
SYNCHRONIZE. This is due to a timing hole where the server's response to
close IDLE (requested when the APPEND command was sent) didn't return in
time. This closes that timing hole and deals with SYNCHRONIZE occurring
while in IDLING/IDLE.
This is squashed commit (sorry -- we'll get better about maintaining a
clean history in collaborative branches in the future!) of a massive
amount of work from Jim and myself.
* EmailIdentifiers for normal (i.e. not outbox, etc.) emails are the
same regardless of which folder they came from
* New EmailStore interface to manipulate messages that reside in any
folder, without having to care what folders are open
* Relevant places that manipulate emails (e.g. the toolbar) have been
updated to use the new EmailStore interface
* Conversation and ImplConversation have been smooshed together
* Many, many more items and bugfixes related to the above points
We discovered a situation where, depending on the order email is
processed, it's possible for logically associated emails to form
two or more conversations. When an email is processed that belongs
in more than one conversation, its removal triggers this error (as
a Message-ID can be associated with one and only one conversation).
Bogus email headers, especially email that does not list a complete
References: list, aggravate this problem.
