[feature] <tree> onselect should be controlled with a timer

RESOLVED FIXED in Future

Status

()

P3
normal
RESOLVED FIXED
19 years ago
15 years ago

People

(Reporter: bugs, Assigned: hyatt)

Tracking

({helpwanted})

Trunk
Future
x86
Windows 95
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13
(Assignee)

Comment 1

19 years ago
Yup. We should do this with mail/news also.

Comment 2

19 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

19 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

19 years ago
Target Milestone: M13 → M15

Comment 4

19 years ago
targetting m15
(Assignee)

Updated

19 years ago
Target Milestone: M15 → M16
(Assignee)

Updated

19 years ago
Target Milestone: M16 → M15
(Assignee)

Updated

19 years ago
Summary: <tree> onselect should be controlled with a timer → [feature] <tree> onselect should be controlled with a timer

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Keywords: helpwanted
Resolution: --- → LATER

Comment 5

19 years ago
No time left in this release, resolving as later, putting on helpwanted radar
out for 6.0?

I'd say this was very important to make mailnews not suck ;) 

Comment 7

19 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

19 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.
gee everyone sure is sad today :P

Comment 10

19 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

19 years ago
reopening all latered bugs
Status: RESOLVED → REOPENED
Resolution: LATER → ---

Comment 12

19 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

19 years ago
Mass move of all M20 bugs to M30.

Comment 14

19 years ago
Mass move of M20 bugs to M30
Target Milestone: M20 → M30

Comment 15

19 years ago
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
I thought this had been fixed? Marking as such.... 
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 17

19 years ago
handing off QA
QA Contact: claudius → jrgm

Comment 18

15 years ago
*** Bug 193313 has been marked as a duplicate of this bug. ***

Comment 19

15 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.