Name Description Size Coverage
Bogofilter.sfd 352 -
components.conf 1611 -
DSPAM.sfd 287 -
Habeas.sfd 164 -
moz.build 1032 -
MsgTraitService.sys.mjs 5173 -
nsMsgBodyHandler.cpp 13380 -
nsMsgBodyHandler.h 3604 -
nsMsgFilter.cpp -*- Mode: C++; indent-tabs-mode: nil; c-basic-offset: 2 -*- 32404 -
nsMsgFilter.h priority to set rule to 3204 -
nsMsgFilterList.cpp 40264 -
nsMsgFilterList.h 2569 -
nsMsgFilterService.cpp 53126 -
nsMsgFilterService.h 1381 -
nsMsgImapSearch.cpp 74798 -
nsMsgLocalSearch.cpp 36692 -
nsMsgLocalSearch.h 3323 -
nsMsgResultElement.h 1471 -
nsMsgSearchAdapter.cpp void CurrentUrlDone (in nsresult exitCode); 36163 -
nsMsgSearchAdapter.h linked list of criteria terms 8452 -
nsMsgSearchBoolExpression.h CBoolExpression --> encapsulates one or more search terms by internally representing the search terms and their boolean operators as a binary expression tree. Each node in the tree consists of either (1) a boolean operator and two nsMsgSearchBoolExpressions or (2) if the node is a leaf node then it contains a search term. With each search term that is part of the expression we may also keep a character string. The character string is used to store the IMAP/NNTP encoding of the search term. This makes generating a search encoding (for online) easier. For IMAP/NNTP: nsMsgSearchBoolExpression has/assumes knowledge about how AND and OR search terms are combined according to IMAP4 and NNTP protocol. That is the only piece of IMAP/NNTP knowledge it is aware of. Order of Evaluation: Okay, the way in which the boolean expression tree is put together directly effects the order of evaluation. We currently support left to right evaluation. Supporting other order of evaluations involves adding new internal add term methods. 4713 -
nsMsgSearchImap.h 1454 -
nsMsgSearchNews.cpp 17794 -
nsMsgSearchNews.h 1849 -
nsMsgSearchScopeTerm.h 1365 -
nsMsgSearchSession.cpp 18932 -
nsMsgSearchSession.h Iterator index for m_listenerList/m_listenerFlagList. We used to use an nsTObserverArray for m_listenerList but its auto-adjusting iterator was not helping us keep our m_listenerFlagList iterator correct. We are making the simplifying assumption that our notifications are non-reentrant. In the exceptional case that it turns out they are reentrant, we assume that this is the result of canceling a search while the session is active and initiating a new one. In that case, we assume the outer iteration can safely be abandoned. This value is defined to be the index of the next listener we will process. This allows us to use the sentinel value of -1 to convey that no iteration is in progress (and the iteration process to abort if the value transitions to -1, which we always set on conclusion of our loop). 3140 -
nsMsgSearchTerm.cpp 58664 -
nsMsgSearchTerm.h Switch a string to lower case, except for special database rows that are not headers, but could be headers @param aValue the string to switch 3325 -
nsMsgSearchValue.cpp 3344 -
nsMsgSearchValue.h 768 -
PeriodicFilterManager.sys.mjs Execute periodic filters at the correct rate. The only external call required for this is setupFiltering(). This should be called before the mail-startup-done notification. 6355 -
POPFile.sfd 353 -
SpamAssassin.sfd 365 -
SpamCatcher.sfd 290 -
SpamPal.sfd 277 -