179492 - getRangeCount returns 1 if one and two rows are selected

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[andreas 'dexxter' halter]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

might be similar to 171547, if one range is selected, this returns 1, same as if
two rows are selected, >2 rows make array-indice type number (eg 3 for 4
element-ranges).

guess this is a mixup off loop-handiness (for()...), and count.

Reproducible: Always

Steps to Reproduce:
1. create tree
2. select one row, hold down ctrl (dump getRangeCount)
3. select second row (dump getRangeCount)

Actual Results:  
dump1(step2) and dump2(step3) are identical

Expected Results:  
dump1 should be 1, dump2 should be 2

note that this was tested with ranges that are not joined. eg:

ex1:
row1. selected
row2. selected
row3. unselected
row4. selected
row5. selected

ex2:
row1. selected
row2. unselected
row3. selected

Comment 1

[Andrew Schultz]

this does not block Mozilla development

Comment 2

[Boris Zbarsky [:bzbarsky]]

mind attaching a small XUL testcase to this bug?

Comment 3

[Jan Varga [:janv]]

Attachment: test case

I'm not able to reproduce your problem with this testcase.

Comment 4

[Jan Varga [:janv]]

WFM

Comment 5

[andreas 'dexxter' halter]

Attachment: onclick testcase

second testcase, where event is fired upon 'onclick', not 'onselect', as i
can't get to the 'event' properties from 'onselect'. (i get the feeling this is
the same as: 66834, as your testcase works just fine here too).

Comment 6

[andreas 'dexxter' halter]

when using 'onclick' instead of 'onselect', getRangeCount is still wrong. (guess
this is due to: 66834). i need onclick as i have to access the event properties
afterwards, and couldn't do so with onselect.

Comment 7

[Jan Varga [:janv]]

Note that getRangeCount() is correct even with your testcase
You just check too early.
Using onselect is standard way to handle tree selection, it is also better to use
because selection may change after a keyboard input too.

Comment 8

[Jan Varga [:janv]]

please change resolution back to WORKSFORME if you figured out a solution to
your problem

Comment 9

[andreas 'dexxter' halter]

could not find any solution that 'worksforme', as my application reacts
depending on the cell the user clicked in, i cannot use the onselect handler (as
it doesn't pass the event). so either onselect passes an event, or
onclick/getRangeCount work as they should (getRangeCount is updated before event
is fired).

Comment 10

[Jan Varga [:janv]]

I think we could fix this by capturing the click event in tree.xml
Neil, wanna take it ?

Comment 11

[Jan Varga [:janv]]

I wonder if it's actually a good idea.
Someone may want to override onclick by himself.

Comment 12

[[e-mail]]

Jan, capturing won't help if the handler is listening on the event target.
In that case, handlers will fire in the order that they are added.
That is usually onXXX first, XBL second, addEventListener third.
So the workaround might be to use addEventListener instead.

Comment 13

[Jan Varga [:janv]]

ok, this isn't so critical and we have a workaround (onselect)

Comment 14

[Boris Zbarsky [:bzbarsky]]

What are our current priorities for core XUL toolkit bugs (as opposed to browser
UI bugs)?

Comment 15

[Jan Varga [:janv]]

well, you know, as an employee I need nsbeta1+ in the bug at least
Anyway, I'm current tree widget owner so I try to keep it in a good shape.
There are over 100 tree and listbox bugs and I don't think this bug is high
priority.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Yes, I understand all that.  I wasn't implying this bug should be higher
priority, just asking so I know what bugs I should make sure I call people's
attention to.

Comment 17

[Jan Varga [:janv]]

I don't think anyone is going to work on this given the plan to remove the XUL "tree" widget (bug 1446335).