moving recurring events by drag has issues

VERIFIED FIXED in Lightning 0.3

Status

defect
--
major
VERIFIED FIXED
13 years ago
9 years ago

People

(Reporter: dmose, Assigned: mattwillis)

Tracking

Trunk
Lightning 0.3

Details

(Whiteboard: [cal-ui-review+])

Attachments

(1 attachment)

Dragging a recurring event in the month view brings up the "this/all/cancel" dialog.  Selecting "This occurrence" causes the event to move as expected.  However:

1) Selecting "All occurrences" causes the event to incorrectly snap back to its pre-drag position and no occurrences are moved.

2) Selecting "cancel" simply makes the event disappear rather than snapping back to pre-drag position.  Forcing the view to refresh will put the event back to where it was supposed to be.
This is very visible and basic behavior; I think this needs to block 0.3.
Flags: blocking0.3+
Selecting "This occurrence" causes the event to move as expected. 

I cannot confirm this. Change the view afterwards and the event is lost!

> 1) Selecting "All occurrences" causes the event to incorrectly snap back to its
> pre-drag position and no occurrences are moved.

This works for me.
> 
> 2) Selecting "cancel" simply makes the event disappear rather than snapping
> back to pre-drag position.  Forcing the view to refresh will put the event back
> to where it was supposed to be.
> 

Confirmed.

using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060916 Calendar/0.3a2+
Sorry for bugspam. Second comment is nesecarry:

Changing a single occurrence to the past causes this event to be lost (see my previous comment). Changing it to the future causes this event to span multiple days (only DTEND seems to be changed correctly). You need to refresh views to see this happening.

Steps to reproduce:

1. create repeating event (repeating daily for 5 times)
2. in Month view: drag one event one week back or one week to future, choose "This occurrence only". 
3. change to multiweek view and back

Result: event gets lost in case of "one week back"
        event spans multiple days in case of "one week to future".
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
The key thing to note is that this bug is only in month view (and perhaps multiweek), and happens on weekly recurring events, not daily ones.

After some quick testing, I think this bug happens because when you move the event to another day, we don't change the RRULE to that day.

For example:
Take October 2006

    October 2006
 S  M Tu  W Th  F  S
 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

If you make an infinite recurring event for say the calendar meetings on Wednesdays starting on Oct 4, and then drag the Oct 4 event box to Sunday, Oct 1, the event will STILL be for WEDNESDAYS, not Sundays. As a result it doesn't appear on Oct 1, and the subsequent Wednesday occurrences don't move.
see my steps to reproduce in comment 3 with *daily* repeating events. I can still reproduce them with latest nightly!
(In reply to comment #6)
> see my steps to reproduce in comment 3 with *daily* repeating events

So noted. 

This is also replicateable using daily repeating events
Whiteboard: [needs patch]
As per bug 336952 comment 8, I think we should make dragging always apply to occurrences.
I moved the "This or all occurrences" dialog call to the else statement, so it is only hit if no aStartDate and aEndDate are passed in. (For example, when double-clicking an event box).

We also got to remove a bunch of parent/child offset code. Bonus.
Assignee: nobody → lilmatt
Status: NEW → ASSIGNED
Attachment #240056 - Flags: second-review?(dmose)
Whiteboard: [needs patch] → [patch in hand][needs review dmose]
Comment on attachment 240056 [details] [diff] [review]
rev0 - Makes modifyOccurrence always act on the occurrence for drags

r=dmose
Attachment #240056 - Flags: second-review?(dmose) → second-review+
Whiteboard: [patch in hand][needs review dmose] → [patch in hand][needs review dmose][cal-ui-review+]
Joey and I both think that at least (1), and, I suspect (2) are probably regressions.  He suggested that it would worthwhile to try and verify that one or both of these were regressions, since whatever the cause was may well have broken other things at the same time.  Adding qawanted keyword.
Keywords: qawanted
Whiteboard: [patch in hand][needs review dmose][cal-ui-review+] → [patch in hand][cal-ui-review+][needs testing]
Comment on attachment 240056 [details] [diff] [review]
rev0 - Makes modifyOccurrence always act on the occurrence for drags

Looks good to me.
Attachment #240056 - Flags: first-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #11)
> Joey and I both think that at least (1), and, I suspect (2) are probably
> regressions.  He suggested that it would worthwhile to try and verify that one
> or both of these were regressions, since whatever the cause was may well have
> broken other things at the same time.  Adding qawanted keyword.
> 

Drag and Drop in Month view was introduced in build 20060629 and the problem exists still then. (I never saw (1) happening but (2) is existing still then).
Keywords: qawanted
dragging an occurrence now always modifies this occurrence without a dialog.
-> Verified fixed.
Status: RESOLVED → VERIFIED
As I understand "This or all occurrences" dialog appears only when I want to edit the recurring events. When I move an occurrence by drag&drop it shouldn't appear. Am I right? But I'm not sure if it's intentional or not:
1)Switch to month view
2)Create repeating new event (for three days)
3)Move one occurrence to another day by drag&drop ("This or all occurrences" dialog doesn't appear- as I understand it's ok)
4)When you double click or want to delete the untouched occurrences "This or all occurrences" dialog appears. But when you double click or want to delete the moved occurrence "This or all occurrences" dialog doesn't appear-----> is it a bug?
Whiteboard: [patch in hand][cal-ui-review+][needs testing] → [cal-ui-review+]
You need to log in before you can comment on or make changes to this bug.