Last Comment Bug 461152 - Move Up/Down in Message Filters doesn't scroll selected filter into view
: Move Up/Down in Message Filters doesn't scroll selected filter into view
Status: VERIFIED FIXED
[gs]
: fixed-seamonkey2.0.3, regression
Product: MailNews Core
Classification: Components
Component: Filters (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Thunderbird 3.1a1
Assigned To: Kent James (:rkent)
:
Mentors:
http://gsfn.us/t/osdp
: 455799 497898 534380 538864 540549 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 07:00 PDT by Jim Reisert
Modified: 2010-04-12 00:40 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
-
.1-fixed


Attachments
ensure visible (2.62 KB, patch)
2009-12-29 16:37 PST, Kent James (:rkent)
mkmelin+mozilla: review+
standard8: approval‑thunderbird3.0.1+
Details | Diff | Splinter Review

Description Jim Reisert 2008-10-22 07:00:17 PDT
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 2008-11-26 11:44:05 PST
Confirmed on linux/trunk.
Comment 2 klonos 2009-05-06 15:46:56 PDT
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 2009-05-06 16:18:30 PDT
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 4 Ludovic Hirlimann [:Usul] 2009-06-13 07:20:36 PDT
*** Bug 455799 has been marked as a duplicate of this bug. ***
Comment 5 Ludovic Hirlimann [:Usul] 2009-06-13 07:22:43 PDT
*** Bug 497898 has been marked as a duplicate of this bug. ***
Comment 6 Kent James (:rkent) 2009-12-17 13:17:04 PST
*** Bug 534380 has been marked as a duplicate of this bug. ***
Comment 7 Kent James (:rkent) 2009-12-22 11:52:37 PST
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) 2009-12-29 16:37:55 PST
Created attachment 419498 [details] [diff] [review]
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 2010-01-03 11:23:35 PST
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) 2010-01-04 10:11:05 PST
Comment on attachment 419498 [details] [diff] [review]
ensure visible

Checked in http://hg.mozilla.org/comm-central/rev/57a3752779a0
Comment 11 Mark Banner (:standard8) 2010-01-05 04:40:18 PST
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) (:☕️) 2010-01-10 08:04:43 PST
Landed on 1.9.1 as <http://hg.mozilla.org/releases/comm-1.9.1/rev/12ee7b2efc8e>.
Comment 13 Kent James (:rkent) 2010-01-10 20:32:48 PST
*** Bug 538864 has been marked as a duplicate of this bug. ***
Comment 14 Ludovic Hirlimann [:Usul] 2010-01-12 04:52:16 PST
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 15 Kent James (:rkent) 2010-01-19 02:01:58 PST
*** Bug 540549 has been marked as a duplicate of this bug. ***
Comment 16 ISHIKAWA, Chiaki 2010-03-01 20:54:27 PST
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 2010-03-01 21:11:32 PST
>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 2010-03-01 21:16:59 PST
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) 2010-03-01 23:22:20 PST
(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 2010-03-02 02:52:37 PST
(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 2010-04-04 10:40:56 PDT
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) 2010-04-12 00:40:45 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.