461152 - Move Up/Down in Message Filters doesn't scroll selected filter into view

Status: VERIFIED FIXED

(MailNews Core :: Filters, defect)

Description

[Jim Reisert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3

I have many filters (more than one window full).  When I use Move Down and the filter I'm moving scrolls down and out of the window, I'm now "flying blind" and I can't see where the filter is being moved to. I can find it using the scroll bar (but it's no longer highlighted) and select it again, but as soon as I "Move Down", the windows resets to the top of the filter list and I'm "flying blind" again.

Reproducible: Always

Steps to Reproduce:
See Details above
Actual Results:  
See Details above

Expected Results:  
Same as Thunderbird 2.0.x - window should scroll, "active" filter being moved should stay highlighted and visible.

Comment 1

[Magnus Melin [:mkmelin]]

Confirmed on linux/trunk.

Comment 2

[klonos]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090404 Lightning/1.0pre Shredder/3.1a1pre ID:20090419051533

I think bug 373075 is similar plus confirming on latest 3.1 nightlies.

In order to see this, you need to have enough filters to fill the listbox beyond its height and so that the scrollbar appears on the right side of the listbox. I think the bug's description should change to:

'Moving Message Filters Up/Down doesn't scroll *with* selected filter into view. Scrollbar resets to top of the listbox each time.'

... or something.

Comment 3

[klonos]

Some other bugs dealing with Message Filters dialog and the listbox that contains the filters:

Bug 358641 -  Allow drag and drop for message filters
Bug 363411 -  Message filters: Scroll position resets on filter name change
Bug 373075 -  awkward scrolling in message filter window on move up/move down (mentioned above).

All of then have to do with scrolling and positioning of the message filters.

Comment 7

[Kent James (:rkent)]

This regression from 2.0 should have been examined before release of 3.0  If fixed, it should go on the branch.

Comment 8

[Kent James (:rkent)]

Attachment: ensure visible

In addition to the bare minimum ensureElementIsVisible call, this cleans up a couple of other minor issues as well:

1) It keeps the scroll position rather than always just resetting it to the top after a filter move.

2) In multiple selection, after a filter move keyboard extension of selection was failing due to a caching issue in listbox.xml. We work around that here.

Comment 9

[Magnus Melin [:mkmelin]]

Comment on attachment 419498 [details] [diff] [review]
ensure visible

>+  // range at _selectionStart. The old value though is now obsolete,
>+  // since we will recreate all of the elements. We need to clear 

Please drop the "though".

There's a bit of jumping, but all in all it's still an improvement.

r=mkmelin

Comment 10

[Kent James (:rkent)]

Comment on attachment 419498 [details] [diff] [review]
ensure visible

Checked in http://hg.mozilla.org/comm-central/rev/57a3752779a0

Comment 11

[Mark Banner (:standard8)]

Whilst I can see the regression as an annoyance, the work around is simple and this doesn't actually break anything. Therefore not blocking a 3.0.x release, but is wanted. I'll consider the patch for approval later.

Comment 12

[Blake Winton (:bwinton) (:☕️)]

Landed on 1.9.1 as <http://hg.mozilla.org/releases/comm-1.9.1/rev/12ee7b2efc8e>.

Comment 14

