384726 - Todo items are duplicated (ICS Calendar only)

Status: VERIFIED FIXED

(Calendar :: Tasks, defect)

Description

[Alistair Low]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: 2007061403

After updating Lightning to 0.5 RC2, I now have duplicate items in the todo list. I have 5 items and the full list seems to be repeated 5 times. 

In the middle of reporting this bug, I tried opening the first task with a double click and then clicking 'Ok' to close the dialog, which worked and the duplicates for that task disappeared. Repeating this for all but one of the tasks removed the duplicates. With the last task, only one of the duplicates was removed, there were still 4 instances with that name in the todo list.

Deselecting and then reselecting the calendars on the calendars tab seems to refresh the todo list to only show one instance of each task.

Reproducible: Didn't try

Steps to Reproduce:
1. Update to Lightning 0.5 RC2.
2. Create 1 or more tasks.
3. Restart Thunderbird.
Actual Results:  
There are multiple instances of each task in the todo list.

Expected Results:  
There should only have been one instance of each task in the todo list.

Comment 1

[Omar Bajraszewski]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4)
> Gecko/20070515 Firefox/2.0.0.4
> Build Identifier: 2007061403
> 
> After updating Lightning to 0.5 RC2, I now have duplicate items in the todo
> list. I have 5 items and the full list seems to be repeated 5 times. 
> 

What version of lightning have you updated from?

Comment 2

[Daniel Boelzle [:dbo]]

(In reply to comment #0)
> Steps to Reproduce:
> 1. Update to Lightning 0.5 RC2.
> 2. Create 1 or more tasks.
> 3. Restart Thunderbird.
> Actual Results:  
> There are multiple instances of each task in the todo list.

Seems to be not that easy. I did that, but can't reproduce the bug. Could you elaborate a bit more what needs to be done, please?

Comment 3

[Alistair Low]

I updated from Lighting 0.5 RC1, running under Thunderbird 2.0.0.4

I'll see if I can reproduce it with a fresh profile.

Comment 4

[Alistair Low]

Steps to reproduce:
1. Update to Lightning 0.5 RC 2
2. Create a new calendar: http://www.icalx.com/public/alistairlow0/test.ics
3. Restart Thunderbird

Comment 5

[Sebastian Schwieger]

Attachment: test calendar

Confirmed without doing the last step (restart). After restart every todo was shown only once. I attach the calendar for reference.

Lightning 2007061403 and Thunderbird 2.0.0.4

Comment 6

[Daniel Boelzle [:dbo]]

Ok, it seems that bug 382840 has uncovered a race condition at startup of the todo list (the mentioned fix now queues any getItems() calls until the ics file is fully loaded). Starting up thunderbird, the items appear doubled, reloading the calendar they appear correct.

Comment 7

[Daniel Boelzle [:dbo]]

Attachment: don't add same item again

Brute-force fix to avoid adding the same item twice.

Comment 8

[Daniel Boelzle [:dbo]]

In general I am unsure whether we should fix this at all, because the task UI will be reworked. We may take this for 0.5, setting blocking-0.5?.

Comment 9

[Michael Büttner (no reviews TFN)]

Comment on attachment 268780 [details] [diff] [review]
don't add same item again

>+                for (var i=0; i < this.childNodes.length; i++) {
>+                    var elem = this.childNodes[i];
>+                    if (elem.todo.hasSameIds(aTodo)) {
>+                        return;
>+                    }
>+                }
I don't like this patch at all, but since it gets the job done feel free to take it for the 0.5 release. Since Berend will soon come up with a fresh version of the agenda/todo stuff I'd just let you go ahead with it, resting assured knowing this patch will die. r=mickey.

Comment 10

[Simon Paquet [:sipaq]]

Is this really a deal-breaker, which would make an RC3 necessary? IMO this is release notes stuff, but not more. 

I recommend blocking 0.5- and also recommend releasing 0.5 once we have unified Mac builds ready for Lightning.

Comment 11

[Joey Minta]

(In reply to comment #10)
Just my perspective here from the 0.3 release.  This bug was exactly the kind of pseudo-dataloss bug that dmose and I would have marked as blocking+.  Given that there will likely be some very unexpected behaviors if the user tries to modify the duplicates, it sounds like asking for trouble to leave this bug in.  (Imagine the user deleting each of the duplicate copies.  I suspect this will actually completely delete the todo from the file.  --> actual dataloss)

Comment 12

[Alistair Low]

Without trying to influence whether this gets fixed, I did exactly as in comment #11 when I was filing the bug and trying to note down all the behaviour. If one of the todo items is deleted then all the duplicates disappear too, and the whole item is lost.

Comment 13

[Omar Bajraszewski]

I've also noticed that checking box next to "show completed tasks" makes duplicates to disappear.

Comment 14

[Simon Paquet [:sipaq]]

Based on Joey's comment, I want to retract my statement in comment 10. We should take this bandaid-fix for 0.5. But please add an XXX comment pointing to this bug and the agenda-revamp bug that Berend is working on to make sure, that this does not stay in the tree any longer than it has to.

Comment 15

[Daniel Boelzle [:dbo]]

(In reply to comment #10)
> Is this really a deal-breaker, which would make an RC3 necessary? IMO this is
> release notes stuff, but not more. 
> 
> I recommend blocking 0.5- and also recommend releasing 0.5 once we have unified
> Mac builds ready for Lightning.
I would second your opinion. Strictly spoken, this doesn't block. But since we still need to do the Mac builds, it doesn't hurt checking the fix in for 0.5. I suspect updating Linux and Windows xpis in that turn is no big deal, too. But unless there are new urgent bugs coming up, we won't do an RC3.

(In reply to comment #11)
> (In reply to comment #10)
...
> (Imagine the user deleting each of the duplicate copies.  I suspect this will
> actually completely delete the todo from the file.  --> actual dataloss)
I don't understand that part. If the user deletes todos, they should disappear from the file... so where is the dataloss part? I only see potential dataloss when those (multiple) todos are modified independently.

Comment 16

[Daniel Boelzle [:dbo]]

checked in on HEAD, MOZILLA_1_8_BRANCH, SUNBIRD_0_5_BRANCH and bumped _RELEASE tags.

Comment 17

[Joey Minta]

(In reply to comment #15)
> > (Imagine the user deleting each of the duplicate copies.  I suspect this will
> > actually completely delete the todo from the file.  --> actual dataloss)
> I don't understand that part. If the user deletes todos, they should disappear
> from the file... so where is the dataloss part? I only see potential dataloss
> when those (multiple) todos are modified independently.
> 
The problem is that the program tells me I have 2 copies of the todo.  So, I delete one, assuming that I still have 1 left.  In reality, what I've done is reduce the count from 1 to 0, meaning I've lost whatever data was associated with the duplicated set as soon as I restart.

Comment 18

[Stefan Sitter [:ssitter]]

Alistair, could you verify that this issue is fixed using the latest build from [http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-mozilla1.8/] please?

Comment 19

[Alistair Low]

Yes, it works now. Thanks!