333013 - extra 0.4 second delay when switching messages by clicking message

Status: RESOLVED INCOMPLETE

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

Seamonkey seems to delay 0.4 seconds after the mail list selection is 
changed before proceeding with displaying the selected message.  

Switching between mail messages by changing the selection (e.g., using 
the up or down arrows in the message list pane, or clicking on a message's
representation) takes about 0.4 second _longer_ than switching to the next
unread message (by typing "n" to invoke the Next Unread Message command).

Given that going to a selected message doesn't take any more work than 
finding the next unread message and then selecting and going to it, the 
former shouldn't take longer than the latter.

Therefore, Seamonkey seems to be inserting an arbitray delay.


Other menu and selection system have added similar (ill-designed) delays.

(Microsoft Windows' Start menu hierarchy is a case in point.  When you
drag the mouse cursor onto a menu item for a nested menu to make that
nested menu pop up, the system delays for a bit before starting to draw
the pop-up menu.

The delay is long enough that it is easy to move the mouse to the right
to where you expect the nested menu to pop up before it actually pops
up.  This meant (they've modified this since) that the menu didn't pop
up at all.  You expected to have the mouse cursor over some item in the
nested menu, but there wasn't any menu there and you had to move back to
the parent menu and try again--not very efficient.

That delay was a bad hack to fix a problem that they didn't fix the
right way.

The problem was that if they drew pop-up menus as soon as the mouse
cursor entered a menu item, then moving across several menu items would
draw and erase multiple pop-up menus.  Drawing operations took long
enough to cause a significant delay in giving visual feedback to the
user (highlighting and unhighlighting menu items) and in responding to
the user's real intentions (e.g., getting to the nested menu of the final
menu item to which the user moved).

Microsoft "fixed" the the problem by adding a delay.  The delay partially
fixed the problem, because as you dragged your mouse cursor across the
intervening menu items for unwanted pop-up menus, the system didn't take
time to draw those pop-up menus--it could keep up with your mouse
movements and update the highlighting of the menu items you were moving
across.

However, the fix was a bad one because when you got to your intended
menu item, the nested menu wouldn't pop up as fast as the computer
could draw it--you had to wait for the extra delay before you'd get
your menu.

The fix was a hack because there are better solutions.  One would have
been to abort drawing a pop-up menu as soon as the mouse cursor left
the associated menu item (instead of finishing drawing the entire
pop-up menu).  That way, when you moved over intervening menu items, you
wouldn't suffer the delay of fully drawing the unwanted pop-up menu, and
when you got to your indended menu item, the system would render it as fast
as it could (without some arbitrary delay).)

Seamonkey shouldn't use the same bad hack.


Reproducible: Always

Steps to Reproduce:
1.  Select a message.
2.  Type "n" to move to the next unread message (in the same folder).
3.  Note the delay to displaying the next message.
4.  Now type up or down arrow (with the focus in the message line pane),
    or click on a message's representation in the list.
5.  Note the delay.
6.  Notice that the delay in the second case is noticeably longer.

(If it's hard to notice the difference with one message, try going through
five or ten in a row.)


Actual Results:  
See step 6.

Expected Results:  
The change-selection case shouldn't take longer than the next-unread case.

Comment 1

[David :Bienvenu]

yup - this allows you to cursor through the message list quickly without loading any messages. It's more or less by design.

Comment 2

[Serge Gautherie (:sgautherie)]

SeaMonkey v1.0.x is not supported anymore.

Can you reproduce with SeaMonkey v1.1.9 ?

***

If I understand correctly,

The up/down arrow should have the delay, to be able to skip loading messages.

The mouse click should *not* have the delay, as it is a direct choice.

(Ctrl+click or Shift+click might want to keep the delay, as we can expect a multi-selection to follow.)

Comment 3

[Daniel B.]

> SeaMonkey v1.0.x is not supported anymore.

So what?  Check whether the current supported version has the problem.


> Can you reproduce with SeaMonkey v1.1.9 ?

Yes.  Couldn't you reproduce it?  (Might it depend on mail volume?)

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)
> (Might it depend on mail volume?)

No, I think the delay is a value somewhere in the code.

***

Can you reproduce with SeaMonkey v2.0a1pre ?

Comment 5

[Daniel B.]

(In reply to comment #4)

> Can you reproduce with SeaMonkey v2.0a1pre ?

It still seems to happen in SeaMonkey 2.0.6.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to Daniel B. from comment #5)
> (In reply to comment #4)
> 
> > Can you reproduce with SeaMonkey v2.0a1pre ?
> 
> It still seems to happen in SeaMonkey 2.0.6.

If it is being impacted by mailnews.threadpane_select_delay you should be able to increase it above the default value of 250, to something like 2000, and know whether this setting is incorrectly affecting direct click.

Comment 7

[Phoenix]

Resolved per whiteboard