615430 - Moving Message Filter rule down beyond screen does not scroll / follow said rule

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: General, defect)

Description

[Michael Lueck]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101008 Firefox/4.0b7pre SeaMonkey/2.1b1

I have a quite extensive set of Message Filter rules. I like to group the rules, and organize in alpha order. As such, I need to move new rules down into their proper spot when creating new rules. The SM UI in this screen does not follow selected new rule when it scrolls / is moved down past what rules are visible on the screen. Moving up/down beyond what is currently visible should cause an up/down scroll event to keep the Message Filter always visible.

Reproducible: Always

Steps to Reproduce:
1. Have a fairly extensive pre-existing Message Filter list, filling the screen
2. Move the top rule down beyond what rules are visible on the screen

Actual Results:  
Continue pushing down, it keeps going down but is out of site

Expected Results:  
When the filter rule reaches the bottom (or top going up) of the Filter Rule list, the scroll bar should auto-scroll to keep the in-focus Message Filter rule always visible.

Thunderbird 2.x UI works as expected. So this is a but specific to SM. I just migrated over from TB 2.x to SM.

Comment 1

[Michael Lueck]

Problem persists / confirmed into b2 release: Mozilla/5.0 (X11; Linux i686; rv:2.0b11) Gecko/20110209 Firefox/4.0b11 SeaMonkey/2.1b2

Comment 2

[Philip Chee]

Thunderbird Bug 461152 was fixed in TB 3.0.1 but was not fixed in SeaMonkey 2.0 despite the fixed-seamonkey2.0.3 flag there.

Comment 3

[Philip Chee]

Jens, you've tested the filter dialog before haven't you? Do you see this on trunk builds?

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

Confirming with trunk.

Comment 5

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: comment 9]

Unfortunately TB's code is quite different from ours here and I have little time, so I'm not assigning this to myself yet. If the simple solution I propose is not accepted, someone else will have to give it a try.

Comment 6

[Philip Chee]

Comment on attachment 513155 [details] [diff] [review]
patch [Checkin: comment 9]

> +
> +    if (gFilterTree.view.selection.count > 0)
If we are moving a filter at least one has to be selected.

> +      document.getElementById("filterTree").treeBoxObject
gFilterTree.

> +              .ensureRowIsVisible(gFilterTree.currentIndex);
>  }
This works right? I haven't tested this yet.

Comment 7

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #6)
> > +    if (gFilterTree.view.selection.count > 0)
> If we are moving a filter at least one has to be selected.
> 
> > +      document.getElementById("filterTree").treeBoxObject
> gFilterTree.

So true. I rushed it. Changed locally.

> > +              .ensureRowIsVisible(gFilterTree.currentIndex);
> >  }
> This works right? I haven't tested this yet.

I had a good moment and actually tried it before I uploaded it. :-P

Comment 8

[Karsten Düsterloh]

Comment on attachment 513155 [details] [diff] [review]
patch [Checkin: comment 9]

r/moa=me with Ratty's nit fixed.

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 513155 [details] [diff] [review]
patch [Checkin: comment 9]

http://hg.mozilla.org/comm-central/rev/c27f56222eaf
Nits address upon checkin.

Comment 10

[Michael Lueck]

Fix confirmed in SeaMonkey/2.1b3

Thank you!!! :-)