374561 - [Bad UI] Sidebar vscroll jumps to "current focused entry" when split pane is resized.

Status: RESOLVED DUPLICATE of bug 257704

(Thunderbird :: Mail Window Front End, defect)

Description

[Taisuke Yamada]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 1.5.0.10 (20070221)

When I resize split pane to find newsgroup (or any other "mailbox") by name, scrollbar position of the sidebar always jumps back to where current focus is set.



Reproducible: Always

Steps to Reproduce:
1. Register enough mailbox/newgroups/RSS entries/... so scrollbar appears/needed to see all (I have around 500 entries).
2. Select top entry in the list
3. Scroll down to last entry
4. Resize sidebar

Actual Results:  
Scrollbar jump back to top entry position.


Expected Results:  
Scrollbar position should have never changed.


This UI behavior is really problematic, because you never expect current *vertical*-scrolling viewport to change when you only change *horizontal* width of the area.

Practically, this is problematic in following use-case:

1. After reading email, I decided to check newsgroup "gmane.network.flow-tools.user". So, I start scrolling down to find one.
2. Due to automatic abbreviation, I can only find lots of "gmane....user" group, which is quite useless. So, I decided to resize a little, 
3. [PROBLEMATIC UI] Scrollbar immediately jumps back to the top, because current focused entry is the "Inbox" at the top. Feeling disturbed, I start scrolling down again.
4. Now, I find several "gmane.networ..l.user" groups. To see exact name, I do a resize again.
5. [PROBLEMATIC UI] Again, scrollbar immediately jumps back to the top. Feeling really disturbed, I start scrolling down again.

So the issue is that horizontal-width resizing affects vertical viewport position unexpectedly. Since the purpose of horizontal-width change is to see more complete horizontal-view of currently "shown entries", jumping back to
"focused entry" instead of keeping "shown entries" is a bad idea.

I can "workaround" it by always scrolling down again, but this violates rule of least surprise, and I report this as an UI-level bug.

Comment 1

[Taisuke Yamada]

Another workaround is to select anything in current viewport prior to resizing. But that's an awkward operation as in this case, the goal of resizing is to find out which one to select. So it's currently requiring selection for resizing for selection.