405499 - Task list behaves erratic after deleting multiple tasks at once

Status: VERIFIED FIXED

(Calendar :: Tasks, defect)

Description

[Stefan Sitter [:ssitter]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.10pre) Gecko/2007112606 Calendar/0.8pre

Steps To Reproduce:
1. Start Sunbird with clean profile
2. Create 2 new dummy tasks named "1" and "2".
3. Select all 2 tasks and press Delete keyboard button
4. Create a new task named "3"
5. Click Title row header to sort tasks by title
6. Click Title row header to sort tasks by title again
7. Click Title row header to sort tasks by title again

Actual results:
after step 3: task list is empty
after step 4: task "2" is shown again
after step 5: task "2" is still shown
after step 6: task "3" is shown
after step 6: task "2" is shown again

Expected results:
after step 4 and following: task "3" is shown

Comment 1

[Stefan Sitter [:ssitter]]

Regression Range:
  WORKS in Sunbird 0.8pre (2007-11-21-05)
  FAILS in Sunbird 0.8pre (2007-11-22-05)
  
Checkins during regression range: http://tinyurl.com/32ko8c

Seems to be caused by the checkin for Bug 253396.

Comment 2

[Stefan Sitter [:ssitter]]

Minor regression compared to Sunbird 0.7 but might lead to missed tasks due to the incorrect display. In my opinion this should be fixed for 0.8.

Comment 3

[Omar Bajraszewski]

Also when you delete completed tasks from task mode list in lightning they don't disappear at once. Some of the deleted tasks are still visible. You need to switch to different window and back to Lightning to remove them

Comment 4

[Michael Büttner (no reviews TFN)]

Attachment: patch v1

The initial problem is that the internal data is held in an array (items listed by index) and an associative array (items sorted by hash-id). the latter is used for o(1) lookup in case we're given an item and need it's index in the array (which identifies its position in the tree). deleting an item removes the element from both data structures, but the indices held in the map are no longer valid. in this case it's necessary to recreate the map (this is what the attached patch does). unfortunately this defeats the whole purpose of the map in the first place. but i'm leaving the optimization of the task view for some other day and move ahead with more important stuff.

Comment 5

[Daniel Boelzle [:dbo]]

Comment on attachment 292422 [details] [diff] [review]
patch v1

>+                  
>+                  this.binding.recreateHashTable();
looks a bit brute-force to me, but r=dbo

Comment 6

[Michael Büttner (no reviews TFN)]

patch checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED

Comment 7

[Stefan Sitter [:ssitter]]

Verified using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12pre) Gecko/2007121105 Calendar/0.8pre.