All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060130 SeaMonkey/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) 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.
yup - this allows you to cursor through the message list quickly without loading any messages. It's more or less by design.
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.)
Version: unspecified → SeaMonkey 1.0 Branch
> 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?)
(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 ?
Version: SeaMonkey 1.0 Branch → SeaMonkey 1.1 Branch
(In reply to comment #4) > Can you reproduce with SeaMonkey v2.0a1pre ? It still seems to happen in SeaMonkey 2.0.6.
(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.
Summary: extra 0.4 second delay when switching messages by changing selection → extra 0.4 second delay when switching messages by clicking message
Whiteboard: [closeme 2013-04-01]
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2013-04-01]
You need to log in before you can comment on or make changes to this bug.