Closed Bug 12288 Opened 25 years ago Closed 25 years ago

[Dogfood][Tree] Shift-click doesn't work in tree control

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: selmer)

References

Details

(Whiteboard: [PDT+] hack completed) 

Open up the Mail 3pane.
Load a folder and click on a message
Use shift key and mouse button to do multiple selection.  Nothing happens.
however, using the ctrl-key and the mouse button works fine.

Testing this in Mail depends on me checking in my changes which I haven't yet.
Hopefully before tomorrow's builds.  But I'm hoping this is a general tree
problem!
Just to make this clear, I'm using the new onselect event handler. I don't know
if that makes a difference.
Status: NEW → ASSIGNED
Target Milestone: M10
yes.  You've caught me in mid-implementation.  Ranged selection hasn't been
implemented in the new selection API yet.
Blocks: 12716
mass targetting m11
My hands have deteriorated to the point where I can no longer type.  I need
help.  If you think you can fix this bug on your own, please take it away from
me.  If you'd like to volunteer to be my hands for a specific bug, then I'll be
happy to come up to your cube and sit with you and fix the bug (assuming you
have the patience for that).
I will be your hands here.
Assignee: hyatt → putterman
Status: ASSIGNED → NEW
giving to putterman, who hopefully will agree to be my typist on this one.
no problem.  Just let me know when.
Blocks: 15008
*** Bug 15094 has been marked as a duplicate of this bug. ***
Assignee: putterman → bienvenu
I'll be Dave's typist for this one - perhaps tomorrow, Thursday?
Status: NEW → ASSIGNED
Is anyone working on this.  If not, here's the algorithm I was thinking of:

In nsTreeFrame::RangedSelection, get the last selected item from the tree's
selected list and then figure out whether the shift-selected item is above or
below it and then select everything between those two items if they aren't
already in the selected list.

The more I think about it though, this seems like it will be really slow for
large selections, especially if I'm doing the duplication check.  Any other
ideas?  Perhaps a way of keeping track of ranges rather than individually
selected items?
OK, I did a little more searching and it looks like I can just call
nsXULTreeElement::SelectCellRange which also needs to be implemented.  And
duplication is an easy check since I can just check if an item is selected
before adding it to the selection list.
Assignee: bienvenu → alecf
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
wondered how long that would take to get to me :)
mass-moving bugs I can't fix for M11 to M12
*** Bug 18104 has been marked as a duplicate of this bug. ***
Summary: Shift-click doesn't work in tree control → [Tree] Shift-click doesn't work in tree control
Triage tree bugs. These to M13
*** Bug 18245 has been marked as a duplicate of this bug. ***
This is dogfood for mail-news -- the only way to get through a big folder by
mass-deleting messages or mass marking unread.
Summary: [Tree] Shift-click doesn't work in tree control → [DOGFOOD] [Tree] Shift-click doesn't work in tree control
Whiteboard: [PDT+]
Putting on PDT+ radar.
Blocks: 18951
Whiteboard: [PDT+] → [PDT+] 12/3
adding steve to CC because he was interested in this.
marking PDT+ 12/3 for now
Assignee: alecf → selmer
Status: ASSIGNED → NEW
Whiteboard: [PDT+] 12/3 → [PDT+] decision on hack by 11/24
You're too fast :-)  Reassigning to myself so Alec can concentrate on tree
scrollbars.

My plan is to just see how it works with today's tree implementation and see if
we can do a reasonable hack like only allowing a certain number of items in the
range.  More graceful stuff and the "random access" stuff will have to be post
dogfood.
Whiteboard: [PDT+] decision on hack by 11/24 → [PDT+] decision on hack by 11/29
Steve's wife had a baby on Sunday.  Steve is planning on coming in on Monday the
29th the finish the bug or pass to Alec Flett.  Changing hack decision to
11/29.  I did read in a status report that Steve and David H. made some progress
on this bug.  David, did you want to add anything?
*** Bug 20186 has been marked as a duplicate of this bug. ***
giving me rest of phillips open qa contact bugs, sorry for spam
adding myself to CC

Steve has given me a patch but I haven't had a chance to  take a look at it
because I have other PDT bugs. Hope to get to this tomorrow.
Ok, what's the update on this bug?  Steve is back now.  Please update the status
whiteboard with a projected fix date.
Status: NEW → ASSIGNED
Depends on: 20268
Whiteboard: [PDT+] decision on hack by 11/29 → [PDT+] hack by 12/10
To get something in quickly, I can check in the hack without the dependent
performance improvements implied in bug 20268.  This will get shift+click
selection working at an adequate performance to meet Akkana's needs (assuming it
works on Linux as well as it does on Windows.)  The performance work in 20268 is
not required for correct operation of shift+click.  On the other hand, this hack
doesn't provide "correct operation" either, just something good enough to get by
for now.

To finish this feature, the shift+click behaviors from 4.x need to be
incorporated in addition to honoring the tree node open/close state.
Yeah, I never got to actually try the file you sent me, but I did a diff, and it
looked good. If it's performing even semi-decently, I'd at least check that in.
Howdy daver!

alecf and I just nailed the "jumping" problem that occurred when you selected a
node after scrolling a previously selected node offscreen.  This should clear
the way for selmer to check his code in.

selmer, go for it!
Excellent.  Thanks for helping everyone.
*** Bug 21248 has been marked as a duplicate of this bug. ***
Summary: [DOGFOOD] [Tree] Shift-click doesn't work in tree control → [Tree] Shift-click doesn't work in tree control
Whiteboard: [PDT+] hack by 12/10 → PDT hack completed
Removing Dogfood and PDT+ monickers since the PDT hack has been checked in.  The
bug won't be closed since there is a lot of work left to complete this feature.
Is it better to close this bug and open a new one?
I'd rather preserve all the history in this bug.  Removing the PDT+ should have
taken it off your radar and made it just a normal bug again.  I'll do it the
other way if that's requested, but then I'll want to copy a lot of stuff out of
this bug into the new one.

Let me know, I'll open a new bug on request.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Summary: [Tree] Shift-click doesn't work in tree control → [Dogfood][Tree] Shift-click doesn't work in tree control
Whiteboard: PDT hack completed → [PDT+] hack completed
OK, marking fixed to get it on the radar for QA.  Thread continues in bug 21462.

Adjusting summary and whiteboard back since I'm closing this now.
Target Milestone: M13 → M12
Status: RESOLVED → VERIFIED
verified shift click working
No longer blocks: 18951
You need to log in before you can comment on or make changes to this bug.