Closed Bug 351870 Opened 18 years ago Closed 13 years ago

unable to unselect single event from a group of selected events in main view

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: damian.publicemail, Assigned: Taraman)

References

Details

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Calendar/0.3a2+ it was not big problem if multiselection in main view was disabled, however because of bug 321384 it could be nice if I can select and unselect events using main view - right now it is supported only via unifinder Reproducible: Always Steps to Reproduce: 1. create two events 2. select first one (press it) 3. press CTRL and click second event 4. do not release CTRL and click again second event Actual Results: second event is editable - I can modify title Expected Results: second event should not be selected
(In reply to comment #0) > Steps to Reproduce: > 1. create two events > 2. select first one (press it) > 3. press CTRL and click second event > Expected Results: > second event should not be selected I think CTRL+click was introduced to allow multiple selection. So I think this works as expected. Normal click on other events unselect the previous selected events too. I think the rest is covered with Bug 350951.
This bug requests that a second Ctrl+Click deselects the event again. This is common behaviour in other applications (e.g. Windows Explorer) and makes sense if during a long selection-procedure one is picked by fault. This is not covered by Bug 350951.
Summary: unable to unselect event from main view → unable to unselect single event from a group of selected events in main view
(In reply to comment #2) > This bug requests that a second Ctrl+Click deselects the event again. This is > common behaviour in other applications exacly, it works how you described for unifinder so should be similar for main view right now you can not deselect events using main view
*** Bug 355290 has been marked as a duplicate of this bug. ***
Whiteboard: [litmus testcase wanted]
Flags: in-litmus?
Whiteboard: [litmus testcase wanted]
I stumbled across the same issue. I agree with Comments 2 & 3 that deselecting events should be possible. Especially when you select a large number of events and misclick one shortly before being done - it is very annoying. Since this is idle now for a long time: any comments on how we should handle this?
Assignee: nobody → Mozilla
Status: NEW → ASSIGNED
OS: Windows XP → All
I'd love to see this fixed as originally suggested, its nice polish. What currently happens on the second click is that the inline editing mode starts up. I guess you'd just need to make sure that event.ctrlKey is false when entering editing mode and also doublecheck that ctrl+click also removes an item from the selection.
working on this bug showed me that the whole selection code seems to be quite buggy. for example: - if you click two events very quick after each other with ctrl pressed, the first event gets deselected, because the select-function only takes into account the currently selected items and no "pending selects" - in day/multiday view, if you accidentally hit a grippy while "multiselecting", only the currently clicked event gets selected. - events selected in the unifinder don't get selected in the views, because these don't handle the "itemselect" event. Searching for existing bugs for this behaviour I stumbled across Bug 639447 which should help sorting out this problems. For now I could just go ahead and adress the single problem from this bug in a small patch to get this solved at least.
Depends on: 639447
Markus, I'd also not be sad if you would take over the patch I wrote over there ;-) If you'd rather do small fixes now, go ahead and address the single problems as you mentioned.
Attached patch allows deselection of items in views (obsolete) (deleted) β€” β€” Splinter Review
This patch allows for deselection. Philipp, I know your request queue is quite crowded. I'm just not sure if mschroeder or ssitter are doing reviews at the moment, because the entries in their queues are quite old. Feel free to reassign review. known issues: see comment #7 These are not caused nor addressed in this patch and will be treated in seperate bugs.
Attachment #589013 - Flags: review?(philipp)
No longer depends on: 639447
Attached patch Patch V1.1 (deleted) β€” β€” Splinter Review
On trying further I discovered, that you can easily lose a whole selection, if you accidentally click on a free space in the view. So added inhibition to that deselection logic when ctrl/meta is pressed.
Attachment #589013 - Attachment is obsolete: true
Attachment #589050 - Flags: review?(philipp)
Attachment #589013 - Flags: review?(philipp)
Comment on attachment 589050 [details] [diff] [review] Patch V1.1 Review of attachment 589050 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, r=philipp and approval for comm-aurora Do you still have commit access, or is this checkin-needed? ::: calendar/base/content/calendar-view-core.xml @@ +286,5 @@ > } > + let items = this.calendarView.mSelectedItems.slice(); > + if (event.ctrlKey || event.metaKey) { > + if (this.selected) { > + debugger; One debugger statement slipped in
Attachment #589050 - Flags: review?(philipp)
Attachment #589050 - Flags: review+
Attachment #589050 - Flags: approval-mozilla-aurora+
(In reply to Philipp Kewisch [:Fallen] from comment #11) > Do you still have commit access, or is this checkin-needed? I had the reactivated hg-account reactivated the last days. I believe the rights are the same as before. > > + debugger; > > One debugger statement slipped in oops. ;-)
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Target Milestone: 1.0 → 1.3
No longer blocks: 719193
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: