Closed Bug 355282 Opened 13 years ago Closed 8 years ago

Click and Dragging a new event can't be cancelled by Escape

Categories

(Calendar :: Calendar Views, defect, minor)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tbullock, Assigned: Fallen)

References

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-1.2 Firefox/1.5.0.7
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.3rc1/lightning-0.3rc1.linux.xpi

In the calendar extension, it isn't possible to escape creating a new event by pushing escape while dragging a new event area.

Reproducible: Always

Steps to Reproduce:
1.In the calendar screen week view click and drag to create a new event but don't release the mouse button.
2.Try to cancel new event creation by pushing escape while mouse is still held down


Actual Results:  
Escape has no effect on creation of new event.  In other words, once you start to create an event, their is no way to stop it.

Expected Results:  
New event area should disappear with no new event created

It is possible to delete an event after it has been created... but this step should not be necessary.
Duplicate of Bug 343268?
I don't think so.

Bug 343268 refers to click/dragging in the month view, which I can't even do in the 0.3RC1 release.

This bug is encountered in the week view.

-Ted
This is about creating a new event per click & drag and the Escape key in the day/week view (definitively not a duplicate of bug 343268).

I can confirm this "bug", but:
Is canceling this action per Escape key a suggestive feature? Is this feature intended by the developers?
OS: Linux → All
Hardware: PC → All
(In reply to comment #3)
> I can confirm this "bug", but:
> Is canceling this action per Escape key a suggestive feature? Is this feature
> intended by the developers?
From end-user point of view this is so natural operation that should be supported
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [litmus testcase wanted]
This bug can either be fixed the quick-n-ugly way, by adding a keypress listener, or the harder (better, in my mind) way of generalizing the month view's DND stuff so it can be shared here too.  (The main problem is that the week/day view doesn't use the actual dnd interfaces, but merely hacks its way into appearing to support dragging.)  Thoughts?
Which implementation method would be easier to maintain in the future?  The mechanism that introduces the most control is probably the way to go.
Flags: in-litmus?
Whiteboard: [litmus testcase wanted]
Duplicate of this bug: 458046
Attached patch Fix - v1 โ€” โ€” Splinter Review
Lets go with quick-and-ugly for now until the view is actually rewritten
Assignee: nobody → philipp
Status: NEW → UNCONFIRMED
Ever confirmed: false
Attachment #568344 - Flags: review?(bv1578)
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Comment on attachment 568344 [details] [diff] [review]
Fix - v1

Looks good.
After the ESC key has been pressed, the dragged event remains selected. I don't know if this is a right behavior, but it's consistent with the drag and drop in month/multiweek view.
r+
Attachment #568344 - Flags: review?(bv1578) → review+
(In reply to Decathlon from comment #9)
> After the ESC key has been pressed, the dragged event remains selected. I
> don't know if this is a right behavior, but it's consistent with the drag
> and drop in month/multiweek view.
Yeah, that should be fine. Thanks for the note!
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ba59002a7b9d>
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Backported to comm-aurora <http://hg.mozilla.org/releases/comm-aurora/rev/2874f3c04f62>
Target Milestone: Trunk → 1.0b9
Backported to comm-beta <http://hg.mozilla.org/releases/comm-beta/rev/341a7f0c5818>
Target Milestone: 1.0b9 → 1.0b8
You need to log in before you can comment on or make changes to this bug.