For IMAP, it seems the double load is inevitable, see bug 520272 for history...
For local folders there was a counfusing double load which I've fixed, along
with some added documentation to clarify a few code paths.
Differential Revision: https://phabricator.services.mozilla.com/D207340
--HG--
extra : moz-landing-system : lando
**How to Test**
- Run a clobber do get a fresh TB profile
- Opening a message in a new tab should now focus to that tab
Differential Revision: https://phabricator.services.mozilla.com/D208362
--HG--
extra : moz-landing-system : lando
- Changes the behaviour when a certificate error is encountered. Instead of just showing the
certificate override dialog box, show a notification which opens the dialog if it is clicked on.
- Uses a different notification text depending on the type of error. Domain mismatch (potential
man-in-the-middle) errors will not show the certificate override dialog at all.
- Surfaces errors that appear from changing the displayed folder. Previously these just silently failed.
- Tests all of the above.
Differential Revision: https://phabricator.services.mozilla.com/D208956
--HG--
extra : rebase_source : bc569ba7a6555aef27fba39b1429a18c9cec7dbf
extra : amend_source : a48d8b7ad7f7030b33fcf5f543f00581785fedbd
We're missing a bunch of coverage data if the test finishes before the message loads. The data is not
from the loading window, but one of its ancestors, so I'm not entirely sure what's going on here.
Differential Revision: https://phabricator.services.mozilla.com/D209181
--HG--
extra : amend_source : c1d6b203cfc5701907421726295793507e51f4cb
When we don't provide setting up an account, it's just confusing.
Differential Revision: https://phabricator.services.mozilla.com/D208862
--HG--
extra : amend_source : 6b04ac5d861b6b046404bb6f52aeabb39df42e0f
This exposes the concept of folder modes in the folder pane to
WebExtensions. The MailTab type has gained a `folderMode` member and a
`folderModesEnabled` member.
The `MailTabs.update()` function is now able to modify the enabled and
the current folder modes.
Differential Revision: https://phabricator.services.mozilla.com/D208600
--HG--
extra : amend_source : 3d2077cba87056ef2c716628d1ccb3a2f5ac6e5a
Renames the `quickSearch()` function to `query()` and re-adds the former
as a wrapper for the later. The wrapper handles the modified parameter
definition. The query() function now only accepts a `queryInfo` object,
which has gained the `parentId` property in Manifest V3.
This is consistent with our other `query()` functions, for example in
the messages API or the folders API.
Therefore `contacts.quickSearch()` remains usable in Manifest V2 as
before, and `addressBook.contacts.query()` is now usable in Manifest V3.
At a later time we can extend `query()` to support additional search
terms/fields to better search vCards.
Differential Revision: https://phabricator.services.mozilla.com/D208374
--HG--
rename : mail/components/extensions/test/xpcshell/test_ext_addressBook_quickSearch.js => mail/components/extensions/test/xpcshell/test_ext_addressBook_query_mv3.js
extra : amend_source : 5fe1aa7c02c7cbaa5857f47ebbaa40e12e1915a7
This is based on feedback from developers. The contacts API, the
mailingLists API and the addressBooks API are currently disconnected,
even though they are tightly coupled.
Differential Revision: https://phabricator.services.mozilla.com/D208355
--HG--
extra : amend_source : 3b26e5ea76f00e433c41541b11bd188d901dc2c8
This uses a different syntax in the schema definition for optional
properties. Instead of sending all optional but unset properties as
`null`, they are omitted, allowing to actually use `null` as a reset
value.
I did not know about this when creating the API initially and resorted
to using `""` for resets. Using `null` for resets feels much more
natural and is used in other APIs (for example in the browserAction
API).
Differential Revision: https://phabricator.services.mozilla.com/D208068
--HG--
extra : amend_source : f7e6d5af168fcd19a5b8010a80f5f1525a0b4e0e
This adds a dedicated method to get one of the unified mailbox folders.
Differential Revision: https://phabricator.services.mozilla.com/D207996
--HG--
extra : histedit_source : 737f1770f9a08bdaf0c0999c97ec302d11c5a183
Unified mailbox folders need special handling, because they do not have
an accountId in the WebExtension API. Switching to the `getFolder()`
wrapper, to get the real folder from a WebExtension MailFolder
object.
Differential Revision: https://phabricator.services.mozilla.com/D207984
--HG--
extra : histedit_source : 28cce0737edad7fd6814aa8d3e5ae6703afe7a7b
The test failed to deliver read/unread message counts, because the
smartserver was created only after the test messages had been added.
This also adds a proper exception, if `getFolderInfo()` is called on
root folders (it already threw a cryptic error before, because
`folder.msgDatabase.*` failed).
Differential Revision: https://phabricator.services.mozilla.com/D207959
--HG--
extra : histedit_source : 6a5c20655423513c65e67db2d4031696bfa182f6
This is a reworked implementation, based on the feedback given in
D198475.
The unified mailbox folders are no longer exposed to the accounts API.
They exist independent of any account. The `accountId` property of the
MailFolder type is now optional.
Unified mailbox folders get a fake path: /unified/*. They are clearly
identified because they do not have an accountId, and there should not
be any collisions with real accounts having a /unified/ folder.
Differential Revision: https://phabricator.services.mozilla.com/D207809
--HG--
extra : histedit_source : 3ccac2ef43b8d2cae13b04117e991170db962486
This is based on
https://searchfox.org/comm-central/rev/9eee1dc9386561ac322d64adaa25e9cd55960ea1/mail/base/test/widgets/browser_treeView.js#56-70
but instead of creating a wrapper around each possible action, this
aims at checking the idle status *before each check*. If the tree
view is still busy updating the UI, the check waits until it is idle,
before moving on.
I found this approach less error-prone, as it is less likely to forget
to wrap a function call and therefore less likely to introduce new
intermittent fails.
Differential Revision: https://phabricator.services.mozilla.com/D208515
--HG--
extra : rebase_source : dc5fe7eaef1dbf22896f988a7bf9ac38a362f56e
extra : amend_source : 5c7f4f78cdc990d4bb72bc9fc702b407015c2bba
Will be superseded by D208515.
--HG--
extra : rebase_source : a471a930a109ce11a9bf2247bb5c4a3c2bf83657
extra : amend_source : 5424b131fd69cc5eca5a9c413371385fec783cba
The `Tab` type has a `type` property which can be set to `mail`. We do
not need the extra `mailTab` property.
Differential Revision: https://phabricator.services.mozilla.com/D208018
--HG--
extra : amend_source : 8396efe402afbf5f8d6c4ba05b3a5fec0637cc2a
**How to test this**
- Open Preferences > general > Formatting of recipients:
- Change between the various radio button options.
- Assert that the `From` and `Correspondents` column in the table view are respecting the chosen option.
- Assert that if a recipient is saved in the address book with a display name, it is not overwritten.
- Assert that also in Cards View the sender follows the same data format.
Differential Revision: https://phabricator.services.mozilla.com/D207221
--HG--
extra : moz-landing-system : lando
Apparently detachment doesn't always complete after only requestAnimationFrame
Differential Revision: https://phabricator.services.mozilla.com/D208316
--HG--
extra : moz-landing-system : lando
In https://hg.mozilla.org/comm-central/rev/4ab32edc743e I had missed two cases where promptKeyExport2AsciiFilename are now really async.
The dialogs seemingly do the right thing, but it doesn't actually backup if you check for the file.
Added a test so it doesn't regress again.
Differential Revision: https://phabricator.services.mozilla.com/D207524
--HG--
extra : amend_source : 6c1ae0b6d13bd6eeb1acedadf480f9fc9b899be4
Almost all are CCov builds timing out. Looking at the logs it seems the tests many times just is slow
to get started there.
Differential Revision: https://phabricator.services.mozilla.com/D208170
--HG--
extra : amend_source : ab33d7a98b5a6018916e2b99790c7ef2c794bb6e
We may have closed the window before the copy to folder had succeded.
Differential Revision: https://phabricator.services.mozilla.com/D208146
--HG--
extra : amend_source : 7e224a32938dc8bcc847021144c7f3dc2634bc6e
The logs show complaint about null gMsgCompose.
Also make some tests work with verify.
Differential Revision: https://phabricator.services.mozilla.com/D207772
--HG--
extra : amend_source : 1406206c7972d55f7bcdd37a88663ca0f1bb43f0
- Set proper style attributes in threadTree when changing between grouped-by-sort and threaded in multi-folder search views.
- Actually set the collapsed/expanded state either in `onCreatedView` or in `onMessagesLoaded(all)`
- Correctly restore expand-all state of grouped-by-sort multi-folder search views (Bug 1892065)
Differential Revision: https://phabricator.services.mozilla.com/D207799
--HG--
extra : amend_source : b61a5c276374e0f08fe0f7f544cabcff172d80a8
I guess the issue is caused by openAddressBookWindow() and similar test
helper functions only waiting for the "load" event, but our front end
code has a lot of async UI code which is triggered on load and therefore
the test tries to access elements too early.
This uses a similar fix as introduced in D207481.
Differential Revision: https://phabricator.services.mozilla.com/D207672
--HG--
extra : amend_source : 747514d1dc2284db03de9456fd1796286ad1812b
Also updating the naming of the allowlist while here.
Differential Revision: https://phabricator.services.mozilla.com/D207856
--HG--
extra : amend_source : 8efc09701bf867b76b4fa82ff052ed1ee2075912
Show the unabbreviated name in tooltips in both the folder list and the message list header,
Differential Revision: https://phabricator.services.mozilla.com/D207395
--HG--
extra : amend_source : ddf68c63c6b0e692032f32fbc4a5530ab7fc0e44
This is D198713, but re-implemented after D198475 (Bug 1874509) was not
accepted (which it depended on).
The type for local accounts has been 'none' in Webextension Manifest V2.
In Webextension Manifest V3, I would like to change that to 'local'.
Differential Revision: https://phabricator.services.mozilla.com/D207536
--HG--
extra : amend_source : cb837f980ea000afcdfa9d3add87cfaf40f7fcee
This is based on the fix for the same issue accepted in D207481. This
patch fixes all such usages in this test, not just the one which failed.
Differential Revision: https://phabricator.services.mozilla.com/D207525
--HG--
extra : amend_source : 54cee9fafc7d420de1534b9bc9f8d44e4758e038
This is based on the fix for the same issue accepted in D207481.
Differential Revision: https://phabricator.services.mozilla.com/D207526
--HG--
extra : amend_source : 9a9232da1f802f03aaa0588d9f07be9abfa14376
**How to Test**
- Go to unified toolbar customziation window
- Type text in to search bar for clear button to appear
- Clear button should function the same as the global search and quick filter bar
Differential Revision: https://phabricator.services.mozilla.com/D207449
--HG--
extra : amend_source : 9e3b7fa44fe52969cad42dc7bd842ed2dc0b6d6f
I observed that the element in question really was not yet present,
when this fail occured. Waiting for it seems promising.
Differential Revision: https://phabricator.services.mozilla.com/D207481
--HG--
extra : amend_source : 31fcef060a1d8dd799df23607d22ec262c4b23c1
This is based on the fix for the same issue accepted in D207481.
Differential Revision: https://phabricator.services.mozilla.com/D207522
--HG--
extra : amend_source : c3863a1760b5878edb6a6699896adfd03d14333e
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
Magnus Melin
Richard Marti
Vineet Deo
Geoff Lankow
welpy-cw
Martin Giger
Alessandro Castellani
John Bieling
Brendan Abolivier
Mike Conley
solange valverde
Joe Crawford
Mozilla Releng Treescript