515803 - [faceted search] After customizing toolbar, entering a search term opens multiple results tabs on clicking "Messages mentioning..." autocomplete drop-down

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Simon Paquet [:sipaq]]

Attachment: JS errors caused by faceted search

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090910 Shredder/3.0b4pre

Steps to reproduce:

1. Select a folder
2. Type in a word in the new search textbox
3. wait for the popup "messages mentioning $word$" to open
4. Select "messages mentioning $word$"
5. press enter

Actual Result:
Five instances of faceted search open

Expected Result:
One instance of faceted search opens

There's lots of stuff in the error console, which is why I'm attaching those here, to not make the bug description unreadable.

Comment 2

[Wayne Mery (:wsmwk)]

I just got 16 tabs by typing in starred, killing that result, then typing "star". Pretty clean profile, one imap account. self build from early thursday morning. includes calendar

Comment 3

[Kirk M]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090910
Shredder/3.0b4pre

In another similar test without selecting any particular folder, I ran a "Search everything" test using 3 different terms that I knew were common in messages but not in all my accounts:

Accounts: 3 POP accounts and 6 IMAP Gmail accounts - all logged in.

In all 3 tests, each using a different term and selecting "Messages mentioning $word$", 7 additional tabs opened each with the duplicate results.

However, running the same 3 tests again and just hitting "Enter" instead of "messages mentioning $word$", produced only a single tab showing the results of each search.

In the Nightly builds threads on the forum there was a suggestion that each separate tab generated when selecting "messages mentioning $word$" from the drop down menu might be equal to the number of accounts in the sidebar. In my tests I found that wasn't the case nor does it seem to be tabs generated only from IMAP and not POP accounts (see types of accounts above).

Note: Ran same tests after updating to today's nightly build: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090911 Lightning/1.0pre Shredder/3.0b4pre ID:20090911031354

Same results with the exception that there's only 3 search results tabs being generated instead of 7.

Comment 4

[David Ascher (:davida)]

This is peculiar.  I wonder if it's a Windows-only thing?

Comment 5

[Phil Ringnalda (:philor)]

At first, I thought it was a gp-bugzilla thing, since I saw it (on OS X), disabled extensions until I got to that, no longer saw it, pulled one changeset for gp-bugzilla (without looking at what it was), reenabled, and no longer saw it. Then I thought it was a first-run thing, since I saw it at work where I don't have gp-bugzilla installed, and it went away by just closing and reopening.

Comment 6

[Kirk M]

Okay, same here (thought I checked that before) and will have to check again tomorrow when the I update to the next nightly build. Updating to a nightly build, trying a "Search everything" and choosing "messages mentioning $word$" will bring up several redundant tabs of search results but closing Shredder and restarting corrects the problem.

This is peculiar since updating to the next nightly build requires a mandatory restart anyway. Could it be that the this new feature isn't being fully incorporated during the required restart and another close/reopen finishes the job? That might explain all the Error console call outs? Just a thought.

I'm running Windows 7 RC by the way. Unfortunately I ditched Ubuntu 9.04 in order to test Win7.

Comment 7

[Simon Paquet [:sipaq]]

Weird, with the same build and the same profile that I reported this bug yesterday, everything works now as expected. The JS errors are still there, so I guess they are not really related.

This could really be a first-time update thing.

One additional note:
I had gloda already enabled in my regular TB nightlies from ftp.mozilla.org before faceted search landed. Could this be the reason for this?

Comment 8

[David Ascher (:davida)]

Asuth fixed some bugs having to do with the upgrade-to-faceted search phase, so this  _could_ be fixed, but it'd be good to have someone able to reproduce it on demand with today's nightly.

Comment 9

[David Ascher (:davida)]

moving up to b4 until we can assess the impact

Comment 10

[David Ascher (:davida)]

If someone can repro this reliably, ideally w/ a dev build, let me know, I may have some debugging questions.

Comment 11

[Wayne Mery (:wsmwk)]

when I got my "16 tabs" (is that like 16 candles?) I repro more than once. but I can no longer pro. including a couple tries at a new profile and build from ~2 hr ago :(

Comment 12

[David Ascher (:davida)]

We seem to have narrowed it down to the following STRs:

1) customize toolbar
2) make some changes
3) finish that

-> autocomplete-driven searches result in multiple tabs.

The analysis is that the customization code is creating the searchbar widget mutliple times, and its constructor registers an observer for "autocomplete-did-enter-text", but its destructor doesn't. 

I'll see about a patch shortly.

Comment 13

[David Ascher (:davida)]

Attachment: workaround

This is a workaround.  The right thing would be to just have the bit in the destructor, but for reasons that I explain in the patch, that's not reliable (or reliably doesn't work in the customize-toolbar path)

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 400181 [details] [diff] [review]
workaround

r=dmose

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Checked in: <http://hg.mozilla.org/comm-central/rev/d68aac628509>.