274294 - drag and drop expects event box to have single class (categories colors)

Status: RESOLVED WORKSFORME

(Calendar :: Sunbird Only, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The drag and drop code, such as calendarViewClick, expects an eventbox to have a
single class.
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/dragDrop.js#41

However setEventboxClass, added for category colors by bug 171657, adds multiple
classes, even if there are no colors.
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendarWindow.js#667

Reproducible: Always
Steps to Reproduce:
Drag an event to a new hour in day view.
Actual Results:  
Doesn't drag.

Expected Results:  
Event moved to new hour.

Comment 1

[gekacheka]

Attachment: dragDrop.js patch: use className.split(" ")[0] == x to accomodate appended class names

(patch -l -p 2 -i file.patch)

Possible approach:  setEventboxClass always puts the original classname first,
so this code picks off the first class name and compares that.	(String.split("
")[0] should be the whole string if there are no spaces.)

Comment 2

[gekacheka]

Attachment: dragDrop.js patch: use className.split(" ")[0] == x to accomodate appended class names, use currentTarget (checked in)

(patch -l -p 2 -i file.patch)

Possible approach:  setEventboxClass always puts the original classname first,
so this code picks off the first class name and compares that.	
(String.split(" ")[0] should be the whole string if there are no spaces.)

Simplify by using event.currentTarget rather than event.target, so it is no
longer necessary act on nested label/description element, but instead will be
handled when event propagates to their parent eventbox.

(patch also fixes some strict javascript warnings.)

Comment 3

[Matthew (lilmatt) Willis]

gekacheka,
Is this a trunk patch? If so, do you know if it will work with the new interfaces?

Comment 4

[gekacheka]

Note that the events are mouse events, not calendar events.  So I don't think
any new interfaces are involved.

Comment 5

[Matthew (lilmatt) Willis]

The original file is full of tabs and crap that make your patch fail, so I'll
try and get that cleaned up first.

Using the latest code plus your patch, I wasn't able to drag an event around.
I got the following error repeatedly while trying:

JavaScript error: chrome://calendar/content/calendarWindow.js, line 494: invalid
'in' operand event.currentTarget

...so I can't test that this works. I'll add it to my r? queue so I remember to
look at it once things are working again, and I'll try to get the original file
cleaned up in the meantime.

Better idea?

Comment 6

[gekacheka]

Comment on attachment 168671 [details] [diff] [review]
dragDrop.js patch: use className.split(" ")[0] == x to accomodate appended class names, use currentTarget (checked in)

Looks like patch was checked in 2005-01-03.
(But can't verify it now because day view is broken.)

Comment 7

[Simon Paquet [:sipaq]]

(In reply to comment #6)
> (From update of attachment 168671 [details] [diff] [review] [edit])
> Looks like patch was checked in 2005-01-03.
> (But can't verify it now because day view is broken.)

Gekacheka can you verify, that this works now.

Comment 8

[gekacheka]

(In reply to comment #7)
> (In reply to comment #6)
> > (From update of attachment 168671 [details] [diff] [review] [edit] [edit])
> > Looks like patch was checked in 2005-01-03.
> > (But can't verify it now because day view is broken.)
> 
> Gekacheka can you verify, that this works now.
> 

Create an event in day view, say 10am.
Drag it to another time, say 2pm.

Expect:  event is moved.

Actual (as of 20050811 nightly w32):

  Error: calendarManagerDNDObserver is not defined
  Source File: chrome://calendar/content/calendar.xul
  Line: 1

Comment 9

[Joey Minta]

dragDrop.js has been removed.  gekacheka, is there any reason to keep this bug open?

Comment 10

[gekacheka]

No longer a problem with new views:  WORKSFORME