Closed Bug 309734 Opened 14 years ago Closed 14 years ago

Double clicking on an empty space in the calendar should create a new event.

Categories

(Calendar :: Lightning Only, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: morty, Assigned: jminta)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050922 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050922 Firefox/1.4

Double clicking on an empty space in the calendar should create a new event,
just like in sunbird.

Reproducible: Always

Steps to Reproduce:
Dounbleclick somewhere in the calendar view.
Actual Results:  
Nothing hapens

Expected Results:  
A new Event should be created -> Sunbird

Related to bug 309426
Adds double click->New event abilities to the views.  the doubleclick event
handler wasn't getting called in calendar-multiday view, so this includes a
workaround for it.

The changes to the views are a subset of the changes shaver already gave r+ to
in the new views patch.  He mentioned vlad might need to take a look at this
too.
Assignee: shaver → jminta
Status: UNCONFIRMED → ASSIGNED
Attachment #197216 - Flags: first-review?(dmose)
OS: Windows 2000 → All
Hardware: PC → All
Comment on attachment 197216 [details] [diff] [review]
add double click to views

Im not comfortable landing a workaround fix like this without knowing what the
real problem is under the hood.  i.e. is there a gecko bug, is something else
in the calendar code eating the event, etc.  So Id prefer it if you could do
some more investigating to track down the lower-level problem.
Attachment #197216 - Flags: first-review?(dmose) → first-review-
OK, I've finally had a chance to look into this more.  Here's what's going on:

When the first click hit's onmousedown, the column's fgboxes.box (anonid=fgbox) gets the attribute "dragging" set to true.  
http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-multiday-view.xml#1174

This triggers the .css selector for that element to actually display the fgbox.
http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-multiday-view.css#53

However, once we hit mouseup, the 'dragging' attribute is again removed
http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-multiday-view.xml#938
which hides fgbox again.

Because these boxes keep coming into and out of "existence", a dblclick never actually makes it through the forest of events/targets.

Commenting out line 938 confirms that this is the essence of the problem.  I've experimented with moving that call around to later places in the code, but it becomes impossible to catch all the extra places where it would need to be called.  One possible solution would be to place it in a timeout greater than the longest time for a doubleclick.  However, leaving this box around for any period of time seems to be asking for trouble, in my opinion.

Therefore, I really think the original patch is the way to go for the multiday view.  It's not ideal, but in terms of code stability, I feel it's superior to the timeout solution.
What would you think about instead making it so that dragging doesn't actually start until the mouse actually moves somewhere?  This would seems to be more typical DND behavior...
(In reply to comment #4)
> What would you think about instead making it so that dragging doesn't actually
> start until the mouse actually moves somewhere?  This would seems to be more
> typical DND behavior...
> 

Right now, as soon as the user puts his mouse down, the time he is clicking at is shown above and below, indicating the time range for the event.  To me, this behavior is good.  Waiting until the mouse actually moves means that these times can't be shown (because their parent box isn't shown) until the user actually moves the mouse.

That being said, I do have a patch that implements this solution and it works without problems (other than the drag-times not instantly showing up).  Opinions welcome as to which solution is preferable.
Adopts the suggestion of not displaying the dragboxes until the user actually moves the mouse.
Attachment #202594 - Flags: first-review?(dmose)
Comment on attachment 202594 [details] [diff] [review]
add double click to views v2

r=dmose; thanks for the patch!
Attachment #202594 - Flags: first-review?(dmose) → first-review+
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
QA Contact: shaver → lightning
You need to log in before you can comment on or make changes to this bug.