453186 - Drag and drop issues in day/week view if mouse leaves the calendar view (with exceptions)

Status: RESOLVED WORKSFORME

(Calendar :: Calendar Frontend, defect)

Description

[Stefan Sitter [:ssitter]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/2008090109 Calendar/0.9pre

Steps to Reproduce:
===================
1. Start Sunbird with new profile
2. Switch to Week View
3. Start creating an event via drag and drop and drag the mouse down until you leave calendar view and hover the status bar
4. Start creating an event via drag and drop and drag the mouse up until you leave calendar view and hover the unifinder
5. Click into the main calendar view several times
6. Create an event. Drag and drop it to a different time or day
7. Switch to month view
8. Drag and drop the event to a different day

Actual Results:
===============
after 3.: drag and drop stops, no event is created
   Error: aItem has no properties
   Source File: chrome://calendar/content/calendar-multiday-view.xml
   Line: 3408

after 4.: drag and drop stops, no event is created
   Error: aItem has no properties
   Source File: chrome://calendar/content/calendar-multiday-view.xml
   Line: 1274

after 5.: each click produces the error
   Error: aItem has no properties
   Source File: chrome://calendar/content/calendar-multiday-view.xml
   Line: 3408

after 6.: the event disappeared. error in console:
   Error: this.mSelectedItems[i] has no properties
   Source File: chrome://calendar/content/calendar-multiday-view.xml
   Line: 3526

   Error: [Exception... "'[JavaScript Error: "this.mSelectedItems[i] has no properties" {file: "chrome://calendar/content/calendar-multiday-view.xml" line: 3526}]' when calling method: [calIObserver::onModifyItem]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///[...]/js/calUtils.js :: notifyFunc :: line 1257"  data: yes] STACK: 
   1: [file:///[...]/js/calUtils.js:1260] notifyFunc
   2: [null:0] null
   3: [file:///[...]/js/calUtils.js:1263] calListenerBag_notify
   4: [file:///[...]/components/calCompositeCalendar.js:78] anonymous
   5: [null:0] null

after 7.: event reappeared but error in console
   Error: item has no properties
   Source File: chrome://calendar/content/calendar-common-sets.js
   Line: 342

after 8.: drag and drop can not be started. error in console
   Error: a has no properties
   Source File: chrome://calendar/content/calendar-month-view.xml
   Line: 1437

Comment 2

[Stefan Sitter [:ssitter]]

Situation has improved using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090710 Calendar/1.0pre. 

When leaving the week view during drag and drop operation always the same error message is logged (see below). But the views seem to behave correctly afterwards, new drag and drop operation is possible.

Error: this.getSelectedItems is not a function
Source File: chrome://calendar/content/calendar-multiday-view.xml
Line: 1270

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Martin, whats the status of this bug? Do you have a WiP patch in the works? Please update the assigned to field accordingly.

Whoever actually fixes this bug, it would be nice if you could allow dragging events outside of the calendar view, i.e for dropping on the calendar list (bug 179484). If not here, please file a new bug.

We should take at least the exception fixes for 1.0, but this is not strictly needed for the beta.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v1

Actually, this patch wasn't as large as I expected and I already had half of it before I found this bug. So here it is, this should fix things.

The behavior is now (not sure how it was before) that when the event leaves the view, a drag session is invoked, which allows dropping in other places. Moving the event back over the calendar view makes it behave as if it were an externally dragged event, which means it can only be dropped into the allday slot.

I'm quite sure we had both a bug that its not possible to convert an event to an allday event by dragging (which this kind of fixes) and a bug that dragged events should display shadows when re-entering the multiday view. I can't find either right now.

Comment 5

[Markus Adrario [:Taraman]]

Comment on attachment 405699 [details] [diff] [review]
Fix - v1

Without this patch I get:
Error: this.getSelectedItems is not a function
Source File: chrome://calendar/content/calendar-multiday-view.xml
Line: 1286

with the patch it changes to:
Error: aItem is undefined
Source File: chrome://calendar/content/calendar-multiday-view.xml
Line: 2594

also the patch is bitrotten. (applied on comm-1.9.1)

therefore: r-

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v2

I couldn't reproduce the issue you mentioned, here is a de-bitrotted patch. Decathlon could you take over review?

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

This bug doesn't block 1.0, but fixing it would nevertheless be nice :)

Comment 8

[Decathlon]

Comment on attachment 547061 [details] [diff] [review]
Fix - v2

When dragging an event *upward* out the view, then dragging again inside the view (without release the mouse) an error appears in the console:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [calIDateTime.addDuration]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://calendar/content/widgets/calendar-widgets.xml :: addDropShadows :: line 382"  data: no]
 
After the steps mentioned above, if you stop dragging in the "all-day event zone" of the view and release the mouse, another messages appears (probably due to the first error):

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [calIDateTime.addDuration]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://calendar/content/widgets/calendar-widgets.xml :: onxbldragdrop :: line 533"  data: no]

No error in the bottom of the view.

Comment 9

[Martin Schröder [:mschroeder]]

Henry, it does not seem to be appropriate to mark a bug as RESOLVED FIXED without commenting which change (commit) or other bug report fixed the actual problem. I would suggest you use RESOLVED WORKSFORME and add a comment in which version of Thunderbird you have checked the behavior and found it working as expected.

Comment 10

[Henry Wilkes (they/them) [:henry-x]]

ok. I can't reproduce in 91