Closed
Bug 474451
Opened 15 years ago
Closed 15 years ago
Dragging the scrollbar grip in the calendar list doesn't scroll the list
Categories
(Calendar :: General, defect)
Calendar
General
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b1
People
(Reporter: ssitter, Assigned: Fallen)
Details
(Keywords: regression)
Attachments
(1 file)
6.55 KB,
patch
|
berend.cornelius09
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090120 Calendar/1.0pre (BuildID: 20090120031333) Steps to Reproduce: 1. Create new calendars until the scrollbar is visible in the calendar list 2. Scroll the list by dragging the scrollbar grip up and down Actual Results: The list doesn't scroll. Instead a drag and drop operation is started to reorder the calendars. Expected Results: Dragging the scrollbar grip works like in any other scrollbar. Most probably regressed by Bug 266249.
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → philipp
Flags: blocking-calendar1.0+
Assignee | ||
Comment 1•15 years ago
|
||
This patch fixes the issue described and also a few other DND problems we've been having: * Dragging of calendars anywhere doesn't cause errors or view drop shadows * Dragging of events doesn't allow drop except in - view (body) - richlistbox in today pane I've noticed the drop shadows don't get removed when leaving the view but this is a bug that also exists without my patch.
Attachment #357935 -
Flags: review?(Berend.Cornelius)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review]
Updated•15 years ago
|
Status: NEW → ASSIGNED
Comment 2•15 years ago
|
||
Comment on attachment 357935 [details] [diff] [review] Fix - v1 >I've noticed the drop shadows don't get removed when leaving the view but this >is a bug that also exists without my patch. This is the reason why Bug 416138 - Moving of all-day-events in weekview not possible, but shows possibility was reopened. I will take care of this in the next days. >+ if (!session.sourceNode || !session.sourceNode.sourceObject) { >+ // No source item? Then this is not for us. >+ return; >+ } We have this query also in the "dragdrop" event of the binding unfortunately after session.sourceNode.sourceObject has been used. Maybe you could place it at the beginning of the event. This causes an error when you try to drag a calendar into the calendar-view. Dropping a task on the agenda-listbox throws an error, regressed by bug 471973 - Make use of alarm interface in backend code. We are using an "aEvent" object where only a "aTask" object is available. The patch looks very good! r=berend
Attachment #357935 -
Flags: review?(Berend.Cornelius) → review+
Assignee | ||
Comment 3•15 years ago
|
||
(In reply to comment #2) > We have this query also in the "dragdrop" event of the binding unfortunately > after session.sourceNode.sourceObject has been used. Maybe you could place it > at the beginning of the event. This causes an error when you try to drag a > calendar into the calendar-view. I see, there is a task dnd patch up for review where I touch more code in this area. I'll fix that there. > > Dropping a task on the agenda-listbox throws an error, regressed by bug 471973 > - Make use of alarm interface in backend code. We are using an "aEvent" object > where only a "aTask" object is available. I fixed this in a different patch thats up for review. Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ba01c954461c> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review]
Assignee | ||
Updated•14 years ago
|
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•