Closed
Bug 416158
Opened 16 years ago
Closed 16 years ago
Keyboard navigation of the event list (unifinder) is slow
Categories
(Calendar :: Calendar Frontend, defect)
Calendar
Calendar Frontend
Tracking
(Not tracked)
VERIFIED
FIXED
0.8
People
(Reporter: davida, Assigned: Fallen)
Details
Attachments
(1 file)
1.36 KB,
patch
|
sebo.moz
:
review+
|
Details | Diff | Splinter Review |
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)
Flags: blocking-calendar0.8?
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•16 years ago
|
||
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
Comment 3•16 years ago
|
||
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+
Comment 6•16 years ago
|
||
(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.
Assignee | ||
Comment 7•16 years ago
|
||
Thunderbird uses 500 ms. It looks like its quite easy to do this, this attribute adds the delay.
Comment 8•16 years ago
|
||
Comment on attachment 303850 [details] [diff] [review] Add delay r=sebo
Attachment #303850 -
Flags: review?(sebo.moz) → review+
Assignee | ||
Comment 9•16 years ago
|
||
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Comment 10•16 years ago
|
||
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.
Updated•16 years ago
|
Version: Mozilla 1.8 Branch → unspecified
Comment 11•16 years ago
|
||
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.
Description
•