UX: Removing thread-pane "snap to last page" behavior

Andrew Sutherland asutherland at asutherland.org
Sun Jan 19 20:57:28 UTC 2014

On 01/18/2014 01:28 AM, Andrew J. Buehler wrote:
> However, given that we've gone something like 4.5 years now with "snap
> to last page" but without implementing this, A: are we likely to
> actually do it? and B: is it really that important?

I think it's pretty definite nothing is going to happen unless you (or 
some other brave soul steps up; but let's not count on that!). I just 
wanted to provide the context of the original decision, especially now 
that I managed to remember it! :)

Another memory that's coming back to me now is that the 'snap' goal in 
question I think may also have been a stop-gap brought about by the 
limitations of the tree view.  I think the dream goal would be something 
like a (transient?) 'position: sticky'  toaster-ish thing in the 
direction of the new messages (or a bar?) saying how many new messages 
received.  The folder-pane's newness flags are able to achieve a 
somewhat comparable result, although it does require either looking at 
all the new messages or changing folders to flush the newness bits (if 
so configured).

In general I also recall finding the handling of new messages as 
somewhat difficult since it's a non-persistent flag list of 'new-to-us' 
unread messages and Thunderbird's IMAP implementation isn't really aware 
of INTERNALDATE which I think constitutes a better approximation for 

My opinion-wise I think I broadly agree with what you (and Gerv) are 
saying.  It's surprising/confusing to the user when scrolling behaviour 
is inconsistent.  The 'padding' logic works out okay because its 
behaviour is consistent.  The snapping behaviour is a big discontinuity 
in that behaviour, noting that at some point even padding effectively 
had to stop because the tree-view's mouse scrolling wouldn't let you 
scroll beyond the last row although you can programatically do it.  
Threaded display is a big complication the original solution and 
game-plan did not deal with (well).

Aside: I personally find that when a thread gets more than 10 messages 
or so that threaded mode is really only useful for local navigation of 
the thread.  Moving to the parent it was replying to, or finding other 
direct replies work great.  Well, work great if the mail-to-news gateway 
on Mozilla mailing lists isn't involved and destroying the message-id's 
and breaking threading.


More information about the tb-planning mailing list