When deleting a collapsed group in a view that is grouped by sort, it is necessary to prevent the
front-end from being notified twice to remove that row.
Differential Revision: https://phabricator.services.mozilla.com/D208067
--HG--
extra : amend_source : 40b0eb24caadca6eb59a971500e860f40be7b2a6
nsMsgWindow::GetTransactionManager will just return the current state, and (almost) always NS_OK.
Differential Revision: https://phabricator.services.mozilla.com/D207698
--HG--
extra : amend_source : 71155806e2ac9b8f03a314cc105b03de8f6129cc
For some folder types, nsIMsgFolder::GetSubFolders calls nsIMsgPluggableStore::DiscoverSubFolders, which might attempt to rectify its in-memory representation of the folder architecture if it finds storage for folders it hasn't already recorded. nsIMsgFolder::GetSubFolders is called by nsIMsgFolder::AddSubfolder (via nsIMsgFolder::GetChildWithURI), meaning that if, when creating the subfolder, we create the storage for it before registering it, we might end up in a situation where nsIMsgFolder::AddSubfolder tries to register it twice, and fails on the second attempt (because the subfolder already exists).
Differential Revision: https://phabricator.services.mozilla.com/D207320
--HG--
extra : amend_source : 038a9b85529ee6b15f691e682d96f4ffcb81ed38
I tend to officially sunset DAV-4-TbSync, and the only remaining
"feature" it supports which is not yet supported by Thunderbird is the
detection of iCloud calendars and address books.
Fixing iCloud CalDAV discovery is handled in D206253.
The reason CardDAV discovery currently fails is: iCloud returns a 207
response for `${url.origin}/.well-known/carddav`, but it does not
contain any useful information. The returned multi-response only
includes one entry, which has a 404 status. The actual good response is
retrievable from `${url.origin}`, but since we have a response already,
it is skipped.
This patch clears the response, if it has no useful information, and
that seems to be enough. One could of course also check for the 404 status
inside the multi-response. But I see no need for it. The code used in
this patch is already used a few lines earlier, probably to work around
a similar issue.
This patch has two unresolved issues (when it comes to iCloud):
- iCloud does not send a displayname and "card" is used. It should
fall back to "contacts" or a similar name, if no displayname is found
- the original request was made to `https://icloud.com`, and the code
is currently not smart enough to use the same provided password for
the follow-up request to `https://p119-contacts.icloud.com` (in my
case) and a second password prompt is shown.
I can provide iCloud access credentials.
With this patch, I can enter my Apple-ID as username using a dedicated
app password created for Thunderbird, and the server `icloud.com`, to
get my address book discovered and added.
Differential Revision: https://phabricator.services.mozilla.com/D206267
--HG--
extra : moz-landing-system : lando
I added some IO error handling for writing to popstate.dat.
How the other reported errors hang together or not, I can't say. The client doesn't directly
interact with the the message db (mork) - but that is handled by the sink.
Differential Revision: https://phabricator.services.mozilla.com/D206885
--HG--
extra : rebase_source : d0360f8b1d8e3d4256683e31ad52d6ca15e460db
There's a generic nsIMsgFolder::URI() which is implemented in terms of GetURI().
This will work on non nsMsgDBFolder-based folders, even if they are written in JS or rust or whatever.
Then there's also an inline nsMsgDBFolder::URI() which the compiler can optimise for when the concrete type is availible to it.
Differential Revision: https://phabricator.services.mozilla.com/D206972
--HG--
extra : amend_source : b64406dfb6e624ae28b93587e3340b43bc976dd7
- 'news' URIs are opened in a new tab or window depending on preference.
- Enable opening 'news' URIs that do not specify a host by using the first NNTP server found.
- Open newsgroups identified by a URI directly without opening an empty message window.
Differential Revision: https://phabricator.services.mozilla.com/D205036
--HG--
extra : amend_source : 11c0122632fccbd62d8c2b83e6b603d06cf68745
test_offlineStoreLocking.js has also been tweaked because it depended upon the old behaviour and on some rather dubious timing.
Differential Revision: https://phabricator.services.mozilla.com/D205656
--HG--
extra : amend_source : d90bc89be2d7db2bb7d4ba77c3bbff2fbb0d22dc
This patch does not implement Exchange's HTTP 401 Challenge described in bug 1679711, as more research is needed to figure out exactly how this can be done. Instead, it tries authenticating against known providers the "normal" way when possible, then using the resulting token against the Autodiscover endpoint. If it can't, then it tries falling back to Basic auth.
This patch does not support falling back to Basic auth if the Autodiscover endpoint responds with a 401 following an OAuth-authenticated request. This may be implemented in the future, but in the meantime being able to get an OAuth2 token but not being allowed to use it against the autodiscover endpoint should be unlikely enough that this is not an issue.
Differential Revision: https://phabricator.services.mozilla.com/D205762
In threadPane.js exists similar code as in about3pane.js, to convert the
sort type of the current sort column into a columnId.
This patch moves these functions as an additional getter into
DBViewWrapper.jsm.
To avoid circular dependencies, this patch moves OUTGOING_FOLDER_FLAGS
from DBViewWrapper.jsm to FolderUtils.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D200242
--HG--
extra : rebase_source : 1e47ef7b626915999d743915cd842d55fc3bb7d9
Update outdated .jsm references in the tree.
Depends on D204766
Differential Revision: https://phabricator.services.mozilla.com/D204769
--HG--
extra : rebase_source : cdf8c1367702bb00c51a750cc712e156db65d371
extra : amend_source : 5f2256fc97ae8f3de2086ffbe99acde9fdef0473
The changes are described in bug 1880043 comment 8 and comment 9.
Differential Revision: https://phabricator.services.mozilla.com/D203652
--HG--
extra : amend_source : 94dbde277362898d46b88021533814aff6735f96
Modernizer browser_junkCommands.js which led me to find the bug.
Test cleanup will remove the folder, and url processing finishes later...
IMAP and NNTP urls also just return null.
Differential Revision: https://phabricator.services.mozilla.com/D204017
--HG--
extra : rebase_source : f38742af7a3d970a96eca0b2d5fa9ba606c82ced
extra : amend_source : d4f089e32ca10c39e652462420bc45d042b8e274
Nowhere was stated that the string parameters of nsISmtpService.sendMailMessage() had to be URI encoded.
Differential Revision: https://phabricator.services.mozilla.com/D204592
--HG--
extra : amend_source : cc962000c8b45f3a2ee46fdda61e1153a15730ab
The fix in https://hg.mozilla.org/comm-central/rev/8aa30c8f177d#l1.12 wasn't correct.
An empty recipient shouldn't be forced to NS_ERROR_ILLEGAL_LOCALPART with a missing error insert in
There are non-ASCII characters in the local part of the recipient address %s and your server does not support SMTPUTF8.
Differential Revision: https://phabricator.services.mozilla.com/D204591
--HG--
extra : amend_source : 88609ae6978b9d2c00a16cb76f58da5d27a7d2ee
Geoff Lankow
welpy-cw
Kai Engert
Magnus Melin
Brendan Abolivier
Alessandro Castellani
John Bieling
Ben Campbell
Ikey Doherty
Martin Giger
Sean Burke
Micah Ilbery
Gene Smith
ISHIKAWA, Chiaki
Yury Ivanovich
Silvia Bonavista i Serrat