Remove needless constants for nsMsgFolderFlags

RESOLVED FIXED in Thunderbird 65.0

Status

enhancement
--
trivial
RESOLVED FIXED
9 months ago
9 months ago

People

(Reporter: aceman, Assigned: aceman)

Tracking

Trunk
Thunderbird 65.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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 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
Attachment #9021697 - Flags: review?(jorgk) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/86c5e6686ff3
Remove needless constants for nsMsgFolderFlags. r=jorgk DONTBUILD
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 65.0
(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.
You need to log in before you can comment on or make changes to this bug.