User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; de-de) AppleWebKit/528.1 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080914025345 Shredder/3.0b1pre If I do the "Steps to Reproduce" I get the following error in the Error Console: Error: menuItems[0] is undefined Source File: chrome://messenger/content/search.xml Line: 99 Line 99 is: << this.inputField.value = menuItems[0].getAttribute('label'); >> Reproducible: Always Steps to Reproduce: 1. Without quicksearch in the toolbar rightclick on the toolbar and choose "Customize..." 2. Drag quicksearch in the toolbar and click "Done". 3. Open Error Console 4. I closed Thunderbird after adding quicksearch to the toolbar. After restarting Thunderbird I'am now no more able to remove it from the toolbar.

Reproduced the error message. It actually appears as soon as one clicks "Customize" when the quicksearch is in the toolbar, not when/after removing it. I'm on it, preparing a patch. However, I could not reproduce being unable to remove it from the toolbar after restarting.

It is easy to make the error message disappear, by protecting the whole function body by a if (typeof(this.searchMode) != "undefined") but I believe that would only hide the true problem, which is that when the constructor (in the same file) is called when clicking on "customize", menuItems gets set to an array of the right length, but for some of the elements of the array, the value property is undefined, which leads to setting mQuickSearchMode to undefined, which all kinds of places in the code don't expect. The bad thing is that this happens also when *closing* the customization dialog, not only opening it. I tried to adapt the constructor to handling not having the value properties, but that is a no go, because it leads to a decoupling between the effectively active quicksearch mode and the checked radio choice in the menu! This whole sorry situation leads to e.g. that after opening the toolbar customization, changing nothing and clicking OK, the quicksearch will give "Search Exception" on the OS standard console (if you have dump() actived by setting browser.dom.window.dump.enabled to true), because searchMode is undefined. The extremely weird thing is that, if desiredQuickSearchMode at start-up is N, then on opening the customization dialog, for all elements of menuItems from the beginning to the element that should have value N, the value is undefined, and it is the right value for the ones after that. On closing the customization dialog, the value property of all of them is undefined. It is as if the mere reading of the value property by the constructor was cause for this value to disappear the next time the constructor is called: if one removes the "break" in if (menuItems[index].value == desiredQuickSearchMode) { selectedMenuItem = menuItems[index]; break; } then when the constructor is called on opening the customization dialog, all value properties are undefined. Similarly, if the for loop is changed into a descending (instead of ascending) for loop, it is all values _after_ the selected one that are undefined, the ones before that have the right value. The whole procedure can be recreated by clicking on "Restore Default Set" in the customize dialog; the constructor then gets called three times, first time with all undefined, then defined for all those it reads, then undefined for those it has read the second time, defined for the others. This may also be related to (as in have the same cause as) bug #453368, because when the situation arises, the selectedMenuItem.setAttribute('checked', 'false'); line makes the function abort without error message, hence not calling this.setSearchCriteriaText().

(In reply to comment #1) > I'm on it, preparing a patch. Do you have any patch in the meantime? Than I would volunteer to test it in my onwn build.

(In reply to comment #3) > (In reply to comment #1) >> I'm on it, preparing a patch. > Do you have any patch in the meantime? Than I would volunteer to test it in my > onwn build. Maybe I was not explicit enough in comment #2: I tried preparing a patch for this, I thought it would be rather easy, but I saw that the course for correcting this I had planned only creates other problems. In other words, I encountered problems that are bigger than my expertise, and need someone that knows XUL to look at it; there may be a deep XUL bug in there, or I misunderstand how it is supposed to work. I have documented my findings and analysis in comment #2, now it is back in the hands of the experts.

Can anybody reproduce the following? 1. Without quicksearch in the toolbar rightclick on the toolbar and choose "Customize..." 2. Drag quicksearch in the toolbar and click "Done" (you will get the error message). 3. Rightclick a second time on the toolbar and choose "Customize...". Remove the quicksearch and click "Done". 4. Restart Thunderbird. 5. Rightclick again on the toolbar and choose "Customize...". --> Now the opened menu is blank :-o 6. Restart Thunderbird and try Step 5. again. --> Now the opened menu isn't blank anymore. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081211 Thunderbird/3.0b2pre

Because I've also found this bug in Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 I've added it to the list for Bugs found in Beta 1.

I'm receiving the following warnings after adding quicksearch to the toolbar: 1) Warning: Timed textboxes are deprecated. Consider using type="search" instead. Source File: chrome://messenger/content/messenger.xul Line: 0 2) Error: menuItems[0] is undefined Source File: chrome://messenger/content/search.xml Line: 99 (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre)

I'm still receiving the Warning: Timed textboxes are deprecated. Consider using type="search" instead. Source File: chrome://messenger/content/messenger.xul Line: 0 with the build Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090218 Thunderbird/3.0b2. Shouldn't this be fixed in the final TB3.0b2?

No, nor is that this bug.

(In reply to comment #8) > I'm still receiving the Warning: Timed textboxes are deprecated. Consider using > type="search" instead. > Source File: chrome://messenger/content/messenger.xul > Line: 0 For this warning see Bug 451852 and its dependencies.

I don't see this anymore in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2pre) Gecko/20090724 Shredder/3.0b4pre but now I get an error if I try to remove quicksearch from the toolbar, Bug 506327

I have the same problem and for anyone who is interested I took a screen shot of my error console, it can be seen in my post on mozillazine. https://bugzilla.mozilla.org/show_bug.cgi?id=504552

-> WFM