1503734 - Remove needless constants for nsMsgFolderFlags

Status: RESOLVED FIXED

(Thunderbird :: General, enhancement)

Description

[:aceman]

Now that 'Components.interfaces' can be globally used as 'Ci', some constants in JS used to just make expressions shorter can now be dropped.

I kill constants for nsMsgFolderFlags here.

Comment 1

[:aceman]

Attachment: 1503734.patch

Try run:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=2c959b7a215ae9ad9806235e90be80a4d6be5713

Comment 2

[Jorg K (CEST = GMT+2)]

Comment on attachment 9021697 [details] [diff] [review]
1503734.patch

Review of attachment 9021697 [details] [diff] [review]:
-----------------------------------------------------------------

I lot of churn here :-(

::: mail/base/content/mailContextMenus.js
@@ +301,2 @@
>    if (!MailServices.mailSession.IsFolderOpenInWindow(folder) &&
> +      !(folder.flags & (Ci.nsMsgFolderFlags.Trash | Ci.nsMsgFolderFlags.Inbox)))

So that can't be
folder.getFlag(Ci.nsMsgFolderFlags.Trash | Ci.nsMsgFolderFlags.Inbox);

::: mailnews/base/content/folderProps.js
@@ +250,5 @@
>      var glodaCheckbox = document.getElementById("folderIncludeInGlobalSearch");
>      var glodaEnabled = Services.prefs
>        .getBoolPref("mailnews.database.global.indexer.enabled");
> +    if (!glodaEnabled || (gMsgFolder.flags & (Ci.nsMsgFolderFlags.Queue |
> +                                              Ci.nsMsgFolderFlags.Newsgroup))) {

and here

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/86c5e6686ff3
Remove needless constants for nsMsgFolderFlags. r=jorgk DONTBUILD

Comment 4

[:aceman]

(In reply to Jorg K (GMT+2) from comment #2)
> >    if (!MailServices.mailSession.IsFolderOpenInWindow(folder) &&
> > +      !(folder.flags & (Ci.nsMsgFolderFlags.Trash | Ci.nsMsgFolderFlags.Inbox)))
> 
> So that can't be
> folder.getFlag(Ci.nsMsgFolderFlags.Trash | Ci.nsMsgFolderFlags.Inbox);

Yes, possibly. But that defeats the purpose of the conversion to .getFlag(). Manipulating the flags like this or the '.flags & <flag>" checks or the monstrosity of ".flags &= ~<flag>" assume the internal representation of the flags (that it is a bitfield inside a single uint32_t) and thus lock it that we can't change it and e.g. add new flags. See https://dxr.mozilla.org/comm-central/source/comm/mailnews/base/public/nsMsgFolderFlags.idl#6 .
I think we should just forbid getting .flags directly, but that is maybe impossible due to addons.
But then why do we even have .getFlag(), .setFlag(), .clearFlag(), if there is direct manipulation by .flags?

So I didn't touch places where it does not make sense yet or where I didn't need to add 'Ci.'. So some 'flags & <flag>' are left.