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

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 1

[David Hyatt]

Yup. We should do this with mail/news also.

Comment 2

[scottputterman]

David, are you suggesting that there should be a timer in mailnews onselect code
or that the tree will do this for us?

Comment 3

[David Hyatt]

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.

Comment 4

[Peter Trudelle]

targetting m15

Comment 5

[Peter Trudelle]

No time left in this release, resolving as later, putting on helpwanted radar

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

out for 6.0?

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

Comment 7

[Peter Trudelle]

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.

Comment 8

[David Hyatt]

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.

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

gee everyone sure is sad today :P

Comment 10

[Phil Peterson]

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

[Peter Trudelle]

reopening all latered bugs

Comment 12

[Peter Trudelle]

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.

Comment 13

[Peter Trudelle]

Mass move of all M20 bugs to M30.

Comment 14

[Peter Trudelle]

Mass move of M20 bugs to M30

Comment 15

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

I thought this had been fixed? Marking as such.... 

Comment 17

[Claudius Gayle]

handing off QA

Comment 18

[Frank]

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

Comment 19

[Frank]

forget about comment 18, wrong bug number entered...