Closed
Bug 309734
Opened 19 years ago
Closed 19 years ago
Double clicking on an empty space in the calendar should create a new event.
Categories
(Calendar :: Lightning Only, defect)
Calendar
Lightning Only
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: morty, Assigned: jminta)
References
Details
Attachments
(2 files)
|
5.08 KB,
patch
|
dmosedale
:
first-review-
|
Details | Diff | Splinter Review |
|
6.29 KB,
patch
|
dmosedale
:
first-review+
|
Details | Diff | Splinter Review |
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
| Assignee | ||
Comment 1•19 years ago
|
||
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)
Updated•19 years ago
|
OS: Windows 2000 → All
Hardware: PC → All
Comment 2•19 years ago
|
||
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-
| Assignee | ||
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
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...
| Assignee | ||
Comment 5•19 years ago
|
||
(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.
| Assignee | ||
Comment 6•19 years ago
|
||
Adopts the suggestion of not displaying the dragboxes until the user actually moves the mouse.
Attachment #202594 -
Flags: first-review?(dmose)
Updated•19 years ago
|
Blocks: lightning-0.1
Comment 7•19 years ago
|
||
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+
| Assignee | ||
Comment 8•19 years ago
|
||
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
QA Contact: shaver → lightning
You need to log in
before you can comment on or make changes to this bug.
Description
•