373075 - awkward scrolling in message filter window on move up/move down.

Status: RESOLVED WORKSFORME

(MailNews Core :: Filters, defect)

Description

[turningoff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10
Build Identifier: 

When you click move up or move down to set the place of a message filter, the window scrolls so that filter is at the bottom on the window.  This is somewhat awkward.  For example, maybe you have already adjusted the window so the filter is in the middle and you are aiming to move it some number of filters down, suddenly you can't see your goal because of the unasked for scrolling, so you have to watch the position like a hawk because you can no longer see the destination.  Clicking those buttons should not cause the window to scroll unless the action would move the filter out of the visible area of the window.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Cowperthwaite]

See also bug 193736.

Comment 2

[Ludovic Hirlimann [:Usul]]

XREF bug 461152

Comment 4

[Frederick Sieber]

Bug 594057 was called a duplicate of this bug, but it is NOT NOT NOT NOT!

This whole area needs reworking badly. 





If you have a lot of Filters, it is hard to find the one you want.  The only
organization option is a klutzy move individual filter up and down in the list.
 Now it scrolls incorrectly when you have reached the end of screen on move
up/down which terribly slows the process of moving Filters, which was already
unwieldy.  I used to used Alt-D with keyboard repeat to manually sort the
filters.  There should at least be a button for sorting the filters by name.  I
don't much care about order or executing the rules because collisions are rare.
 But being unable to organize messages in any way efficiently greatly reduces
the value of the whole feature.   There has been a request to have sort
capability on the filters for SIX YEARS! 

Reproducible: Always

Steps to Reproduce:
1. Have lots of filters
2. Tools, Message Filters
3. Try to find the one you want - Good Luck
4. Try to use klutzy move single filter up/down in list, in order to sort the
list manually.
5. After have moved the message to bottom of screen, extraneous incorrect
scrolling action, greatly slows your sorting process to the point where decide
to forget it.

Comment 5

[Frederick Sieber]

It appears that someone may have tried to fix this recently, and just made it a lot worse.   It has been a lot worse with the latest version 3.1.

Comment 6

[Wayne Mery (:wsmwk)]

your bug is almost certainly a duplicate. But perhaps you can find a better bug to duplicate it to from this list?
 https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&short_desc=organiz%20sort%20order%20hard%20scroll&type0-0-1=substring&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&short_desc_type=anywordssubstr&type0-0-0=substring&component=Filters&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird

Comment 7

[Frederick Sieber]

This is a good place for my problems.

1.  Have two screen fulls of filters.  After you have made the web page take up your entire display.
2.  Try to use  the Alt-D key to move the first line displayed to somewhere on on the second page full.  Say it started with Z and you want to alphabetically sort it to the bottom of the list.
3.  After you get to the second web page, every time you depress Alt_D the entire page is rescrolled.  So if there say 40 lines on the display, you have to wait for it to rescroll the entire page 40 times!

Needless to say if you have a lot of filters, to manually sort the list using move/up move/down is for all practical purposes IMPOSSIBLE.  At least I don't have that much patience.

This is just an elaboration on my previous complaints.  This bug renders the message filters USELESS for any one that has more that 20 filters.

Comment 8

[John David Galt]

This bug is a direct result of the fix for bug 461152, and I complained about it there at the time.

You might want to vote for bug 103684, which (I believe) is the simplest fix.

Comment 9

[Frederick Sieber]

UPdate for 3.1.5

AltU AltD works somewhat differently, but this bug remains.  If you keep the window small, it is somewhat less time consuming, but still unwieldy, awkward, VERY INCONVENIENT, VERY OUTDATED.    People should take more pride in their work. 
Why not lift the code from the bookmark tree on firefox?

Comment 10

[:aceman]

I can't see this problem today. Does it still exist?

Comment 11

[John David Galt]

TB now runs fast enough for me that the slowness of scrolling, as I complained about in bug 461153, is no longer perceivable.  However, the window still scrolls to put the bug you are moving at the bottom after each move.

But I would like to see this bug broadened (or a new one created) to include the entire problem in comment 7.  The filter interface ought to be made to work decently for those of us who use hundreds of filters.  I suggest at least adding "Page Up" and "Page Down" buttons, cut/copy/paste buttons (preferably using the same keyboard shortcuts as whatever operating system you are on), and a search function.  Ideally, drag-and-drop of filters should also be allowed.

I'm cross-posting this to bug 103684, which appears also to be motivated by the same general problem situation.

Comment 12

[:aceman]

There already are bugs open for all the issues you just raised. Please join them. See e.g. bug 668995, bug 450302, bug 214548.

Comment 13

[:aceman]

So bug 103684 is fixed now. Also other changes were made to the filter list. Can anybody still reproduce the original issue as reported in comment 0?

Comment 14

[John David Galt]

I'm now (TB 14.0) seeing most of the repaint operations skipped when a filter is being moved again and again rapidly.  This is faster and a big improvement, but the new current position does still wind up on the next-to-bottom line of the window, so I think comment 0, read narrowly, is still true.

I'm not seeing the bug 103684 fix yet, so maybe both fixes still only in nightlies and we should reserve judgment until it appears in a release.

Comment 15

[:aceman]

OK, bug 103684 is marked to be included in TB15.

Comment 16

[Phoenix]

Resovled per whiteboard and Comment 14