Closed Bug 242791 Opened 16 years ago Closed 11 years ago

click-selecting an email displays it instantly. moving between mails using cursors causes annoying delay

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: bugzilla, Assigned: maxxmozilla)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

click-selecting an email displays it instantly in the preview screen. 

moving between mails using the cursor keys causes an extremely annoying delay of
around 2 seconds - why put in a delay for people trying to save time?

Reproducible: Always
Steps to Reproduce:
1. click an email in your inbox-list
2. hark at how quickly it appeared in the preview window
3. use cursor-up to go to next email
4. wait 2 seconds
5. wonder why it took 2 seconds to display the email

Actual Results:  
one email displayed instantly, one takes a while

Expected Results:  
both should have been instant.
Confirming on 20050811 trunk.

I've measured the delay thunderbird adds at approximately 0.8 seconds for me
when selecting a message with the keyboard - enough to make it difficult to
quickly move through messages with the keyboard.

When selecting a message with the mouse the selected message is shown instantly.
Note:

This bug does not appear when using 'F' and 'B' keys, but does when using Up and Down arrows.
QA Contact: front-end
I can confirm this problem as well, I found it a very annoying issue on thunderbird, as Thomas said - "enough to make it difficult to
quickly move through messages with the keyboard".

I can't understand how this bug was filled in 2004 and haven't been fixed yet...
Confirmed on linux/trunk. (I suppose this is only for IMAP accounts.)

I find esp comment 2 interesting. Are the up-down keys going though some slow code, which "F" and "B" aren't?
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
No, this is not only in IMAP accounts, same for local folders, and I can confirm F/B keys doesn't have that delay, only the cursor keys.

I think maybe this was done by-design to avoid having to repaint a lot of messages if we pres down, down, down, down... to reach some specific message, however it is a big pain if we really need to see every message in a fast way, eg. reviewing spam... or searching some message by looking at body... I think the best way would be add a setting on about:config to allow to enable/disable this delay.
same problem here
Duplicate of this bug: 373107
Ah yes this is per design so you can go through messages fast and don't look at them, and have them marked as read in the process. 
(I think it's the _selectDelay that trees have.)
->INVALID
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
"...so you can go through messages fast and don't look at them..."

The problem is if you want to go through messages fast and LOOK at them... you just can't :( 

"...and have them marked as read in the process..."

This is not a problem if we have the "Wait X seconds before marking a message as read" option enabled.

Is there no way to make this an option on about:config at least?
What is the benefit to the end user of going through messages and NOT looking at them?  Wouldn't it be of more benefit to the user if as soon as they select a new message, the preview pane starts rendering it?  As it is, with the artificial delay, it may just make the rendering feel "disappointingly slow" - when in reality rendering hasn't even begun.  Wouldn't the user expect that when they move move to a new message, it should display the new message as soon as they requested it?

Furthermore, this doesn't address the inconsistency in behaviour between moving to a new message with up and down arrows, vs moving with F and B keys, and clicking with the mouse.  For the latter two, the new message IS displayed in the preview pane as soon as it's requested.
Would I be able to nominate this bug for re-opening?

Based on the above linked discussion in comment #12 I've come to the conclusion that there are two aspects of this bug which need further attention.

1. Inconsistency of behaviour between Up/Down and F/B.  If the delay is necessary for working around an IMAP related problem ie bug #363039, then the delay should be applied consistently for both Up/Down and F/B.  There is no value to use in having them different, as the availability of both is not discoverable.

2. Delay applied unnecessarily to situations where the mail being loaded is stored locally.  Since this delay is a workaround to a problem fetching remote IMAP mails, it should not be applied when the mail being requested is already mirrored locally, or is a local folder (such as a POP account) - more common scenarios.  Doing so only introduces an unnecessarily delay, as fetching these mails requires no contact with the server and would otherwise load instantly.

Let me know if you would prefer I opened new bugs instead - I just thought this was probably already duped to here enough already.
Attached patch Proposed fix v1 (obsolete) — Splinter Review
This bug is very annoying, please approve at least a hidden pref to change the behavior.


Thanks to paul@world3.net for the hint (Bug 373107 comment #1)
Assignee: nobody → firefox
Status: RESOLVED → REOPENED
Attachment #362608 - Flags: review?(mkmelin+mozilla)
Resolution: INVALID → ---
Version: unspecified → Trunk
Comment on attachment 362608 [details] [diff] [review]
Proposed fix v1

> function ThreadPaneKeyPress(event)
> {
>   if (event.keyCode == KeyEvent.DOM_VK_RETURN)
>     ThreadPaneDoubleClick();
>+  let delay = pref.getIntPref("mailnews.show_message.delay");
>+  document.getElementById("threadTree").setAttribute("_selectDelay", delay);

This shouldn't be called here - we don't need to do it for every key press.

>+// delay after which messages are showed when moving through them with cursors
>+pref("mailnews.show_message.delay", 500); // measured in miliseconds

"mailnews.threadpane_select_delay" perhaps? Also, milliseconds with two l's, and mention it's for the thread pane navigation in the comment.

We should probably make this a bit lower than it is currently. With 250ms you're still able to navigate quite easily down,down,down without loading all messages in between. 

What is the default _selectDelay? 
Probably best to leave the default attribute in the xul...
(In reply to comment #15)
> This shouldn't be called here - we don't need to do it for every key press.
yeah, I've also thought about it, user can restart app after changing the pref...
ThreadPaneOnLoad() would be ok ?

> We should probably make this a bit lower than it is currently. With 250ms
> you're still able to navigate quite easily down,down,down without loading all
> messages in between. 
> 
> What is the default _selectDelay? 
> Probably best to leave the default attribute in the xul...
default is 500ms, 250ms seems to be a way better default, I'll leave the new default (250) in xul and the same would be default in the pref - is that what you've wanted ?
Attachment #362608 - Attachment is obsolete: true
Attachment #362608 - Flags: review?(mkmelin+mozilla)
Sounds ok to me, or maybe onfocus? Though you'll need neil or someone to sr too since it's partly mailnews.
ThreadPaneOnLoad sounds good to me.

Note that you should use the _selectDelay property rather than the attribute.
Attached patch Proposed fix v2 (obsolete) — Splinter Review
Updated to comments.
Attachment #362973 - Flags: superreview?(neil)
Attachment #362973 - Flags: review?(mkmelin+mozilla)
Status: REOPENED → ASSIGNED
Attachment #362973 - Flags: superreview?(neil) → superreview+
Comment on attachment 362973 [details] [diff] [review]
Proposed fix v2

>diff --git a/mail/base/content/messenger.xul b/mail/base/content/messenger.xul
Please change mailnews/base/resources/content/threadPane.xul to match, thanks.
[no new sr is required for that change]
includes fix for threadPane.xul
Attachment #362973 - Attachment is obsolete: true
Attachment #362980 - Flags: superreview+
Attachment #362980 - Flags: review?(mkmelin+mozilla)
Attachment #362973 - Flags: review?(mkmelin+mozilla)
Attachment #362980 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 362980 [details] [diff] [review]
Proposed fix v3
[Checkin: Comment 23]

Nice! r=mkmelin
Target Milestone: --- → Thunderbird 3.0b3
Keywords: checkin-needed
Comment on attachment 362980 [details] [diff] [review]
Proposed fix v3
[Checkin: Comment 23]


http://hg.mozilla.org/comm-central/rev/0b4e7f946930
Attachment #362980 - Attachment description: Proposed fix v3 → Proposed fix v3 [Checkin: Comment 23]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b2
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
Duplicate of this bug: 350224
You need to log in before you can comment on or make changes to this bug.