User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040917 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040917 Firefox/0.9.3 If the number of message filters in the message filter dialog is longer than the size of the list widget, clicking the checkmark icon to enable or disable a filter will force the widget to scroll up to the top of the list. This isn't critical, but it makes enabling or disabling lots of filters (say, if you're changing to use the new Global Inbox) a real pain in the keester. Reproducible: Always Steps to Reproduce: 1. Open the Message Filters dialog (Tools -> Message Filters...) 2. If necessary, add enough filters so that the number of filters is greater than the size of the filters list widget, -OR- resize the dialog so that the list widget is smaller than the number of filters. 3. Scroll the list down. 4. Click the checkbox icon for some filter to disable it. Actual Results: The list widget scrolls back to the first entry. Expected Results: Redrawn the widget with the check removed, but with the same list entries showing.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

Bugfix is in the patch (from mail folder). Additional fixes in the patch: Moving filter up/down does not make it jump to the bottom of the visible area. Deletion of the filters does not make list jump to the top, but remain current position. If a new filter is added to the list, it always visible.

Comment on attachment 198932 [details] [diff] [review] patch to fix this bug and FilterListDialog UI improvement If there's an easier way of fixing this, I'm sure Neil knows about it :-)

Comment on attachment 198932 [details] [diff] [review] patch to fix this bug and FilterListDialog UI improvement The "easier" way of fixing this is to make the filter data source dynamic, so that the tree refreshes itself automatically :-P

Comment on attachment 198932 [details] [diff] [review] patch to fix this bug and FilterListDialog UI improvement >diff -u -r1.5 FilterListDialog.js -p would have been nice. > window.openDialog("chrome://messenger/content/FilterEditor.xul", "FilterEditor", "chrome,modal,titlebar,resizable,centerscreen", args); > > if ("refresh" in args && args.refresh) >+ { > refresh(); >+ >+ //filter is always placed on top, make sure it is visible >+ gFilterTree.treeBoxObject.scrollToRow(0); >+ } I think you should swap these around. >+function ensureSelectionIsVisible() ensureRowIsVisble should be able to do most of the work here (although you still need the -1 check). This should make the function so short that you don't need to write it out separately. It's a pity that ScrollToRow doesn't bounds-check its parameter, except in some edge cases.

Jan, apart from making updates dynamic do you have any other workarounds?

*** Bug 325401 has been marked as a duplicate of this bug. ***

this is still a problem. version 2.0.0.9 (20071031)

Comment on attachment 198932 [details] [diff] [review] patch to fix this bug and FilterListDialog UI improvement I tried patching this one to the latest trunk cvs, and it does apply cleanly, i.e. did not bit-rot. I think some progress can be made on a 2.5 year old outstanding patch review once the comments in comment #5 are addressed.

Comment on attachment 198932 [details] [diff] [review] patch to fix this bug and FilterListDialog UI improvement clearing requests, obsoleting - jminta's work in bug 422474 has fixed this - yay!

fixed by bug 422474

Removing bug 360488 dependency: I guess SM got fixed by its bug 436357... [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) I can reproduce with my usual profile. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081201 SeaMonkey/2.0a2pre] (nightly) (W2Ksp4) I can't reproduce with a new profile.

(In reply to comment #12) > Removing bug 360488 dependency: I guess SM got fixed by its bug 436357... That's right, I rolled the fix in there without even realising it ;-)