User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081116 Firefox/3.1b2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081117 Thunderbird/3.0b1pre If there is some space left below the last folder in the folder pane, hovering this free space results in a small (here on Linux: 8x8 px) empty tooltip being shown. First time seen in the 2008-11-13 Shredder nightly, possibly a regression from <http://hg.mozilla.org/comm-central/rev/1de58e1d7549> in the Bug 414038. Reproducible: Always Steps to Reproduce: 1. Make Thunderbird window high enough or collapse the folder tree to get free space below the last folder in the tree. 2. Hover this free space of the folder pane. Actual Results: An empty tooltip appears. Expected Results: No tooltip.

Can't set the regression keyword because my Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081116 Firefox/3.1b2pre reproducibly crashes when entering more than two letters into the "keyword" form... :-O

I can confirm this. Until build 20081112 all OK. Beginning with build 20081113 I see this empty tooltip.

The reproducible crash while filling the "Keywords" form has gone with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081117 Firefox/3.1b2pre, thus allowing me to set the regression keyword.

Confirming, myself for Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b2pre) Gecko/20081117 Shredder/3.0b1pre nightly, also seen on Mac per bug 465595, and further reports for Windows XP.

It seems this bug is being caused by the bottom two folders, of the first mailbox entry, being (for whatever reason) set to the wrong encoding type. I have four accounts, and the first one in the list showed "Arabic (IBM-864)" character encoding for the "Sent" and "Trash" folders. You can access this setting by right-clicking either folder and selecting Properties... When I tried to correct the problem by changing encoding for the "Sent" folder to "Western (ISO-8859-1)" (i.e. matching the other folders that are set correctly), clicking OK would not work. I had to perform the modification on the "Trash" folder and, though clicking OK still seemed not to work, it corrected the setting for both "Sent" and "Trash" folders. Now everything is fine and the blank tooltip is gone.

(In reply to comment #6) > It seems this bug is being caused by the bottom two folders, of the first > mailbox entry, being (for whatever reason) set to the wrong encoding type. > > [...] When I tried to correct the problem by changing encoding for the > "Sent" folder to "Western (ISO-8859-1)" [...], clicking OK would not work. > I had to perform the modification on the "Trash" folder and, though clicking > OK still seemed not to work, it corrected the setting for both "Sent" and > "Trash" folders. > > Now everything is fine and the blank tooltip is gone. Can't confirm this workaround. The default character encoding for all folders of all my e-mail and newsgroup accounts was always set to ISO-8859-1; no effect on the empty tooltip in the folder pane changing it back and forth either.

My mistake. My steps work only for the empty tooltip showing up for folders. It does not eliminate the one associated with the blank space at the bottom. However, since the empty tooltip shows up for folders when Thunderbird incorrectly selects the first (and in my case, wrong) character encoding type from the list, it would not surprise me if that is what is in fact happening -- even though there is no text there. In that blank space, maybe there's a null string, that the incorrect character encoding is clobbering, and making it appear as though there is a tooltip? Just a thought.

(In reply to comment #8) > My mistake. My steps work only for the empty tooltip showing up for folders. > It does not eliminate the one associated with the blank space at the bottom. Yes, the empty tooltip for the folders themselves would be different from what is discussed here, and has been reported for builds before bug 414038 landed already. I've played with several character-set options without being able to get rid of it below the space occupied by the folders.

Somebody at mozillazine mentioned corrupted/unrebuilt .msf files as culprit for this bug: http://forums.mozillazine.org/viewtopic.php?f=29&t=945395&st=0&sk=t&sd=a&start=15

Given the regression window, should be fallout from bug 414038. <http://hg.mozilla.org/comm-central/pushloghtml?startdate=2008-11-12+03%3A00%3A00& enddate=2008-11-13+03%3A00%3A00>

Seems to do the trick.

Comment on attachment 353150 [details] [diff] [review] Fix v.1 + if (gFolderTreeView._rowMap[row]) I'm inclined to say this should be row in gFolderTreeView._rowMap but I don't have strong preferences. + return gFolderTreeView._rowMap[row]._folder; + return false; We should return null, not false.

Good thing I was in the right place, with both of my two lines being wrong :) Pushed the right thing in http://hg.mozilla.org/comm-central/rev/79fb05dfc64b

This FIXED bug is flagged with in‑testsuite? It would be great if assignee or someone else can clear the flag if a test is not appropriate. And if appropriate, create a test and plus the flag to finish off the bug.

added under https://litmus.mozilla.org/show_test.cgi?id=7722