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

VERIFIED FIXED in Thunderbird 3.1a1

Status

MailNews Core
Filters
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: Jim Reisert, Assigned: rkent)

Tracking

({fixed-seamonkey2.0.3, regression})

Trunk
Thunderbird 3.1a1
fixed-seamonkey2.0.3, regression

Firefox Tracking Flags

(blocking-thunderbird3.0 -, thunderbird3.0 .1-fixed)

Details

(Whiteboard: [gs], URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
Version: unspecified → Trunk

Comment 1

9 years ago
Confirmed on linux/trunk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Summary: Move Up/Down in Message Filters doesn't display properly → Move Up/Down in Message Filters doesn't scroll selected filter into view

Comment 2

8 years ago
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

8 years ago
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.
Duplicate of this bug: 455799
Duplicate of this bug: 497898
Component: General → Search
QA Contact: general → search
(Assignee)

Updated

8 years ago
Duplicate of this bug: 534380
(Assignee)

Updated

8 years ago
Component: Search → Filters
Product: Thunderbird → MailNews Core
QA Contact: search → filters
(Assignee)

Comment 7

8 years ago
This regression from 2.0 should have been examined before release of 3.0  If fixed, it should go on the branch.
Assignee: nobody → kent
Status: NEW → ASSIGNED
blocking-thunderbird3.0: --- → ?
(Assignee)

Comment 8

8 years ago
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.
Attachment #419498 - Flags: review?(mkmelin+mozilla)
(Assignee)

Updated

8 years ago
Whiteboard: [needs r mkmelin]
(Assignee)

Updated

8 years ago
Target Milestone: --- → Thunderbird 3.1a1

Comment 9

8 years ago
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
Attachment #419498 - Flags: review?(mkmelin+mozilla) → review+

Updated

8 years ago
Whiteboard: [needs r mkmelin] → [has r]
(Assignee)

Comment 10

8 years ago
Comment on attachment 419498 [details] [diff] [review]
ensure visible

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

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Attachment #419498 - Flags: approval-thunderbird3.0.1?
(Assignee)

Updated

8 years ago
Whiteboard: [has r] → [needs 3.0 approval]
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.
blocking-thunderbird3.0: ? → -
status-thunderbird3.0: --- → wanted
Attachment #419498 - Flags: approval-thunderbird3.0.1? → approval-thunderbird3.0.1+
Landed on 1.9.1 as <http://hg.mozilla.org/releases/comm-1.9.1/rev/12ee7b2efc8e>.
Whiteboard: [needs 3.0 approval]
status-thunderbird3.0: wanted → .1-fixed
(Assignee)

Updated

8 years ago
Duplicate of this bug: 538864
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100110 Shredder/3.0.1pre
Status: RESOLVED → VERIFIED
Keywords: verified-thunderbird3.0
(Assignee)

Updated

8 years ago
Duplicate of this bug: 540549
Whiteboard: [gs]

Updated

8 years ago
Keywords: fixed-seamonkey2.0.3

Comment 16

8 years ago
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

8 years ago
>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

8 years ago
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
(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

8 years ago
(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

8 years ago
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.
(Assignee)

Comment 22

8 years ago
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.
You need to log in before you can comment on or make changes to this bug.