369689 - In day and week views, events ending at midnight cannot be resized to a smaller size using the mouse

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Luc Mousseau]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

When an event's end date / time is set to midnight (ie: 00:00 the next day), in day and week views, if you try to resize the event using the mouse to an earlier time, it will actually resize the event to the selected time the NEXT day.

Reproducible: Always

Steps to Reproduce:
1. Create event and set the end time to 00:00 (ie: From: 08/02/2007 15:00 To: 09/02/2007 00:00).
2. In week or day view, using the mouse to resize the event, set the end time to something earlier, ie: 22:00.

Actual Results:  
The end date/time will be set to 22:00 the next day (09/02/2007).

Expected Results:  
The end date/time should be set to 22:00 earlier the same day (08/02/2007).

Happens in all versions of calendar and lightning. The issue is obviously that because midnight is defined as 00:00 the next day, rather than 24:00 the same day, it apparently doesn't know to reduce the date by one day when going smaller. 

I could see a nice side-effect of fixing this bug could be the ability to change the start/end date range over multiple days using the mouse by dragging sideways (which also can't currently be done).

Comment 1

[Martin Schröder [:mschroeder]]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070209 Calendar/0.4a1.

Comment 2

[Luc Mousseau]

Attachment: Patch v1 - Resizing an event using the mouse sets day to selected handle

Looking into this bug again it occurred to me that the issue isn't just when you resize an event ending on midnight using the end grippy, but also when you resize using the "top" grippy on a later day of an event which spans more than one day.

For example, if I have an event which spans two days, from April 11th 1pm to April 12th 1pm, and using the grippy at the TOP of April 12th, since I can only drag down from there, when I release the mouse at say 8am, it should set the start date to April 12th at 8am, not April 11th at 8am. And vice-versa for an event ending at midnight on a day, when dragging to an earlier time (as stated in my original report).

The patch sets the date to the date of the column where you click/drag the grippy.

Only one issue appears to exist with this now and it's due to Bug 368982, where it appears at least to me, that the bottom grippy is not available for events of smaller than 45 minutes in length.

Comment 3

[Martin Schröder [:mschroeder]]

Comment on attachment 261362 [details] [diff] [review]
Patch v1 - Resizing an event using the mouse sets day to selected handle

I'm no reviewer. Shifting review to Michael.

Comment 4

[Michael Büttner (no reviews TFN)]

Comment on attachment 261362 [details] [diff] [review]
Patch v1 - Resizing an event using the mouse sets day to selected handle

I can't find anything wrong with this patch, looks fine to me. But I'm a bit concerned about how events spanning more than a single day are handled. Should it really be possible to drag the end/start of the transition from one day to another? I'd like Christian to comment on this. Most probably, we'll handle any further work in a spin-off bug and just let this one in.

Christian, just for clarification, with this patch in place it looks like this:

---------
|   | c |
|   | * |
| a | * |
| * | d |
| * |   |
| b |   |
---------

'a' is the start-grippy for the start of the event, 'b' is the end-grippy of the transition from first day to second day (which can be dragged upwards/downwards), 'c' is the start-grippy of the transition into the second day (which can be dragged as well), 'd' is the end-grippy of the event. 'a' and 'd' can be dragged as usual. I'm talking here about the possibility to modify 'b' and 'c'. furthermore, e.g. 'b' can only be dragged within the first day, and always results in the event to end on the first day, the user doesn't have the possibility to drag sideways. what's your opinion on this?

Comment 5

[Christian Jansen]

We should go with the patch, looks fine for me, too.
I've created a spin-off bug #377744 for hunting down usability issues.

Comment 6

[Michael Büttner (no reviews TFN)]

Comment on attachment 261362 [details] [diff] [review]
Patch v1 - Resizing an event using the mouse sets day to selected handle

r=mickey as per my comment #4. thanks for the patch.

Comment 7

[Michael Büttner (no reviews TFN)]

This is a pretty low risk patch and the issue could be visible. Any votes for taking this before 0.5 has been released?

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

My experience has been that the datetime-modification code in the UI tends to be a delicate thing. This patch might be fine, i don't know. But I think there is some hidden risk in taking it. And because i think it's not that visible, i'd like to hold it off. 

Comment 9

[Michael Büttner (no reviews TFN)]

Sold, we hold it off.

Comment 10

[Simon Paquet [:sipaq]]

Fix checked in on trunk and branch.

Comment 11

[Andreas Treumann]

Verified in latest lightning (2007071603) and sunbird (20070716) builds, task is fixed.