Closed Bug 501402 Opened 15 years ago Closed 15 years ago

Day View not updated correctly after deleting multiple events [Error "a.occurrence is undefined" in calendar-multiday-view.xml]

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: mmecca)

Details

(Keywords: regression, Whiteboard: [needed beta][no l10n impact])

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090630 Calendar/1.0pre (BuildID: 20090630051140)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090630 Shredder/3.0b3pre with Lightning 1.0pre (BuildID: 20090630032347)

Steps to Reproduce:
===================
1. Start Sunbird or Thunderbird + Lightning with clean profile
2. Switch to Day View and create two or more events
3. Press Ctrl+A or Ctrl+Click to select multiple events in the view
4. Press Delete to remove all selected events

Actual Results:
===============
The view is not correctly updated although the events have been deleted. Only the first selected event disapeared. The other events are still visible. Hint: The unifinder and the Today Pane has been updated correctly. Error Console shows the following messages multiple times:

Warning: reference to undefined property a.occurrence
Source file: chrome://calendar/content/calendar-multiday-view.xml Line: 533

Error: [Exception... "'[JavaScript Error: "a.occurrence is undefined" {file: "chrome://calendar/content/calendar-multiday-view.xml" line: 533}]' when calling method: [calIObserver::onDeleteItem]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///E:/sb/calendar-js/calUtils.js :: notifyFunc :: line 1221"  data: yes] 

STACK: 
1: [file:///E:/sb/calendar-js/calUtils.js:1224] notifyFunc
2: [file:///E:/sb/calendar-js/calUtils.js:1227] calListenerBag_notify
3: [file:///E:/sb/components/calCompositeCalendar.js:86] anonymous
4: [null:0] null
5: [file:///E:/sb/calendar-js/calUtils.js:1221] notifyFunc
6: [file:///E:/sb/calendar-js/calUtils.js:1227] calListenerBag_notify
7: [file:///E:/sb/calendar-js/calStorageCalendar.js:614] anonymous
8: [null:0] null
9: [file:///E:/sb/calendar-js/calTransactionManager.js:216] cT_doTransaction
10: [null:0] null

Source File: file:///E:/sb/calendar-js/calUtils.js Line: 1224
Looks like a regression between the 1.8.1 and the 1.9.0 branch:

Works using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/20080917 Sunbird/0.9

Fails using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre) Gecko/20080917 Calendar/0.6a1
Keywords: regression
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0? → blocking-calendar1.0+
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [needed beta][no l10n impact]
Attached patch Patch v1 — — Splinter Review
It appears that the references to the calendar-event-box's stored in the mSelectedChunks array are no longer valid after the clear method is called from the relayout method. Subsequent calls to internalDeleteEvent trigger the error when attempting to compare the a.occurrence.hashId value when a.occurrence is undefined during the mSelectedChunks.filter operation.

Proposed fix:
1) add a check for undefined in the a.occurrence property when calling mSelectedChunks.filter in the internalDeleteEvent method
2) clear out the mSelectedChunks array in the clear method as any entries are no longer valid
3) rebuild the mSelectedChunks array in the relayout method as the new calendar-event-box instances are created
Attachment #389403 - Flags: review?(philipp)
Assignee: nobody → matthew.mecca
Status: NEW → ASSIGNED
Attachment #389403 - Flags: review?(philipp) → review+
Comment on attachment 389403 [details] [diff] [review]
Patch v1

Fix looks fine and works just as well :-)

Thanks for taking care of a blocker bug, I really appreciate it!
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/cbf01c186ed7>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Can this be checked with the automatic Mozmill tests from Bug 500469, preferable for all views?
Flags: in-testsuite?
(In reply to comment #5)
> Can this be checked with the automatic Mozmill tests from Bug 500469,
> preferable for all views?

I don't see why not.  Merike, thoughts?
It would fit nicely in phase 2, yes.
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100313 Calendar/1.0b2pre
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: