Steps to reproduce: 1) in Calendar mode, with all future events seleted (although it's also showing past events, which is a separate bug but may be useful to know) 2) click on an event in the list 3) up or down arrow expected: just a change in the list of which event is selected actual: long delay as the calendar view is refreshed (which is slow with a caldav calendar), about 3 seconds, and the list view loses focus, meaning that the next event is selected (dark gray) but the list widget doesn't have focus (if it did the event would have focus)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 348481
Only the focus issue is covered by the duped bug report. We still need to track and fix the performance issue.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: Keyboard navigation of the event list is painfully slow and loses focus → Keyboard navigation of the event list (unifinder) is slow
Selecting the event in the unifinder will select the same event in the main calendar view. This causes the view to change and repaint.
One way to solve this would be to have a "wait" event occur before you select the given item in the calendar view. For example while you're scrolling it doesn't mirror that selection in the calendar view and when you stop scrolling and select an event for some amount of time, say 5 seconds or something, then it selects the event in the calendar view.
We will block on this because we think it is an important usability consideration. If we can get a patch in the next few days, we'll take it, otherwise we'll re-set it to a minus'd state.
Flags: blocking-calendar0.8? → blocking-calendar0.8+
(In reply to comment #4) > when you stop scrolling > and select an event for some amount of time, say 5 seconds or something, then > it selects the event in the calendar view. I like your idea, Clint, but I vote for 0.5 or 1.0 seconds. Or maybe use the value that Thunderbird uses from the time that people stop scrolling in the Thread pane to when Thunderbird updates the Preview pane.
Thunderbird uses 500 ms. It looks like its quite easy to do this, this attribute adds the delay.
Assignee: nobody → philipp
Status: REOPENED → ASSIGNED
Attachment #303850 - Flags: review?(sebo.moz)
Comment on attachment 303850 [details] [diff] [review] Add delay r=sebo
Attachment #303850 - Flags: review?(sebo.moz) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Great stuff, I agree that we should work with TB's default delay first. We can always adjust the delay time later if this turns out to be the wrong choice.
Checked in lightning build 2008030318 ans Sunbird 20080303 -> task is fixed and verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.