User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1 Build Identifier: version 2 beta 2 (20070116) In the Message Filters window, after a filter has been selected, Clicking "Move Down" moves the selected filter down one slot and keeps the filter enabled. Typing Alt-D ("Move Down"'s keyboard accelerator) moves the selected filter down one slot but disables the filter. Reproducible: Always Steps to Reproduce: 1. Open the Message Filter window. (It's useful if you have more than 2 filters.) 2. Select a filter (left click) 3. Click on "Move Down". The selected filter moves down one slot and remains enabled. 4. Type Alt-D. Actual Results: The selected filter moves down one slot but is disabled. Expected Results: The selected filter should move down one slot and remain enabled. Moving a filter down through 30 or more filters is easier if I can hold down a key than clicking on a button 30 or more times. Please make the action for Alt-D the same as for clicking on Move Down. The accelerator should have the same action as the thing it's accelerating.

->NEW on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070126 Thunderbird/2.0pre ID:2007012603. Move up also seems to toggle state sometimes.

It's not a toggle, because the accelerator keys only disable the filters. I disagree with Magnus Melin's claim of this happening "sometimes". It happens every time the accelerator keys are used, whether the direction is up or down.

Ah, seems the toggle thing happens if the last filter is "enabled", you select it, and press Alt+D. (Well, pressing just any key will toggle it.) For me it seems ok sometimes, in some combination of using Alt+U (move up) first (?)

The original code wanted to check for a space key to toggle the enabled status, but for some reason just tested event.keyCode != 0. That made all accelerators/shortcuts match, which is not desirable. This patch replaces that with event.charCode != KeyEvent.DOM_VK_SPACE.

(In reply to comment #6) > This patch replaces that with event.charCode != KeyEvent.DOM_VK_SPACE. Strictly speaking DOM_VK_SPACE is a keycode, not a charcode...

(In reply to comment #7) > (In reply to comment #6) > > This patch replaces that with event.charCode != KeyEvent.DOM_VK_SPACE. > Strictly speaking DOM_VK_SPACE is a keycode, not a charcode... According to <http://developer.mozilla.org/en/docs/DOM:event.keyCode>, looks like for a keypress event (which is what is being trapped in this case), charCode should be used. But for a keydown or keyup event, keyCode should be used. Sounds like the safe route is to use the which member variable, so then you don't have to remember whether you're processing a keypress or a keydown/keyup message.

Comment on attachment 316364 [details] [diff] [review] Simple fix Thx for the patch. The method in question is named onFilterTreeKeyPress so I think it's ok to only consider keypress -> fine with the charCode here.

Patch checked in: Checking in mail/base/content/FilterListDialog.js; /cvsroot/mozilla/mail/base/content/FilterListDialog.js,v <-- FilterListDialog.js new revision: 1.16; previous revision: 1.15

Given that this is a one-line fix and the SeaMonkey counterpart seems to be identical (http://lxr.mozilla.org/seamonkey/source/mailnews/base/search/resources/content/FilterListDialog.js#647), maybe that part could be handled here as well?

probable dupe bug 274726

possible dup bug 313402 (see bug 313402 comment #2)

Bug 274726 is definitely a dupe, and I've marked it as such. Bug 323402 is no so clear. Initially someone was asking for sorting the list of filters for display purposes in order to find individual filters more easily. Then it got renamed for the bug that was fixed here. I think the original request is probably valid, although I think a better solution to finding filters is not sorting, but searching. Classic Eudora has a find inside the Filters window that I use fairly frequently.

(In reply to comment #15) > Bug 323402 Mistyped the bug number. That should have been bug 313402.

Fix on the SeaMonkey side. Continuing Magnus' r+ as the code is identical in both TB and SM. Now it's mailnews, though, so it needs sr.

(In reply to comment #18) > Created an attachment (id=323414) [details] > Same fix for SeaMonkey Checking in mailnews/base/search/resources/content/FilterListDialog.js; /cvsroot/mozilla/mailnews/base/search/resources/content/FilterListDialog.js,v <-- FilterListDialog.js new revision: 1.70; previous revision: 1.69

I'm not understanding something about the bug fix process. I'm the one who originally reported <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=395799">Bug 395799</a>, which was reported as a duplicate of this one. This one was marked "resolved" more than two months ago, but my bug still occurs even though several Thunderbird releases have come out since. Has this bug been included in a release? (I can't see any annotation that says so, but that may be either because it's automatic, or because there's further process before the status changes from "resolved" to "included in a release". Of course, the other possibility is that this bug is fixed, but the one I reported continues, even though they appeared to have the same cause. If I open a Message Filter window, select a filter, and then close the window with Cmd-W (I'm on a Mac), then the selected filter is disabled. This still happens in version 2.0.0.14.

(In reply to comment #20) > Has this bug been included in a release? > This still happens in version 2.0.0.14. The patch was applied to the trunk, so is only in 3.0 alpha versions. In general, the only types of changes going in to 2.x releases are security fixes and critical bugs.