Todo items are duplicated (ICS Calendar only)

VERIFIED FIXED in Lightning 0.5

Status

Calendar
Tasks
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Alistair Low, Assigned: dbo)

Tracking

Lightning 0.5
Lightning 0.5

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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

11 years ago
(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?
(Assignee)

Comment 2

11 years ago
(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?
(Reporter)

Comment 3

11 years ago
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.
(Reporter)

Comment 4

11 years ago
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

11 years ago
Created attachment 268775 [details]
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
(Assignee)

Comment 6

11 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

11 years ago
Created attachment 268780 [details] [diff] [review]
don't add same item again

Brute-force fix to avoid adding the same item twice.
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #268780 - Flags: review?(michael.buettner)
(Assignee)

Comment 8

11 years ago
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?.
Flags: blocking-calendar0.5?
OS: Windows XP → All
Hardware: PC → All
Summary: Todo items are duplicated → Todo items are duplicated (ICS Calendar only)
Version: unspecified → Lightning 0.5
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.
Attachment #268780 - Flags: review?(michael.buettner) → review+
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

11 years ago
(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)

(Reporter)

Comment 12

11 years ago
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

11 years ago
I've also noticed that checking box next to "show completed tasks" makes duplicates to disappear.
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.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
(Assignee)

Comment 15

11 years ago
(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.
(Assignee)

Comment 16

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

Comment 17

11 years ago
(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.
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Lightning 0.5
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?
(Reporter)

Comment 19

11 years ago
Yes, it works now. Thanks!

Updated

11 years ago
Status: RESOLVED → VERIFIED

Updated

10 years ago
Flags: blocking-calendar0.5+
You need to log in before you can comment on or make changes to this bug.