Closed
Bug 20788
Opened 25 years ago
Closed 24 years ago
[feature] <tree> onselect should be controlled with a timer
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: bugs, Assigned: hyatt)
Details
(Keywords: helpwanted)
Look at: Edit -> Wallet -> View Cookies (make sure you have several cookies) Click in the tree, then move the cursor keys up and down quickly. You'll notice you cannot move the selection very fast as each time selection changes, onselect for the tree fires and causes the data display panel in the bottom half of the dialog to be updated. What should happen: The onselect event should be fired after an interval after the user has released the navigation key (or mouse button, fast-clicking isn't likely here, but might be likely in other circumstances), so that whatever is associated with onselect is only called when the user has finished their navigation process.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13
Assignee | ||
Comment 1•25 years ago
|
||
Yup. We should do this with mail/news also.
Comment 2•25 years ago
|
||
David, are you suggesting that there should be a timer in mailnews onselect code or that the tree will do this for us?
Assignee | ||
Comment 3•25 years ago
|
||
The tree's keyboard navigation code should use timers before actually firing onselect i think, although this is tricky, since the selection really is moving.
Updated•25 years ago
|
Target Milestone: M13 → M15
Comment 4•25 years ago
|
||
targetting m15
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15 → M16
Assignee | ||
Updated•25 years ago
|
Target Milestone: M16 → M15
Assignee | ||
Updated•24 years ago
|
Summary: <tree> onselect should be controlled with a timer → [feature] <tree> onselect should be controlled with a timer
Updated•24 years ago
|
Comment 5•24 years ago
|
||
No time left in this release, resolving as later, putting on helpwanted radar
Reporter | ||
Comment 6•24 years ago
|
||
out for 6.0? I'd say this was very important to make mailnews not suck ;)
Comment 7•24 years ago
|
||
I'd hardly equate this with mail/news sucking. This operation will suck, but it is a rather strange way to scroll when mere selection changes the items' state.
Assignee | ||
Comment 8•24 years ago
|
||
It is a given that mail/news performance is going to suck in 6.0 in the initial release. Is it depressing? Yes. Is there anything we can do about it? No.
Reporter | ||
Comment 9•24 years ago
|
||
gee everyone sure is sad today :P
Comment 10•24 years ago
|
||
I'd like to develop a list of tree-related perf problems and prioritize them. I bet this one wouldn't be at the top of the list, but we should make the list.
Comment 11•24 years ago
|
||
reopening all latered bugs
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Comment 12•24 years ago
|
||
Moving all latered bugs to M20 as ordered by project manager. Although these bugs are now open, assigned and targetted, XPToolkit has no plans to fix/implement them in the current release cycle, if ever.
Target Milestone: M15 → M20
Comment 13•24 years ago
|
||
Mass move of all M20 bugs to M30.
Comment 15•24 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Reporter | ||
Comment 16•24 years ago
|
||
I thought this had been fixed? Marking as such....
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 18•21 years ago
|
||
*** Bug 193313 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
forget about comment 18, wrong bug number entered...
You need to log in
before you can comment on or make changes to this bug.
Description
•