**How to Test**
- Open mail tab
- Type input into either Quick Filter Bar or Global Search Bar
- Clear button should appear
- Clicking clear button should remove input and hide clear button
- Typing and hitting escape should remove input and hide clear button
- Typing and deleting should make clear button appear and then hide
Differential Revision: https://phabricator.services.mozilla.com/D207064
--HG--
extra : moz-landing-system : lando
We don't support encrypting to newsgroups. For other messages, you cannot send before
recipients have been set: the whole check is therefore pointless.
A lot of other things to clean up here as well... e.g. aliasing of functions of members
is certainly a bit unusual, and splitRecipients does not have a third arguments since many years,
but I guess it wasn't noticed due to the above...
Differential Revision: https://phabricator.services.mozilla.com/D207118
For the thunderbird fastmail imap test account, the issue is that since it's a thunderbird subdomain,
and there are no SRV records for it. During detection we fall back to asking SRV records for the basedomain, which
is thunderbird.net, which is known to be google hosted => we pop up OAuth2 to be able to detect calendars.
We don't fall back to base domain for CardDAV, and I would say we should not do it for CalDAV either.
This would potentially affect someone who is using a subdomain for hosting, but not setting
the SRV records for their subdomain - AND the base domain at the same time are setting the SRV records and
they are usable for the subdomain credentials.
Such cases probably exist, but it would not appear to be a very normal case. Where a subdomain is used
for the email address (which is where we get the subdomain from) likely it's often some kind of testing/staging
environment, like it is for thunderbird.net.
That OAuth2 is requested during account setup during CardDAV/CalDAV autodiscovery is in itself
not unexpected if we discover those services are hosted differently from mail, and thus might
not have the same credentials.
Differential Revision: https://phabricator.services.mozilla.com/D207010
These preferences need a default value or otherwise the tests I'm trying to enable use a different default value and fail.
Differential Revision: https://phabricator.services.mozilla.com/D207216
--HG--
extra : amend_source : 8ca6086dc4b4bc7b4476868db472005277ca9427
The log complains about "Exception while attempting to mark message with
gloda state afterdb commit". No expert here, but forcing gloda to index
and waiting for it to finish might help.
Differential Revision: https://phabricator.services.mozilla.com/D207336
--HG--
extra : rebase_source : 50ec008ef6ba298a2eb754157c6fc730b12906cf
extra : amend_source : 1d9e0532a5b7e917026c3cceb9366b205485837b
**HOW TO TEST**
- Hover over the thread button in the cards view.
- Try a multiple combination of densities and font sizes.
- Ensure the thread button always renders correctly and the top and bottom borders are visible.
Differential Revision: https://phabricator.services.mozilla.com/D207095
--HG--
extra : amend_source : 04abff4ad2461220617ea897e5e88b77da7740d5
As pointed out by mkmelin, there is some potential for raciness in the
testing where we could miss the click event.
We address this now rather than wait for a mystery intermittent test
failure to appear.
Differential Revision: https://phabricator.services.mozilla.com/D207149
--HG--
extra : amend_source : 12ac9774f44f0848ccb5575b47521e2750d662a0
The prior change seems to have landed between fixes, as it then caused the links
on our troubleshooting page to stop working, by forcibly removing their docShell.
We now work around this issue by detecting the special case when a parent opener
has isRemote set, such as in the extensions use case.
Differential Revision: https://phabricator.services.mozilla.com/D206445
--HG--
extra : rebase_source : e6c48e0911e067c12f8804d38df98999534efbfa
extra : amend_source : d6e6e5a13204c96f32739373692146bf70f4ef28
This patch adds support for the 3 injection points `document_start`,
`document_end` and `document_idle` for message display scripts. This
allows dark reader add-ons [1] to inject their CSS at an earlier stage,
reducing white flicker.
This patch also tries to remove a flicker, which currently happens when
switching messages.
To see the effect of the patch, try dark mode with [1] first and then
with [2], which is the updated verison of the add-on, using
`document_start` to inject the CSS as early as possible.
[1] : https://addons.thunderbird.net/addon/darko_t/
[2] : https://bugzilla.mozilla.org/attachment.cgi?id=9393235
Differential Revision: https://phabricator.services.mozilla.com/D205649
--HG--
extra : moz-landing-system : lando
- '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
I've also reverted the changes bug 1859656 introduced for the already existing Exchange/O365 account setup results, so they don't require a migration, since we'll probably be changing the UX in this area later on.
Differential Revision: https://phabricator.services.mozilla.com/D206790
--HG--
extra : rebase_source : 1b262331d5f15d2469335bdfe8cc0a046222c3ab
MailUtils.sys.mjs already contains openMessageByMessageId(), which basically does the same thing as
openMessageForMessageId() in msgHdrView.js. This integrates the former into the latter, and by
moving it to MailUtils.sys.mjs makes it accessible in other parts of the front-end as well as for
(experimental) add-ons. The same goes for openBrowserWithMessageId().
Differential Revision: https://phabricator.services.mozilla.com/D206249
--HG--
extra : rebase_source : 490079901e8ebcc19bd792a3c90a944bb8c1b0ac
Some tiny visual improvements to the folder pane:
- Slightly darker background color to match what's used in the address book.
- Add transition animation behind a media query.
- Add a box shadow that appears on scroll.
Differential Revision: https://phabricator.services.mozilla.com/D206570
--HG--
extra : amend_source : a46ea2bcb5a358338cf49f210c5bc0d651015958
extra : absorb_source : b4766b8e81fe180164e47ee21c19c5bf7ca3779a
Detect google CalDAV/CardDAV even if DNS MX records have UPPERCASE hostnames.
In the case of unisalento.it these are like ALT2.ASPMX.L.GOOGLE.COM
Differential Revision: https://phabricator.services.mozilla.com/D205878
--HG--
rename : mail/modules/dnsWorker.js => mail/modules/DNS.worker.mjs
extra : amend_source : 34aa4398f2e9faba280c6b1fef28813f2a0ae544
extra : absorb_source : 0d9c08ca50180e7b17b83c00a74bcba4dd88df31
Had to replace the appid used for env.appinfo.ID filtering. Also added a local timestamp to get rid of warnings.
Differential Revision: https://phabricator.services.mozilla.com/D205564
--HG--
extra : moz-landing-system : lando
Delaying the thread kill commands to animation frames fixes the command forcing
the parent of the submenu popup to close before it can propagate there naturally.
As a trade-off we now have to wait for the commands to actually execute their action.
Differential Revision: https://phabricator.services.mozilla.com/D202861
--HG--
extra : amend_source : 5644c6bf7cb81a41373d4583f9004d6d2b3041ba
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
**HOW TO TEST**
- Ensure you are in the Grouped by Sort view in Cards view
- Launch Thunderbird
- Ensure the rows are styled correclty and there's no UI flicker (you should notice that without the patch)
Differential Revision: https://phabricator.services.mozilla.com/D206300
--HG--
extra : amend_source : 58283c351d34f794c7d0c3ceaba4ded009b8279a
This element doesn't exist any more, so removing the style for it should be no problem.
Differential Revision: https://phabricator.services.mozilla.com/D206282
--HG--
extra : moz-landing-system : lando
**How To Test**
- Open up table view for Thunderbird
- Switch between densities and hover over mail list icons
- The full height of the icon box should be clickable
- There should be a little bit padding on each side of the icon to provide more of a clickable width
Differential Revision: https://phabricator.services.mozilla.com/D205628
--HG--
extra : amend_source : 60aff0917a89b71c014ea8a3c2aae0c53b9aa37a
**How to Test**
- Open up console and type openAccountHub();
- Select email, and fill in the IMAP fastmail test email in onePassword
- A Manual Config button should pop up in the footer
- Use imap.fastmail.com for incoming hostname, and smtp.fastmail.com for outgoing
- Set connection security to SSL
- Hit the re-test button, a loading screen should appear and you should be redirected back to the manual config form
- There is currently no success notification, but the continue button should be enabled now. Hit Continue.
- You should see an adding account loading screen, with a missing stop button, and then the account added screen
- The finish button should be at the bottom of the modal
- Selecting finish should redirect you back to the account hub
- Requests for a password, use the App Password for the fastmail account on onePassword
Differential Revision: https://phabricator.services.mozilla.com/D201847
--HG--
extra : amend_source : 3716753867b2eaa549e8e46f3a3473a3d6fbb553
This test failed sometimes with --verify, which no long seems to happen
after splitting it up.
Differential Revision: https://phabricator.services.mozilla.com/D205902
--HG--
rename : mail/components/extensions/test/browser/browser_ext_compose_sendMessage.js => mail/components/extensions/test/browser/browser_ext_compose_sendMessage_mv3.js
extra : amend_source : 7c52fed0d47ca4efb42b78b8c3b0914d77462697
I think the test was assuming wrong behavior. After the startup of an
extension which has a content script registered in its manifest, all
open tabs get injected into. This is different from registering a script
programmatically, which only affects newly opened tabs.
Removed timeouts after browser load and added timeouts before checking
for unchanged values.
Differential Revision: https://phabricator.services.mozilla.com/D205842
--HG--
extra : moz-landing-system : lando
Need to create a generic (not specific to download ) low space message property, too. Bug 1886349
Use Cr.NS_... idiom to refer to a constant.
Fixed the spelling attemped.
Differential Revision: https://phabricator.services.mozilla.com/D205286
--HG--
extra : rebase_source : caa216e963264cc2943b73f3f19e1c9f6c5a5b2e
This is the last patch for the stack of Bug 1877390. Everything outside
of DBViewWrapper now uses columnIds to for sorting. The special
handling for custom column sort has been moved entirely into the
DBViewWrapper.
Differential Revision: https://phabricator.services.mozilla.com/D200243
--HG--
extra : rebase_source : 20120c5c4dd999e8de965e20b812f923d95e3b5a
This continues the effort to remove redundant code. The relation
between sortType and columnId is defined in DEFAULT_COLUMNS and does not
need to be hard-coded in the DBViewWrapper.primarySortColumnId getter.
Differential Revision: https://phabricator.services.mozilla.com/D200290
--HG--
extra : rebase_source : 58a956816dbc9d4c536712484273c39071a08ee3
Both can be generated from DEFAULT_COLUMNS and do not need to be
maintained manually.
While modifying them, I learned that one of their use-cases in
HandleColumnClick() in threadPane.js can be simplified using the new
getter for primarySortColumnId.
Differential Revision: https://phabricator.services.mozilla.com/D200276
--HG--
extra : rebase_source : 4bea1ba0fdf8b5a2c4b87328b4c569bb6a386742
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
The function convertSortTypeToColumnID() uses dbView.curCustomColumn to
convert the "byCustom" sort type to a columnID. This however only works
for the current custom sort column, and not for any custom column. It is
also only used with the primarySortType (and not with any sort type) as
input.
To improve readability of this code, this patch reworks this function to
always return to columnID of the current sort column.
Differential Revision: https://phabricator.services.mozilla.com/D200212
--HG--
extra : rebase_source : 219d43da8faa064fdd95bc14388c1bc185aceb23
This will be set in mozilla-config.h which is force-included in all C++ code so it's
easy to use in #ifdef's or #if defined().
Differential Revision: https://phabricator.services.mozilla.com/D205749
--HG--
extra : moz-landing-system : lando
Failing at least comm/mail/components/extensions/test/browser/browser_ext_messages_open_attachment.js
--HG--
extra : amend_source : cfb6455a4d8c64f36dddcd841e011a7b7dbe10f6
The pref removal is a port of bug 1705440. Everything else is dead code.
Differential Revision: https://phabricator.services.mozilla.com/D205141
--HG--
extra : amend_source : 9cfb59c281c34a705231816429826dc48c1251e3
Adding back debugging infor for GPGMELib.
This should not be using global console for debug info, if such info is warranted.
For error cases, we can log errors. To see debug only info, people should set `openpgp.loglevel` to `All`.
Differential Revision: https://phabricator.services.mozilla.com/D205423
--HG--
extra : rebase_source : f5399a64a9b0bfc18a60e89f9e1faf51f9ea0410
extra : amend_source : f87ec4551da5615a96bce2a0b23548b4a15077fa
After recent linter changes, these are reported as
`'context' is assigned a value but never used. (no-unused-vars)`
Differential Revision: https://phabricator.services.mozilla.com/D205453
--HG--
extra : moz-landing-system : lando
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
This patch checks all calls of browser.menus.create() and makes sure
the menu creation is correctly awaited, before the test continues.
I identified the following as the main reason for the observed
intermittent fails: Even though the event listeners for the contextmenu
events have been successfully added to the element inside the shadow
DOM, they are not active immediately. One can observe the original
context menu being opened, which should not happen. I did not find an
event to wait for, which properly checks this. I therefore use a small
delay.
Differential Revision: https://phabricator.services.mozilla.com/D205191
--HG--
extra : amend_source : d5d0411d8dccd0dc75c498ca761146338ded10ae
The open/close Promises of PrintUtils are not returned from the m-c
component and are not accessible. The only access handle I could find is
the browser itself. Attaching the two callback methods is a very simple
solution, but is it any good?
This patch locks the composer (for example menus, action buttons
and commands) while the print preview modal dialog is shown.
Differential Revision: https://phabricator.services.mozilla.com/D204553
--HG--
rename : mail/components/extensions/test/browser/browser_ext_compose_onBeforeSend.js => mail/components/extensions/test/browser/browser_ext_compose_printPreview.js
extra : amend_source : e78f88df767abe3ed7a285bb11953c063a44e1f0
This is a possible implementation for the icon of popups. These are only
supported by Windows.
On Windows, all popups currently use the Thunderbird logo icon. Since
popups do not have a URL bar, it is not discoverable which popup is
opened by which add-on (they usually open moz-extension:// urls, which
point to pages within the add-on).
For the menus API we have the rule, that the icon used in context menus
is always the add-on icon, so that the user is able to identify which
menu entries are created by which add-on. We could follow the same
principle and force popups to use the add-on icon.
To see the patch in action, you can install one of the recommended
add-ons, for example the "Mail Merge Add-on" or the "Auto Adress
Cleaner" from the list of recommended add-ons and then click on the gear
icon inside AMO and select "Debug Add-ons". On the new page click the
"Inspect" button of the installed add-on and switch to the console tab
and enter:
`browser.windows.create({url:"https://example.com", type:"popup"})`
This patch is not allowing to use arbitrary icons, but enforces the one
defined in the manifest of the extension. It uses the Thunderbird logo
icon, if the add-on did not specify an icon in its manifest.
Differential Revision: https://phabricator.services.mozilla.com/D204270
--HG--
extra : moz-landing-system : lando
**How To Test**
- Open thunderbird. Use your find function and ensure findbar shows up and works.
- Switch to a multimessageview. Use your find function and ensure findbar shows up and works.
- Switch between message view and multimessageview to ensure that find bar is not overlapping or confusing browsers.
Differential Revision: https://phabricator.services.mozilla.com/D203217
--HG--
extra : moz-landing-system : lando
The pref removal is a port of bug 1705440. Everything else is dead code.
Differential Revision: https://phabricator.services.mozilla.com/D205141
--HG--
extra : amend_source : 2c201c8ffbba571c54b3ffac250c321fa056efd6
This is a continuation of the effort started in D204760: Switching to
BrowserTestUtils.waitForPopupEvent() instead of waiting for
`popuphidden` and `popupshown` events. It uses this general syntax:
```
await BrowserTestUtils.waitForPopupEvent(menu, "shown");
// Do something that should hide the menu.
await BrowserTestUtils.waitForPopupEvent(menu, "hidden");
```
or
```
await BrowserTestUtils.waitForPopupEvent(menu, "hidden");
// Do something that should show the menu.
await BrowserTestUtils.waitForPopupEvent(menu, "shown");
```
The main goal is to get rid of the artificial setTimeouts. This patch
also removes duplicated code and adds javadoc descriptions to the
touched functions.
Differential Revision: https://phabricator.services.mozilla.com/D205027
--HG--
extra : amend_source : 29a92fda9a687016f68009e4e4ba5152f14608dd
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
I only verified places where *writing* caused log spam, which was
resolved. But I added new log spam during read, because the empty value
is not parsable. The parsing error is caught and reported, not causing any
fails, but still needs to be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D204901
--HG--
extra : amend_source : 1445f51dcf13afdfb21a816d4a416b74419c866b
I see a lot of warnings in the test logs, about this pref storing way to
much data (since we install a lot of different test extensions).
Clearing the pref after each test gets rid of those warnings.
Depends on D204860
Differential Revision: https://phabricator.services.mozilla.com/D204861
--HG--
extra : moz-landing-system : lando
I observed intermittent fails and think we should reduce the chance of
these fails happening by enabling this preference. To not cause unwanted
side effects, let us enable them only in specific tests, not in all
tests.
Depends on D204761
Differential Revision: https://phabricator.services.mozilla.com/D204860
--HG--
extra : moz-landing-system : lando
Another reason why this type of test could fail: We are not waiting till
the popup is closed but use a timeout.
This patch uses the helper `closeBrowserAction()` in all places,
which waits for the "popuphidden" event.
It also increases readability by using the named event "popup closed".
In the `browser_ext_browserAction_popup_focus.js` test, the
wait-for-closed logic is moved from the extensions background to the
test itself, because it is much more stable this way.
Differential Revision: https://phabricator.services.mozilla.com/D204761
--HG--
extra : moz-landing-system : lando
We know we have issues with clicks on menu items and hiding menu popups
in the WebExtension tests. We currently mitigate these issues not only
in header files, but also directly in tests, and we also still have
places which are not using the mitigation (which could be the reason for
this intermittent).
While I still attempt to find the underlying cause for these issues,
this patch tries to unify the mitigation.
1. Use the helper `clickItemInMenuPopup()` instead of manually calling
`menu.activateItem()` in the tests themselves. The helper waits for the
"popupHidden" event, which was not waited for in all places.
2. Use the helper `closeMenuPopup()` instead of manually calling
`menu.hidePopup() in the tests themselves. The helper waits for the
"popupHidden" event, which was not waited for in all places.
3. The function `closeContextMenu()` has been renamed to
`closeBrowserContextMenuPopup()` and no longer accepts a menu
parameter, but is now used only for the browserContext menu. If
a specific menu should be closed, `closeMenuPopup()` should be used.
4. The function `closeExtensionContextMenu()` has been renamed to
`clickItemInBrowserContextMenuPopup()`, which better describes what it
does.
Differential Revision: https://phabricator.services.mozilla.com/D204760
--HG--
extra : moz-landing-system : lando
Remember the last selected item when changing view sorting, or showing/hiding passwords in an
unfiltered view.
Differential Revision: https://phabricator.services.mozilla.com/D204515
--HG--
extra : amend_source : f6405f878c3cf2981be8a6bfda066f43bbf8d875
Currently add-on developers try to do manual parsing, which is error
prone. It is true that they could load a third party library, but
exposing this makes it so much easier.
Differential Revision: https://phabricator.services.mozilla.com/D204490
--HG--
extra : amend_source : eac1c6ffe0efa666752eab2ef26119738056515f
This API will be populated with utility methods useful for extension
developers. The main goal is to be consistent across add-ons and not
forcing add-ons to re-invent methods which already exist in Thunderbird.
If Thunderbrid decides to change the output of these functions, all
add-ons using them will automatically be adjusted as well.
Differential Revision: https://phabricator.services.mozilla.com/D204473
--HG--
extra : amend_source : cfb3e0c93ed9e20f65bb026ca5566d834d5fd253
It looks like the close Cancellation/rejection happens earlier now.
Differential Revision: https://phabricator.services.mozilla.com/D204477
--HG--
extra : amend_source : 846bd45d642f7c8b938a9a5961181c7440449073
This fixes a regression introduced 3 years ago in Bug 1719985. If the
compose window has lots of text and is scrolled to the bottom, the
context menu will not have all entries and the spellchecker throws:
```
can't access property "ownerGlobal", element is null
```
According to MDN, `elementFromPoint()` needs coordinates relative to
the view port, but it currently gets coordinates relative to the document.
Differential Revision: https://phabricator.services.mozilla.com/D204518
--HG--
extra : amend_source : 12a0ec6a91b72d62d598d8f292dafdae2b50e3cb
This is a continuation of the effort started in D202887. Here we add
tests to verify the composer elements being correctly locked and
unlocked again.
The following still incorrect cases are fixed:
- the spelling button is now correctly locked
- action buttons are now correctly locked
Differential Revision: https://phabricator.services.mozilla.com/D203940
--HG--
extra : amend_source : fce46a5adc2aa8535e1f0df6477749fb1145ef3d
MacOS seems to use the `checked` attribute instead of the `selected` attribute for
menu items. This patch extends the existing CSS rule to act on both. It also loads
the `icons.css` and `colors.css` into the extension popup.
Differential Revision: https://phabricator.services.mozilla.com/D204363
--HG--
extra : amend_source : 807d0cc14bf8faad696f5d8c4c1af672d23f8ca9
This adds a test which was forgotton in Bug 1545932 and has been
regressed by Supernova changes. The regression itself has already been
fixed elsewhere in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D204148
--HG--
extra : amend_source : 8ec2a5b501da08fdc94a79c09daaecaaee056c3a
Instead of trying to check the new value after the theme has been
applied (which does not always work), we now simply wait *until* the
value has changed.
Differential Revision: https://phabricator.services.mozilla.com/D204341
--HG--
extra : amend_source : d54269c9a514acfb7114ff22138daeb01ae10166
The way jsmime.js and jsmime.jsm interacted did not work for esmification.
Make jsmime.js a proper module jsmime.mjs - remove the anchient module loading people use to use 15 years ago
before JavaScript had proper modules.
The interaction with extraMimeParsers.jsm was also problematic (loading it through Services.scriptloader.loadSubScript in jsmime.jsm),
and there's very little reason to use that in the first place these days. So inlined it into the jsmime.mjs module.
jsmime.js (now jsmime.mjs) uses a kind of namespacing that we could well get rid of but for keeing it was for now to keep the patch reviewable.
Will upload the patch first without formatting it, again to make it easeier to see the real changes.
There's a fair amount of linting fixing to be done even if they are not real changes...
Differential Revision: https://phabricator.services.mozilla.com/D204143
--HG--
rename : mailnews/mime/jsmime/jsmime.js => mailnews/mime/jsmime/jsmime.mjs
extra : rebase_source : d1c145bf779e58f550eb94f090f7be572b82b41e
When adding values to standard headers (like reply-to) via the compose
API, the row of their header field is automatically shown. This is
currently not the case for non-standard headers, which have been added
to the UI via the `mail.compose.other.header` preference.
This patch forces also non-standard headers to be shown, and adds a
test.
Differential Revision: https://phabricator.services.mozilla.com/D204157
--HG--
extra : amend_source : b9eedfa327fe8ff6e54b57a0f52300afceb2e2d6
The pref apperas not to exist. Because we didn't wait after clicking so the event handling didn't necessarily have time to safe the pref.
Differential Revision: https://phabricator.services.mozilla.com/D204190
--HG--
extra : amend_source : 0595ff3b069a9814b12f3763ba89bf0f25a1cda0
m-c finally wants to drop the `dom.disable_window_flip` preference in
Bug 1773079 and it will be permanently set to `true`.
It is currently set to `false` for us, but it does not look like
flipping it to `true` causes any issues.
Differential Revision: https://phabricator.services.mozilla.com/D204176
--HG--
extra : amend_source : 6a5d5485be3713665634857a2e74f958ff9c5be7
This patch sets `ui.prefersReducedMotion` in theme tests, to reduce
animations, which could delay theme updates.
Differential Revision: https://phabricator.services.mozilla.com/D204147
--HG--
extra : amend_source : 11581b23a430e47dd35b722b9176769c538b5280
Following feedback from developers, we remove the recommendation to
manually move messages to trash. Instead, developers should use the
standard `browser.messages.delete()` function, which honors the user's
trash settings.
Differential Revision: https://phabricator.services.mozilla.com/D204077
--HG--
extra : amend_source : 1b7ea551cff50620be932ad6a0282dec4e43bd6b
The attachment checker was doing some not quite ok things, and couldn't be converted to a standard module.
Fix the wrongdoings.
Differential Revision: https://phabricator.services.mozilla.com/D203740
--HG--
rename : mail/modules/AttachmentChecker.jsm => mail/modules/AttachmentChecker.worker.js
extra : rebase_source : 8cd0e035b571ddc349e3d7f9adbaa44fc58fdfcd
These messages are not usable and should not be touched by the API.
Differential Revision: https://phabricator.services.mozilla.com/D204060
--HG--
extra : amend_source : f74f4095830ef7beb4f1869c6c9448c78f2dabc0
We have an observer in `MailGlue.sys.mjs` for `chrome-document-global-created`,
to create a new instance of the `LightweightThemeConsumer` for each new
opened document.
This is not fired for the `messageBrowser`, which appears to be a
content document.
This patch makes sure we also create such an instance for the
messageBrowser. The patch also adds a test.
**The Bug itself has a reproducer add-on, showcasing the introduced
change by adding a border to all theme-able elements. Without this
patch, the message header area is not touched.**
Differential Revision: https://phabricator.services.mozilla.com/D204029
--HG--
extra : amend_source : 1f0f31a8492de603f71477d8a5376895ecf44e1b
This was almost fixed by D204029 already, but the image url itself has
changed as well (it is an image-set now).
Differential Revision: https://phabricator.services.mozilla.com/D204041
--HG--
extra : amend_source : a59234a8e607aff5bfa933acb8f7a3629e9ab75c
Historically the cookies popup didn't have a close button on macOS because (maybe) it was a standalone popup
dialog handled by the macOS titlebar and window decoration system independently.
Since this dialog is now (since 10 years) a modal dialog, it needs a close button as shown on Windows and Linux.
Differential Revision: https://phabricator.services.mozilla.com/D203810
--HG--
extra : amend_source : 18ed3617bd0f8c58f8b5d1c1f903899d21095091
In case mailnews.headers.extraExpandedHeaders contains a header we "know about" and have
already defined behavior for, use the preferred behavior.
E.g. set List-Archive into the pref - without this fix it shows as a plain filed, not as a link.
Differential Revision: https://phabricator.services.mozilla.com/D203898
--HG--
extra : amend_source : 3b507a7907f42d493dd211e833c12cda1af8a50f
Remove some of things that shoudn't really be logged.
Some usage were in try-catches that should not reasonably throw.
Upgraded many debug/logs to warn - when appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D203750
--HG--
extra : rebase_source : 73d8f0ba2ad7ebf0f82e71bed603f90e45dac0ce
extra : amend_source : 0824f75948689237cc7d49715a23603ce0f654a3
Issue #1: When the save or send button is clicked, many elements get
briefly enabled (for example the encryption button), instead of
disabling the currently enabled elements.
Issue #2: When the save button is clicked while the send button is
disabled, the send button gets permanently enabled.
Issue #3: Autosave enables some explicitly disabled elements after the
compose process has finished.
Issue #4: The help menu behaves very strange (first seen in
https://phabricator.services.mozilla.com/D168753)
This patch fixes these issues by only disabling items which have not yet
been acted upon (no longer messing up the logic by multiple calls to
`updateAllItems(true)`.
Furthermore, `updateAllItems(false)` no longer enables wrong items
(which was the cause for issue #2).
Even after spending a considerable amount of time on the help menu
issue, I was not able to get it re-enabled on macOS. I also do not
understand why the menu change in the composer has an effect in the
messenger window. I propose to skip the helpMenu element, its menuitems
still get disabled. This issue is handled in Bug 1883647.
Differential Revision: https://phabricator.services.mozilla.com/D202887
--HG--
extra : amend_source : 333122c87d1276476fec873546ef629fb395cca9
While writing a test for Bug 1862405, I realized that we cannot react on
auto saved messages/drafts. This adds the autoSave mode to the
onAfterSend event and adds a test which can be used for Bug 1862405 as
well.
Differential Revision: https://phabricator.services.mozilla.com/D203342
--HG--
extra : amend_source : b577d89ba2bab3f2723d4f71d030476006e2a1ee
If an add-on needs to set this header, I think it should be possible.
The only red line is modifiying real message headers, which are
controled by Thunderbird already. These headers should always be
modified through the appropriate APIs (ComposeDetails.returnReceipt or
ComposeDetails.deliveryStatusNotification).
If we get requests for a lot more headers which qualify to be
accessible, we might consider inverting the principle in the future and
keep a list of headers we do NOT want to be modified through the API.
This patch also adds protection for X-Mozilla-* headers from being
manipulated through the WebExtension API.
Differential Revision: https://phabricator.services.mozilla.com/D202815
--HG--
extra : amend_source : b3de693809dc9bda10f2dc2ec1afb33e757d5261
Richard Marti
welpy-cw
Magnus Melin
Vineet Deo
Geoff Lankow
John Bieling
Alessandro Castellani
Micah Ilbery
Ikey Doherty
Brendan Abolivier
Martin Giger
Sean Burke
solange valverde
Silvia Bonavista i Serrat
Alfred Peters
Rob Lemley
ISHIKAWA, Chiaki
Kai Engert
Mozilla Releng Treescript
Mark Banner