569120 - Investigate using modifier keys (e.g. Ctrl or Alt) to allow moving events by minutes on day/week views

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Decathlon]

In day/week views, when moving an event by drag and drop, the only positions allowed are full hours or 15 minutes multiples i.e. the event snap to only four possible positions inside an hour: xx:00 xx:15 xx:30 xx:45.
Drag and drop doesn't allow others positions with a different time, neither when modifying an existing event (position, starting and ending time), nor when creating a new one. The only way is modifying the event by opening the edit dialog.

Using a modifier key while dragging, could allow to move the events by minutes, or by a minimum interval allowed by the current pixels per minute value, in order to assign every starting or ending time without using the dialog.

This bug has been request in bug 535353 comment #3.

Comment 1

[Decathlon]

Attachment: patch with CTRL key

Maybe we could start with this patch which uses the Ctrl key as modifier key, but it can be changed with another key.
At the moment the Ctrl key is used to select the "parent" event when an event is outside of a recurrence rule, this patch works fine along with that function.
Ctrl key is also used for multiselection in multiday view, and this could be a problem. I've found bug 458050 that explicitly requests not to use the Ctrl key when events are moved/resized by drag'n'drop. 
There is also a request for creating copies of events by drag'n'drop with Ctrl key that could be take in count (bug 411069). In this case the Ctrl key in this patch should be changed with another modifier key because that function would need for sure that key.
I'm not sure if Linux or Mac need a different modifier key.

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 454481 [details] [diff] [review]
patch with CTRL key


(In reply to comment #1)

> Ctrl key is also used for multiselection in multiday view, and this could be a
> problem. I've found bug 458050 that explicitly requests not to use the Ctrl key
> when events are moved/resized by drag'n'drop. 
I think this bug is rather about when pressing ctrl and then starting the drag action. This bug would rather make use of ctrl while in the drag action, which is ok.


> There is also a request for creating copies of events by drag'n'drop with Ctrl
> key that could be take in count (bug 411069). In this case the Ctrl key in this
> patch should be changed with another modifier key because that function would
> need for sure that key.
I think we should take this into account. When using the windows/linux filesystem explorers, pressing CTRL while dragging creates a copy. What about using the shift-key? This should be OS independent too.



>               if (ignore) {
>                   document.calendarEventColumnDragging = null;
>-                  col.mDragState = null;
>+                  dragState = null;
>                   return;
>               }
Does this really work out as expected? You want to set col.mDragState = null, but you're changing the local variable dragState to null instead. I tried the following in xpcshell:

js> var f = { foo: 333 };
js> f.foo
333
js> let g = f.foo;
js> g = null;
null
js> f.foo
333

Therefore, you should still be setting col.mDragState here.


>           document.calendarEventColumnDragging = null;
>-          col.mDragState = null;
>+          dragState = null;
>         ]]></body>
>       </method>

Same here.

> 
>           //dump ("AMY: " + aMouseY + " boY: " + this.parentNode.boxObject.screenY + "\n");
>-          var frameloc;
>+          let frameloc;
Go ahead and get rid of this dump statement while you're here.



Otherwise this patch looks great, good work!

r- only to get a new patch with nits fixed and modifier changed to shift (if you agree).

Comment 3

[Decathlon]

Attachment: patch with Shift key

Patch with modifier key changed, nits (and big errors ;-)) fixed.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 470576 [details] [diff] [review]
patch with Shift key

Looks good, r=philipp

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ae1353ef08a2>
-> FIXED

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/5f5d62f1b746>

a=philipp