[Thunderbird] QuickSearchBar : custom search result

Andrew Sutherland asutherland at asutherland.org
Mon Aug 26 19:29:09 UTC 2013

(tb-planning is the best venue for questions like this since others may 
have better ideas and then everyone can benefit from any answers; 
replying there. Information on joining the list is available at 

On 08/26/2013 06:06 AM, Karim Gemayel wrote:
> I'm writing a Thunderbird extension, and as you wrote some code for 
> the Thunderbird Quick Search bar perhaps you could enlighten me.
> I'm looking to replace the result returned when a search query is done 
> with the Quick Search Bar.
> Looking at the code and .idl, I thought registering a search listener 
> with the event 'onNewSearch' and stopping the original search with 
> nsIMsgSearchSession.interruptSearch() would do the trick, and then 
> adding my own result using nsIMsgSearchSession.addSearchHit().
> interruptSearch() completely stops the search process, so I removed it.
> Now it works, my own search result is displayed, but the original 
> search result is also displayed.
> So, I'm wondering, how can I disable the display of the original 
> search and replace it with my own result ? I'd simply want to inject 
> my own result in place of the original one without modifying anything 
> else, specially without affecting observers and listeners notifications.

For clarity, I suspect you're talking about the quick filter bar; the 
"quick search" bar was present in Thunderbird 3.0 and earlier versions.

I don't think it makes sense to directly replace the quick filter bar's 
mechanisms.  If you are adding some type of additional filtering 
mechanism, you can contribute an additional filter via the 
quickFilterManager.  I made a blog post long ago on creating extensions 
that can be found here:

The source for the extension is now here:

But there are probably more interesting extensions to look at, 
especially if you want to more comprehensively alter the behaviour of 
the quick filter bar.  For example, alta88's "TotalQuickFilter" looks 
pretty amazing: 

If your goal is not to integrate with the quick filter bar, then you 
should probably do something like the global database's faceted search 
mechanism does when you select the "open email as list" option.  It 
creates a tab of type glodaList which then creates a GlodaSyntheticView 
instance which FolderDisplayWidget.show() knows how to use.  The list in 
question can then be further filtered by using the quick filter bar.

If your replacement search is using the global database, then it's 
really easy to do, open a glodaList tab.  Otherwise, because of the 
specialness of the 3-pane tabs' multiplexed implementation, it might be 
"easiest" to just call .show() on the current folder display widget with 
a synthetic message view implementation that you implement (look to 
GlodaSyntheticView for inspiration).  If your search is strongly 
associated with the currently displayed folder, you can probably get 
away with leaving the folder tree showing the current folder being 
selected, but you'd need a UI affordance to make it easy for the user to 
get back to the original contents of the folder without switching away 
and then back.  If your search is sufficiently different, you can 
probably create an artificial node in the folder tree.  If you are 
creating a new node, it might make more sense to hang a UI off of the 
global search box's extensible autocomplete mechanism instead.

Anywho, those are my thoughts.  Since you didn't explain your use case, 
I might be way off, but those approaches are more advisable than mucking 
around in the lower level internals of the 
FolderDisplayWidget/DBViewWrapper and interfering with the operation of 
the quick filter bar.  Please be sure to describe what your end goal is 
at a high level if any of this sounds problematic or there are nuances 
that you would like to discuss further.


More information about the tb-planning mailing list