Closed
Bug 179492
Opened 23 years ago
Closed 7 years ago
getRangeCount returns 1 if one and two rows are selected
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: dexxter, Assigned: janv)
Details
Attachments
(2 files)
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 2•23 years ago
|
||
mind attaching a small XUL testcase to this bug?
Assignee | ||
Comment 3•23 years ago
|
||
I'm not able to reproduce your problem with this testcase.
Assignee | ||
Comment 4•23 years ago
|
||
WFM
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 5•23 years ago
|
||
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).
Reporter | ||
Comment 6•23 years ago
|
||
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
please change resolution back to WORKSFORME if you figured out a solution to
your problem
Reporter | ||
Comment 9•23 years ago
|
||
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).
Assignee | ||
Comment 10•22 years ago
|
||
I think we could fix this by capturing the click event in tree.xml
Neil, wanna take it ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 11•22 years ago
|
||
I wonder if it's actually a good idea.
Someone may want to override onclick by himself.
Comment 12•22 years ago
|
||
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.
Assignee | ||
Comment 13•22 years ago
|
||
ok, this isn't so critical and we have a workaround (onselect)
![]() |
||
Comment 14•22 years ago
|
||
What are our current priorities for core XUL toolkit bugs (as opposed to browser
UI bugs)?
Assignee | ||
Comment 15•22 years ago
|
||
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•22 years ago
|
||
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.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
Assignee | ||
Comment 17•7 years ago
|
||
I don't think anyone is going to work on this given the plan to remove the XUL "tree" widget (bug 1446335).
Status: NEW → RESOLVED
Closed: 23 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•