Closed
Bug 242791
Opened 20 years ago
Closed 15 years ago
click-selecting an email displays it instantly. moving between mails using cursors causes annoying delay
Categories
(Thunderbird :: Mail Window Front End, defect)
Thunderbird
Mail Window Front End
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0b3
People
(Reporter: bugzilla, Assigned: maxxmozilla)
References
Details
Attachments
(1 file, 2 obsolete files)
4.72 KB,
patch
|
mkmelin
:
review+
maxxmozilla
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•19 years ago
|
||
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.
Comment 2•18 years ago
|
||
Note: This bug does not appear when using 'F' and 'B' keys, but does when using Up and Down arrows.
Updated•17 years ago
|
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...
Comment 5•17 years ago
|
||
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.
Comment 9•16 years ago
|
||
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: 16 years ago
Resolution: --- → INVALID
Comment 10•16 years ago
|
||
"...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?
Comment 11•16 years ago
|
||
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.
Assignee | ||
Comment 12•15 years ago
|
||
Discussion: http://forums.mozillazine.org/viewtopic.php?f=29&t=1083805
Comment 13•15 years ago
|
||
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.
Assignee | ||
Comment 14•15 years ago
|
||
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 → ---
Assignee | ||
Updated•15 years ago
|
Version: unspecified → Trunk
Comment 15•15 years ago
|
||
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...
Assignee | ||
Comment 16•15 years ago
|
||
(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 ?
Assignee | ||
Updated•15 years ago
|
Attachment #362608 -
Attachment is obsolete: true
Attachment #362608 -
Flags: review?(mkmelin+mozilla)
Comment 17•15 years ago
|
||
Sounds ok to me, or maybe onfocus? Though you'll need neil or someone to sr too since it's partly mailnews.
Comment 18•15 years ago
|
||
ThreadPaneOnLoad sounds good to me. Note that you should use the _selectDelay property rather than the attribute.
Assignee | ||
Comment 19•15 years ago
|
||
Updated to comments.
Attachment #362973 -
Flags: superreview?(neil)
Attachment #362973 -
Flags: review?(mkmelin+mozilla)
Assignee | ||
Updated•15 years ago
|
Status: REOPENED → ASSIGNED
Updated•15 years ago
|
Attachment #362973 -
Flags: superreview?(neil) → superreview+
Comment 20•15 years ago
|
||
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]
Assignee | ||
Comment 21•15 years ago
|
||
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)
Updated•15 years ago
|
Attachment #362980 -
Flags: review?(mkmelin+mozilla) → review+
Comment 22•15 years ago
|
||
Comment on attachment 362980 [details] [diff] [review] Proposed fix v3 [Checkin: Comment 23] Nice! r=mkmelin
Updated•15 years ago
|
Target Milestone: --- → Thunderbird 3.0b3
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 23•15 years ago
|
||
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]
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b2
Updated•15 years ago
|
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
You need to log in
before you can comment on or make changes to this bug.
Description
•