[Ludovic Hirlimann [:Usul]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100110 Shredder/3.0.1pre

Comment 16

[ISHIKAWA, Chiaki]

I am afraid that this problem has returned in a somewhat subtle manner in the
latest 3.0.3.

I am using TB 3.0.x under linux (mostly Debian Gnu/Linux).

3.0.2 was OK

With 3.0.3,
running TB3 over LAN, TB3 running on a linux PC, and showing the display
on another X11 window, when I move down a filter, the re-display seems to work
very strangely: it is as if the item goes down the lower boundary of the
window pane, and suddenly the whole list is moved DOWN(!), not down, 
the upper portion becoming blank,
 (by block scroll) and then the whole screen is re-drawn from top to bottom (or
the lower portion is scrolled UP and the remaining is redrawn. The same effect.).
This is observable due to the delay/latency caused by LAN connection.

But the problem with the DIRECT draw where TB3.0.3 is used on the same machine
where the X console terminal is on the same machine
is very problematic and renders the filter down/up operation inoperative.
It is very difficult to explain, but the most similar symptom I could find
in this bugzilla is this 461152 and  "Bug 538864", Message Filters window - Using Up and Down buttons causes window to scroll to top, in that 
the scrolling shows 

I think it is a re-paint problem: there must be some logic (to miss the flushing the last paint operation somewhere.
The reason the symptom differs
from the SAME machine operation and REMOTE operation can be explained
by this IMHO.

Please note that the symptom is different on a remote usage and
local usage and testing under both conditions is necessary.

Also, the display driver (for local, direct rendering) may have something to do.
In both cases, I used ATI/AMD Radeon graphics adapter.

Comment 17

[ISHIKAWA, Chiaki]

>Using Up and Down buttons causes window to scroll to top, in that 
>the scrolling shows

I meant to write that the resulting scrolling goes back to the
original display in that the top-most filter is the FIRST filter and the
filter I was trying to move is no longer visible!

There seems to be a few other scroll (update problem).
I don't know if they are related, but they seem to point that the redisplay code 
may have some issues.

51836 Scrolling in Filter rules dialog too slow.

TIA

Comment 18

[ISHIKAWA, Chiaki]

Typo of the bug number. NOT 51836 -> 518305
 Bug 518305 -  Scrolling in Filter rules dialog is too slow
Summary: 	Scrolling in Filter rules dialog is too slow

Comment 19

[Mark Banner (:standard8)]

(In reply to comment #16)
> I am afraid that this problem has returned in a somewhat subtle manner in the
> latest 3.0.3.
> 
> I am using TB 3.0.x under linux (mostly Debian Gnu/Linux).
> 
> 3.0.2 was OK
> 
> With 3.0.3,

Please can you file this under a separate bug. Whilst it may seem like the same issue, this has been marked as fixed since .1.

I can also tell you that between .2 and .3 the only change in the Thunderbird source code was to correct Local Folders/Accounts from being lost from the display. Hence I very much doubt that your issue has returned as a result of the upgrade.

Comment 20

[ISHIKAWA, Chiaki]

(In reply to comment #19)
> 
>  [... snip ...]
> 
> Please can you file this under a separate bug. Whilst it may seem like the same
> issue, this has been marked as fixed since .1.
> 

I did:

 Bug 549577 -  TB 3.0.3 Move Up/Down in Message Filters doesn't scroll selected filter into view

> I can also tell you that between .2 and .3 the only change in the Thunderbird
> source code was to correct Local Folders/Accounts from being lost from the
> display. Hence I very much doubt that your issue has returned as a result of
> the upgrade.

Hmm, then possibly the problem with the upgrade of GUI middleware/X11 library, etc. under Debian GNU/Linux lately?
But I will follow this up in Bug 549577 

TIA

Comment 21

[John David Galt]

This fix is in TB 3.0, and as a result it is now VERY, horrendously slow to add a new filter to my list (and scroll it down the hundreds of lines to where it belongs) because TB now stops to repaint the list after every single one-line move.

Is there an option setting to delay the repaints until explicitly asked for (by a "refresh" button or similar)?  If not, please create it.

Comment 22

[Kent James (:rkent)]

I tested this with 100 filters on my slow XP system, and I was able to scroll the filter down about two lines per second. While not exactly speedy, I don't think that is unacceptable behavior.

The root cause of your issue is "scroll it down the hundreds of lines" which is done by selecting down hundreds of times. I would agree that is far from ideal, and so the filter list editor is really not very suitable for use for people with hundreds of filters. But I don't think that the correct solution is to reverse the fix of this bug.