!AppConstants.MOZ_UPDATER won't have that file...
Differential Revision: https://phabricator.services.mozilla.com/D212670
--HG--
extra : amend_source : 0444854ce44186ae027bb8700c2ed09d6b8f2aa8
extra : histedit_source : 5213a00b4567b701e36221ae87cd2a9d0527cece
We used to use this code when printing address books. We don't do it that way any more.
Differential Revision: https://phabricator.services.mozilla.com/D212660
--HG--
extra : rebase_source : d3689144ab3e9776a64774e6cadf1aa490a4fb42
extra : amend_source : fcca84ddcb9594a7d27aa66c6caa2b22439ccdee
What is supported:
- Hold CTRL while clicking to select multiple rows.
- Hold SHIFT while clicking to select a range of folder from the currently active element.
- Hold CTRL and press arrow up/down to select next/previous row.
- Enable multiselection via data attribute to keep the widget modular.
Specific to Folder pane:
- Enable only a few simple actions when in multiselection
- Open in Tab/Window and Mark as Read are always enabled.
- Move and Copy only if conditions are met.
- Empty trash/junk only if the selected folders are all trash/junk.
Differential Revision: https://phabricator.services.mozilla.com/D203232
--HG--
extra : amend_source : 20aec1999e7f5034189b7740f5e4747a76cd4c06
I forgot to include the Thunderbird config additions.
Differential Revision: https://phabricator.services.mozilla.com/D212513
--HG--
extra : amend_source : 1f464c0dee553d91b053e984d95c647d5ee25017
The `listInlineTextParts()` function defined in this test is a helper
function to extract the content of inline text parts. These parts are
the only parts which have their content returned by `messages.getFull()`
and are not returned by `messages.listAttachments()`.
Since developers need detailed knowledge about MIME and the structure of
messages in order to access the content of these parts via `getFull()`,
this helper function can be used to return a flat list of all inline
text parts, just as `messages.listAttachments()` returns a flat list of
attachments.
There is an attempt to add this helper function directly to the API (see
bug 1898854), but it is currently stuck in review. For now, the helper
function will be provided through documentation. Since we are officially
exposing this function, this patch adds a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D212562
--HG--
extra : amend_source : 5af9e60ab359bd823ef000f149021aab2c7e3e07
This adds a test for the issue raised in Bug 1737532.
Differential Revision: https://phabricator.services.mozilla.com/D212543
--HG--
extra : amend_source : 549c298f46a71d65b012a23ff79192d33f84099b
When the messages API had been initially created, the function
`getFull()` did not return the binary content of parts. The
`listAttachment()` method should be used to access the content
of these parts, which the API refers to as "MessageAttachment".
So called related parts, for example inline images are currently skipped
by `listAttachments()`. Even though these parts are defined as inline, I
still want to handle them as attachments and have them returned by
`listAttachments()` and `getAttachmentFile()`. I do not want to intoduce
a second set of functions to handle "inline attachments".
This patch adds the `contentId` property of related parts to the
`MessageAttachment` type and returns them in `listAttachments()`. The
content itself can be retrieved using `getAttachmentFile()`.
Differential Revision: https://phabricator.services.mozilla.com/D212030
--HG--
extra : amend_source : 398d1d2006f4695f3d5ed77eff3bbd40791689a7
We should only use `id` inside a primary type definition. For example
the `MailFolder` type defines an object representing a folder, and it
has an id to reference that `MailFolder`. If a `MailFolder` is used
elsewhere, it should be a named id, for example `folderId`.
We correctly do this in about 99%. However we have these exceptions:
* mailTabs.MailTab: This is not a primary type, it uses tab IDs from
the `tabs` API
* compose.ComposeRecipient: It uses node IDs from the `contacts` API
or the `mailinglist` API
* spaces.querry: It should use `spaceId`, compare with the `folders` API
This patch fixes that for Manifest V3. We have this issue also in the
documentation of parameters, but that has no influence on the code of
extensions and can be changed later.
Differential Revision: https://phabricator.services.mozilla.com/D211914
--HG--
rename : mail/components/extensions/test/browser/browser_ext_compose_begin_headers.js => mail/components/extensions/test/browser/browser_ext_compose_begin_headers_mv3.js
extra : moz-landing-system : lando
The migration UI that used this code was removed in bug 1867860, and hasn't worked since 91,
according to the commit message on that bug.
Differential Revision: https://phabricator.services.mozilla.com/D212502
--HG--
extra : amend_source : f5e697b36ef958669d618585b50000dd9766109c
There was leftover code in nsParseNewMailState from the everything-is-an-mbox days.
This meant messages lines beginning with "From " in the body would flip it back out
into header-parsing mode, causing database fields to be filled with rubbish.
This particularly affected POP3 mail. IMAP uses a different class for header parsing.
Differential Revision: https://phabricator.services.mozilla.com/D210737
--HG--
extra : rebase_source : 202b7134495c2ecfe23eff90f0a2c651d3e63087
Daniel Darnell
Richard Marti
Ian Neal
Bill Gianopoulos
Magnus Melin
Martin Giger
Vineet Deo
Joe Crawford
Sean Burke
Geoff Lankow
Rob Lemley
welpy-cw
Thunderbird Updatebot
Kai Engert
Alessandro Castellani
John Bieling
Brendan Abolivier
Ben Campbell