Technically broken (unencoded dot!) "From:" addresses like
=?utf-8?Q?WestLicht.=20Schauplatz=20f=C3=BCr=20Fotografie?= <info@westlicht.com>
were not decoded in Geary's conversation viewer.
Other clients like Gmail and Thunderbird handle the
brokenness, and we should too.
This also closes bgo#714339, "subject contains garbled UTF-8
characters".
https://bugzilla.gnome.org/show_bug.cgi?id=713060https://bugzilla.gnome.org/show_bug.cgi?id=714339
Background synchronizer was keyed to work on ImapEngine.GenericFolders
which are no longer the most basic IMAP folder in the system. This
prevented the account synchronizer from doing any work at all.
We had a bug in our DateTime to time_t conversion logic where all
time_ts would end up in the year 3800. This fixes that, and repopulates
the internaldate_time_t column with the new, correct time_t values.
Closes: bgo #724335
In their hidden state, quotes will be limited in length, with a link to
extend them. Only long quotes will be hidden; short ones will be
displayed in their entirety. Note that the threshold for hiding a quote
is larger than the size of the hidden quote. This ensures that there
will always be a noticable expansion of a quote when it is shown. (This
also accounts for the fact that the height we measure includes padding.)
We can only measure the size of a quote once it is actually shown as
part of the document. Notably, we can't figure out the sizes of quotes
in hidden emails. Therefore, we also decide which quotes in an email
need to be hidden when the email is unhidden. However, showing and then
hiding quotes can lead to content flashing, so we start all quotes off
in the hidden state, and remove this if they turn out to be short
enough.
This looks for some translatable common names for special folders like
Sent Mail, Drafts, Spam and Trash, instead of only relying on the
server's special-use or xlist extensions. If the server doesn't report
special-use/xlist, we look for common folder names, creating them on the
server if necessary, so we always have folders necessary for tasks like
saving drafts or sent mail.
Closes: bgo #713492
The character following the token is found through a look-ahead, to
avoid consuming the opening of the next token. (There should be
newlines separating tokens, but in some poorly understood circumstances,
this doesn't happen.) We don't use a look-behind at the beginning, so
that the second consecutive token doesn't insert a second newline
between the two. (The first of the pair already gave us one.)
Closes: bgo #723742
The "enabled" property is no longer used, so removing.
If the flag watcher is cancelled (because the folder has been closed),
the watcher was still rescheduling another polling loop. This patch
prevents that.
If compiled with the GDK binding fix in Vala 0.23.2 (bgo#713240), this
patch fixes the accelerator problem.
Tip o' the hat to Charles, who pointed out the accelerators.ui file.
In particular, bug #713493 reports this, although this patch doesn't
appear to solve the problem entirely. However, I have spotted
situations in the past where the Append replay operation caused local
operations to hang. This is because Append was being treated as a
local operation when, in fact, it's first call is back to the server
to fetch UIDs of the new messages. Hence, it should be treated as
a remote operation so local operations can run without delay.
Previously, synchronizing folders caused a jump in CPU, so work was
done to minimize activity. Optimizations to folder normalization
has reduced the CPU load, so it's okay now to allow flag watching
while the background folder is open.
This is not a substitute for an architected solution: periodic
flag synchronization with folders, not merely when changes in contents
(additions/removals) are detected, but this helps some, especially
with high-traffic folders.
More testing of previous changes located two other problems that
this patch fixes.
First, if a connection reestablishment was attempted but the reconnect
failed initially (common if the server is simply unavailable, i.e.
recent Gmail outage) the reestablishment logic halts. This patch
forces another attempt.
Second, the back-off delay that used to be present in the
conversation monitor (when it handled reestablishment) was missing
in the new code. This adds it back.
One bug in that commit was that only one of two the two conditionals
for entering connection reestablishment was considered when
determining if the Folder should close. This change now uses both
conditionals. Without this, it's possible for the remote to fail
to open due to connection error and the Folder to remain open although
reestablishment doesn't occur because there's no remote folder to
establish with.
OpenMailbox.org doesn't complete transactions when the IDLE state
is entered while commands are outstanding. One thing I've considered
for a while is only issuing IDLE when no comands are outstanding,
as in some situations the connection state "thrashes" if commands
come in back-to-back. This commit does just that, only entering
IDLE when no commands are outstanding.
