Scrolling/jumping to next message in threadPane works very unfavorably because selected message is the first or last line

RESOLVED FIXED

Status

Thunderbird
Mail Window Front End
--
enhancement
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: MartinP, Assigned: asuth)

Tracking

Bug Flags:
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b3ux][see comment #39])

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 Firefox/2.0.0.6
Build Identifier: version 2.0.0.6 (20070802)

Going to the next unread message (key N) will sometimes scroll the threadPane.  If going forward this will always show the next active message in the last visible line.

This behavior is very unfavorably as it hinders further sight onto message subjects directly after the selected message.  However, this is the moving direction for the next N.

Instead of showing the new message subject in the last visible row, it should be shown in the middle or beginning of the visible area of the threadPane.

"Sylpheed" and "Claws-mail" do it right.

Reproducible: Always

Steps to Reproduce:
1. Go to a folder with several unread messages
2. Select a message far above the unread ones
3. Hit N or Menu/Go/Next/Unread Message

Actual Results:  
The active message will now be shown in the last visible row, so you cannot see whats next.

Expected Results:  
The active message should be shown in the first or middle visible row, so you can see whats next (the subjects of the next messages).

This behavior hinders fast processing of high-volume "mailing list" / spam folder, where one typically just reads over the subjects and hits N very often.
(Reporter)

Comment 1

11 years ago
Created attachment 275659 [details] [diff] [review]
Proposed solution

Comment 2

11 years ago
Comment on attachment 275659 [details] [diff] [review]
Proposed solution

Neil might have some useful suggestions here...
Attachment #275659 - Flags: superreview?(bienvenu)
Attachment #275659 - Flags: review?(neil)

Comment 3

11 years ago
Comment on attachment 275659 [details] [diff] [review]
Proposed solution

>+        tree.treeBoxObject.scrollToRow(index - page / 4);
So when you move off the bottom you actually jump to 1/4 from the top?
I'm not sure I'd appreciate that. (Sounds OK for moving off the top though.)

The other idea I had was that if the row was previously visible then it should be scrolled to between 1/4 and 3/4 otherwise it should be scrolled halfway.
(Reporter)

Comment 4

11 years ago
(In reply to comment #3)
> (From update of attachment 275659 [details] [diff] [review])
> >+        tree.treeBoxObject.scrollToRow(index - page / 4);
> So when you move off the bottom you actually jump to 1/4 from the top?

No, when I'm jumping to any mail in the middle I position it to be at (roughly) the first visible quarter.  The "/ 4" is more or less ad hoc.  Using "/ 2" also works.  This way the new mail will be shown in the middle.

The top and bottom cases are handled in the other if branches (see comments).

> I'm not sure I'd appreciate that. (Sounds OK for moving off the top though.)
> 
> The other idea I had was that if the row was previously visible then it should
> be scrolled to between 1/4 and 3/4 otherwise it should be scrolled halfway.

Yeah, I thought also about having the mail always in the middle (so always scrolling) bit it felt "uncomfortable".  This would probably be much better with smooth scrolling, so you eyes can actually track the motion.

Comment 5

11 years ago
(In reply to comment #4)
>(In reply to comment #3)
>>(From update of attachment 275659 [details] [diff] [review] [details])
>>>+        tree.treeBoxObject.scrollToRow(index - page / 4);
>>So when you move off the bottom you actually jump to 1/4 from the top?
>No, when I'm jumping to any mail in the middle I position it to be at (roughly)
>the first visible quarter.  The "/ 4" is more or less ad hoc.  Using "/ 2" also
>works.  This way the new mail will be shown in the middle.
That's what I meant to say; I thought it strange that you would jump so high.

>>The other idea I had was that if the row was previously visible then it should
>>be scrolled to between 1/4 and 3/4 otherwise it should be scrolled halfway.
>Yeah, I thought also about having the mail always in the middle (so always
>scrolling) bit it felt "uncomfortable".  This would probably be much better
>with smooth scrolling, so you eyes can actually track the motion.
I'm not sure what you mean by always scrolling. I think what you're trying to say is that your plan is that when the row gets to the end of the page it jumps to the first quarter (or middle) so you get less scrolling, whereas with my suggestion once it gets to 3/4 of the way down it's always scrolling. Maybe we can compromise; once it gets to 3/4 of the way down it jumps to the middle?
(Reporter)

Comment 6

11 years ago
(In reply to comment #5)
> (In reply to comment #4)
> >(In reply to comment #3)
> >>(From update of attachment 275659 [details] [diff] [review] [details] [details])
> >>>+        tree.treeBoxObject.scrollToRow(index - page / 4);
> >>So when you move off the bottom you actually jump to 1/4 from the top?
> >No, when I'm jumping to any mail in the middle I position it to be at (roughly)
> >the first visible quarter.  The "/ 4" is more or less ad hoc.  Using "/ 2" also
> >works.  This way the new mail will be shown in the middle.
> That's what I meant to say; I thought it strange that you would jump so high.

There seems to be a tradeoff.  On the one hand you want to have some context visible around the active mail, so I try to jump so, that the active one is not the first one shown.  On the other hand, you want to jump as seldom as possible as it requires a small amount of "finding" after the jump.  So, when going forward in the mailbox with a sequence of 'N's one wants to have the active message as high as possible so jumping occurs rarely.  *I* found 1/4 to be a good compromise, maybe this requires tweaking to personal taste?

> >>The other idea I had was that if the row was previously visible then it should
> >>be scrolled to between 1/4 and 3/4 otherwise it should be scrolled halfway.
> >Yeah, I thought also about having the mail always in the middle (so always
> >scrolling) bit it felt "uncomfortable".  This would probably be much better
> >with smooth scrolling, so you eyes can actually track the motion.
> I'm not sure what you mean by always scrolling.

So with scrolling *here* I meant to keep the active mail always at the same visible row (e.g. at row 5 of totally 10 visible).  So hitting 'N' would a) go to the next mail and b) also scroll the thread pane such that the new active mail would be at the same visible position again (e.g. row 5).

I tried this out, but found it disturbing, because scrolling does not happen pixelwise.  So it is very hard and unnatural for the eyes to track the scrolling if it actually jumps more than one mail.  What I wanted to say is: I think this option is not viable until we have pixel-wise scrolling.

> I think what you're trying to
> say is that your plan is that when the row gets to the end of the page it jumps
> to the first quarter (or middle) so you get less scrolling,

Yes.

> whereas with my
> suggestion once it gets to 3/4 of the way down it's always scrolling. Maybe we
> can compromise; once it gets to 3/4 of the way down it jumps to the middle?

Yes, sounds good too.  Again, maybe this is an candidate for a user customization?

I see two variables here:
 - where to place the active message after a jump (my favorite now: 1/4 of
   visible rows).
 - when to actually change the visible part of the thread pane (you suggested:
   when we hit 3/4 of the visible area)

Comment 7

11 years ago
(In reply to comment #6)
>So with scrolling *here* I meant to keep the active mail always at the same
>visible row (e.g. at row 5 of totally 10 visible).  So hitting 'N' would a) go
>to the next mail and b) also scroll the thread pane such that the new active
>mail would be at the same visible position again (e.g. row 5).
No, that sounds like a really bad idea to me. mscott, bienvenu, thoughts?

Comment 8

11 years ago
I agree - I don't care for that idea. You want to avoid scrolling when possible, because that avoids repainting, and avoids the user having to re-adjust.

Updated

11 years ago
OS: Linux → All
Hardware: PC → All

Updated

10 years ago
Duplicate of this bug: 342022

Updated

10 years ago
Summary: Scrolling/jumping to next message in threadPane works very unfavorably. → Scrolling/jumping to next message in threadPane works very unfavorably because selected message is the first or last line
(Reporter)

Comment 10

10 years ago
Just to give you more feedback: I have been using my proposed patch for 3 month now on a daily basis and am very happy with it.

Is there any problem with it?

Should I rework the patch for some reason?

What is delaying its usage?

Could someone confirm this bug formally (bug state != unconfirmed)?
(Reporter)

Comment 11

10 years ago
Ping

Comment 12

10 years ago
(In reply to comment #10)
>Should I rework the patch for some reason?
Does your patch take comment #8 into consideration?
(Reporter)

Comment 13

10 years ago
(In reply to comment #12)
> (In reply to comment #10)
> >Should I rework the patch for some reason?
> Does your patch take comment #8 into consideration?

Yes, it greatly reduces scrolling.
I think the core problem (being able to see what's next in the list at all times) is worth looking into.  

I tackled similar issues in Komodo, and it does get complicated, especially when you add selection with mouse clicks for example.  

One idea which would help w/ the eye tracking thing but which would require more work is for the scrolling to be smooth -- that way the user never loses "spatial context".

Adding Bryan as it's a UX call.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-thunderbird3?
Right, we need to balance the problem of being able to see what's next with minimizing the amount of scrolling that happens.  I think this means we just want to keep some buffer space between the focus position and the edge of the scroll view.  I believe that's what neil was getting at in comment 3.

The view should allow you to scroll around without keeping the focus directed to the middle where more scrolling action would be triggered.  At the same time we should be keeping the next and previous items in the list within the view.

A little ascii art to demonstrate, below is the entire scroll area with a virtual top and bottom buffer space that allows you to always keep the next or previous item in view while moving within the scroll area:

+---------------------------+
| top buffer space          |
|---------------------------|
| focus can change items    |
| within this area without  |
| causing view to scroll    |
|---------------------------|
| bottom buffer space       |
+---------------------------+
(Reporter)

Comment 16

9 years ago
I revised to patch to address the previous comment.

The visible area is now divided into a central part and upper / lower borders respectively.  The border size can be configured.

If the next active mail is in the central area, no scrolling is done at all.

If downward / upward scrolling is needed, the next mail is placed at the upper / lower border, so you have some room if you repeat the last action ('n', 'n', 'n', ...).

Please give feedback and test.
(Reporter)

Comment 17

9 years ago
Created attachment 358916 [details] [diff] [review]
Revised patch

Updated patch
Attachment #275659 - Attachment is obsolete: true
Attachment #358916 - Flags: review+
Attachment #275659 - Flags: superreview?(bienvenu)
Attachment #275659 - Flags: review?(neil)
(Reporter)

Comment 18

9 years ago
Created attachment 360570 [details] [diff] [review]
Update to proposed solution

Fixed behavior for very start and end, e.g., if entering a new folder.
Attachment #360570 - Flags: review+

Comment 19

9 years ago
did you mean to ask for review from someone, instead of just marking it r+? If so, I'd suggest neil@httl.net...
(Reporter)

Comment 20

9 years ago
By all means, whatever brings this forward.

I did not find a field or formal way to request review by someone specific.

Updated

9 years ago
Attachment #360570 - Flags: superreview?(bienvenu)
Attachment #360570 - Flags: review?(neil)
Attachment #360570 - Flags: review+

Comment 21

9 years ago
Comment on attachment 360570 [details] [diff] [review]
Update to proposed solution

instead of just setting the review to plus, you set it to ? and then type in the e-mail address of the person you want a review from.
(In reply to comment #15)
> +---------------------------+
> | top buffer space          |
> |---------------------------|
> | focus can change items    |
> | within this area without  |
> | causing view to scroll    |
> |---------------------------|
> | bottom buffer space       |
> +---------------------------+
Firstly, I would like to point out that I agree that the current scheme is not ideal. In fact, I deliberately resize my thread pane so as to reveal 95% of the next message header (which basically is everything except the bottom margin). However this scheme, as does the one depicted here, suffers from the problem that once you get to the bottom buffer you scroll for each message until you get to the end of the list. By comparison I believe the behaviour of emacs is not to scroll, but if you move just off the top/bottom then scroll to reveal some buffer space, and if you move a long way away then center the selected message.
(Reporter)

Comment 23

9 years ago
Sorry, I think you missinterpret the code.  I should actually behave very similarly to what emacs does.

I you hit the bottom buffer space on going down, your cursor is positioned at the lower end of the next top buffer space.
(In reply to comment #23)
> Sorry, I think you missinterpret the code.  I should actually behave very
> similarly to what emacs does.
Actually I hadn't read the code, or indeed your previous explanation that matches what your code does. I do have to disagree about your comparison to emacs though, as I don't remember it scrolling that much at a time.
Hmmm, perhaps my comments from Comment #15 were misunderstood.  Our goal was to always make the next/previous messages available in the list.

Inside the middle area between the buffers a person can change focus with their next/previous messages still in view.  Without having the buffer areas when you change focus from the first or last message to a message outside the view the view code scrolls that next message into view.  What I believe we want to do is keep the buffer space such that a scroll is caused when focus goes into the buffer space.

Here's an example of the focus change using a similar layout to before with numbers detailing the different messages and where *#* == focus.

Initially focus is on the 8th message, but when the person hits 'f' for forward the list scrolls 1 message because the 9th message is in the buffer space.
+---------------------------+
| 1                         |
| 2                         |
| 3                         |
|---------------------------|
| 4                         |
| 5                         |
| 6                         |
| 7                         |
| *8*                       |
|---------------------------|
| 9                         |
| 10                        |
| 11                        |
+---------------------------+

Here is the next view where the 9th message has been highlighted and a new 12th message (which was out of the viewport area before) has been pulled into view, while the 1st message has fallen out of the viewport area due to the scroll.
+---------------------------+
| 2                         |
| 3                         |
| 4                         |
|---------------------------|
| 5                         |
| 6                         |
| 7                         |
| 8                         |
| *9*                       |
|---------------------------|
| 10                        |
| 11                        |
| 12                        |
+---------------------------+

Neil laid this out well over irc that explains most possible implementations, I've adapted it to fit the above example.

- The thread pane has 11 lines and you have 3 lines of buffer - 

  a) when you get to line 9, scroll it up to line 8
  b) when you get to line 11, scroll it up to line 8
  c) when you get to line 9, scroll it up to line 4
  d) 11 -> 4? possible others?

I believe we want to do (a) such that we're essentially causing scrolling prematurely. b) is the emacs style that causes a small scroll jump when you hit the border; this doesn't really solve our goal of having the headers in view.  c) is a reset of the scroll which makes for a large scroll jump but doesn't solve our goal.

Updated

9 years ago
Attachment #360570 - Flags: review?(neil)
Comment on attachment 360570 [details] [diff] [review]
Update to proposed solution

Cancelling review given that this isn't the solution that Bryan wants.
(Reporter)

Comment 27

9 years ago
I was actually addressing comment #15 which says: "Right, we need to balance the problem of being able to see what's next with minimizing the amount of scrolling that happens."

This is achieved with version c. which is implemented by my patch.

Try it.  Seriously.  It is the way to go unless pixelwise scrolling is available.  I described the effect in #6 with the version that always tries to keep the focus in the middle of the visible area (a special case of what is now described as a.).  It sounds good in theory but is unusable in practice.

Try it out with small and large mail folders.  Especially if some mails are already marked as read and some jumping is involved when hitting 'n'.

Btw. emacs' way of scrolling is (at least in current 23.0.60.1-cvs): scroll on hitting the border and such that the new cursor position is in the middle of the buffer.  So, it always scrolls for 1/2 visible buffers.  The intention is to a.) minimize scrolling and b.) to have a lot of context at the new cursor position for reading and editing.

We, however, want something slightly different.  We want to a.) minimize scrolling too and b.) very often continue with the previous operation (go up / down).  So we need more context into the direction of moving (also in order to further minimize scrolling).  So, not positioning the cursor in the middle but slightly to the border is a good thing.

Comment 28

9 years ago
Comment on attachment 360570 [details] [diff] [review]
Update to proposed solution

canceling sr request - but it's up to Bryan to respond to the last comment.
Attachment #360570 - Flags: superreview?(bienvenu)
(In reply to comment #27)
> I was actually addressing comment #15 which says: "Right, we need to balance
> the problem of being able to see what's next with minimizing the amount of
> scrolling that happens."

I guess I was aiming for more of an even balance. :)

> This is achieved with version c. which is implemented by my patch.
> 
> Try it.  Seriously.  It is the way to go unless pixelwise scrolling is
> available.  I described the effect in #6 with the version that always tries to
> keep the focus in the middle of the visible area (a special case of what is now
> described as a.).  It sounds good in theory but is unusable in practice.
> 
> Try it out with small and large mail folders.  Especially if some mails are
> already marked as read and some jumping is involved when hitting 'n'.

I haven't actually tried this yet, so I hope it still applies as I'd like to do that.  With the c) implementation it's much more of a paging interface than what we currently have so I'm curious if it will work out better for everyone.

But here's how I'd like to move forward.  I'm going to try the patch out for this week so I can understand it better; I hope others do the same.  I don't really care which behavior is correct, I'd like to have the ability for extensions to change it.  I'm not sure what that would take, but obviously we have at least two different types of scrolling that are both valid and useful.  So it would be great if there was a quick couple line extension that could be written to override the default scroll behavior we commit to trunk with a different behavior.  This would also give us some minimal statistics on usage of the alternate behavior.

Neil, MartinP, bienvenu: can one of you look into or suggest the changes necessary so this behavior is extensible?  Thanks.
Flags: wanted-thunderbird3? → blocking-thunderbird3+
Whiteboard: [b3ux][m3]
Target Milestone: --- → Thunderbird 3.0b3
(Reporter)

Comment 30

9 years ago
Just a short note to the patch: It should still apply and you don't have to recompile for the patch to take effect.  You just have update the javascript code in messenger.jar/content/messenger/threadPane.js.
I'm trying it out, but the scroll feels somewhat unexpected.  If I'm paying attention carefully it's nice because I get a whole new page of messages to look over.  However when I'm just hitting next as I quickly run through the list it seems jarring when it decides to page in the new list.  I'll keep trying it out.

If you swap out the existing logic for this it just adds a buffer area to the scroll so you're always 2 messages away from the edge.  You might want to try this out too.

 if (index >= last - 2)  // move down, look ahead 2
 { // only move 1 because 1/2 visible rows mean we'll bounce otherwise
   tree.treeBoxObject.scrollToRow(Math.min(max - 1, first + 1));
 }
 else if (index < first + 2)  // move up, top always aligns with a row, look 2, move 2
 {
   tree.treeBoxObject.scrollToRow(Math.max(0, index - 2));
 }

Updated

9 years ago
Assignee: nobody → clarkbw
Created attachment 371485 [details] [diff] [review]
small buffer area patch

Ok, I tried this out for a week and couldn't get used to the behavior.

Neil: can you take a look at this version of the patch?

I want to land this version of the patch because I think it's a bit simpler and keeps with existing scrolling behavior instead of changing it.

However I also want to get your version of the patch into AMO so we can get people the alternate behavior.  I'd personally like to show that small patches can be made to override behavior and are excellent candidates for extensions that allow people to really customize TB.

So Martin, I can create the extension or push it through AMO; just let me know whatever you want to do.  I'm the admin for our AMO extensions so I should be able to get it through the process fairly quickly.  However you want to do this I think we need the extension in source control somewhere and then we can create the XPI to deliver to add-ons.mozilla.org
Attachment #371485 - Flags: review?(neil)
Whiteboard: [b3ux][m3] → [b3ux][m3][needs review]
(Reporter)

Comment 33

9 years ago
Bryan: Have you tried your patch with a very small message pane, say two lines high?

Regarding the extension: I have no preference here, as I have not experience doing mozilla extensions.  I'd appreciate whatever results in a) my version in thunderbird or b) my version in an extension with minimal effort :-).
Comment on attachment 371485 [details] [diff] [review]
small buffer area patch

>+  // Diagram
I don't think we need a whole diagram, a comment along the lines of "try to keep the surrounding four messages visible" should suffice :-)

>+  if (index >= last - 2)  // move down
>+  { // look ahead 2, 1/2 visible rows can cause bouncing so only move 1
>+    tree.treeBoxObject.scrollToRow(Math.min(max - 1, first + 1));
This doesn't look right, since it only advances one row at a time; the next unread message may be out of sight, particularly in threaded view. Notwithstanding the issue of a really short thread pane, of course ;-)
Attachment #371485 - Flags: review?(neil) → review-
I haven't taken another try at this, maybe this week I'll have time to give it another go but anyone else can feel free to take this over.
Whiteboard: [b3ux][m3][needs review] → [b3ux][m5][needs updated patch]
Whiteboard: [b3ux][m5][needs updated patch] → [b3ux][m6][needs updated patch]
Created attachment 374312 [details] [diff] [review]
updated, simpler patch

This is basically the same logic but cleaned up.  I'm not sure who should review this now since it's in mail and not mailnews anymore... I have no idea when the fork happened.

There is an issue that the last row could only be partially visible and is still counted so you have to subtract that from the last count for this to work properly.
Attachment #371485 - Attachment is obsolete: true
Attachment #374312 - Flags: review?(neil)
Whiteboard: [b3ux][m6][needs updated patch] → [b3ux][m6][waiting on review]
Version: unspecified → Trunk
Comment on attachment 374312 [details] [diff] [review]
updated, simpler patch

Sorry it took me so long to get around to reviewing this.

I found the following problems trying out this patch:

1. When scrolling down using the f key, the tree scrolled one row too far, so that there was an extra blank row at the bottom (normally there's only a partial blank row).

2. This may be intentional, but if you clicked on the first visible row, and pressed b to go to the previous message, then that became the new first visible row, rather than creating any sort of buffer.

3. If you then pressed f, then the tree actually scrolled down a row at the same time, thus making the selection jump two lines.

4. & 5. As per 2. & 3. but working at the last visible row.

6. If you pressed n to go to a message that was off-screen, then the tree would only scroll one line, rather than bringing that message on screen.
Attachment #374312 - Flags: review?(neil) → review-
Ok, well I'm not going to be able to keep working on this so I'm throwing it back into the void.  It is still blocking, even though I'm removing the target for it so likely it will fade away slowly until we find it again in september...

If anyone has the time to pick this up please just take it over.
Assignee: clarkbw → nobody
Keywords: helpwanted
Whiteboard: [b3ux][m6][waiting on review] → [b3ux]
Target Milestone: Thunderbird 3.0b3 → ---
(Assignee)

Comment 39

9 years ago
I actually copied your code into my gloda-search folder display abstraction patch already.
Assignee: nobody → bugmail
(Reporter)

Comment 40

9 years ago
I'm still willing to put some more effort into this.

There was the idea of having the code in an addon, is there any
progress on this front?  It would allow easier testing of the
alternatives.  I have no experience with writing addons, but would be
willing to fill in the functional code.  The addon only would need to
be able to replace "function EnsureRowInThreadTreeIsVisible(index)".

Alternatively, maybe we can enhance my third version of the patch to
be more configurable to everybody's liking.

As a first shot to generalize the scrolling preferences of the
different persons:

We need to configure, *when* to scroll, and *whereto* to scroll.

*When* could be expressed in "distance to visibility border in %".
 - 0 would mean: only scroll if the border is actually hit.
 - 100% would mean: scroll even if we are at the first line in moving
   direction (e.g., first line of going down).
 - 50% would mean: only scroll if we cross the middle in the visible
   area.

*whereto* could be expressed in "where to place the next active row in
the new visibility window in moving direction".
 - 0 would mean: place in the beginning (start of new page, 1st row if
   going down)
 - 100% would mean: place in the end (end of page, last visible row if
   going down)
 - 50% would mean: place in the middle.

Example configurations:
- The current behavior is: when = 0, whereto = 100%. (if going down,
  always at the last row)
- I personally would like something around: when = 20%, whereto =
  10%. (almost paging, jump a little bit before the end, start a
  little bit from the border)
- Claws mail has something like: when = 0, whereto = 0 (fully paging).
- Emacs (per default) does something like: when = 0, where = 50%.

(Probably, not all configurations make sense here).

Is everybody's preference expressible with this notation?

If yes, I would try to rewrite my patch using these parameters.
Martin, the extension is pretty easy.  I would start with the extension wizard to give you the boiler plate code you need.

http://ted.mielczarek.org/code/mozilla/extensionwiz/

Then follow some of the extension develop tips ( https://developer.mozilla.org/en/Setting_up_extension_development_environment ) to get the right environment.

Then you probably want to overlay messenger.xul since that seems to load the threadpane.js file.
( http://mxr.mozilla.org/comm-central/source/mail/base/content/messenger.xul )

I'm sure there's nicer ways to do it, but you can just overwrite the function name with your own and then get exactly what you want.

Throw your code up on bitbucket or github and send me an email.  I can help you get through the http://add-ons.mozilla.org process and then your extension will be easily installable from the add-ons manager window.  go go go! :)
(Reporter)

Comment 42

9 years ago
Guys, I implemented my idea as an extension.  Please find it here:

http://bitbucket.org/martinp26/threadpanesanitizer/raw/7e4679b4ff9d/threadpanesanitizer.xpi

You can check out different policies easily using the extension: modify "when" and "whereto" in the preferences and move around a large folder with many unread messages using "n" and "p".

I added some preset policies: Current TB, Emacs-like, Full-paging (like claws mail), and "Almost full paging".

(Compared to the above description, I inverted the meaning of when.)
From Comment #39 and talking to Andrew bug 474701 should incorporate the fix we wanted so I'm not going to leave this as blocking anymore.  Martin's extension should be making it's way into add-ons soon.  Will post a URL back here for the add-on page when it is up.

I'm not sure what to do with the resolution status here.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Keywords: helpwanted
Whiteboard: [b3ux] → [b3ux][see comment #39]

Comment 44

9 years ago
For consistency, should the same logic be applied to scrolling the folder pane (and thus at the same time resolving bug 470416)?
(Reporter)

Comment 45

9 years ago
I thought about this too, but decided that it would not make much sense as the usage pattern for both panes is very much different:

In the thread pane I want to process many items in a row and need context view.  Single items (mails) usually have a relation (e.g. thread or general topic).

In contrast, in the folder pane I use a very static view and the single entries are typically not processed in a specific order.  They are ordered just alphabetically.

But that is just *my* usage pattern

Comment 46

9 years ago
For a usage pattern where this would make sense for the folder pane: heavy mailing list and/or newsgroup use, where having lots of unread messages in lots of different folders/groups is going to be a fairly common occurrence. When using the N key to step through unread messages in multiple folders/groups, after reaching the last unread message in a folder/group it would be nice to see the folder/group you'll be taken to next (though admittedly if the next group with unread messages is a long way down the list you're not going to see it in advance anyway).
(Assignee)

Comment 47

9 years ago
Bug 474701 landed a fix that incorporates the single-message 'buffer' for the row ensuring logic.  Additionally, we 'snap' to the end of the list.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.