329975 - Task dialog does not show completed percentage

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[Frank]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Mozilla Sunbird/0.3a1+

If a Task has e.g. 50% completed, which is shown correclty in the left panes listview, and you double click it for editing, the dialog always shows 0%.
If you change the percentage and save the task the listview is updated and the value is saved in the calendar file correctly.
Opening the task again result in the dialog sjowing 0% again.

Reproducible: Always

Steps to Reproduce:
1. Create a Task an set Percentage competed to a value > 0%
2. Save the Task (You will see your entered and saved value in the task listview)
3. Open the task for editing
4. The percentage completed shows 0%

Actual Results:  
Dialog always shows 0% completed, no matter of the actual value of the according task

Expected Results:  
The dialog should show the tasks percentage completed value (as in the listview)

Comment 1

[Stefan Sitter [:ssitter]]

Confirmed.

Note: task dialog allows to set 0/10/20/30/40/50/60/70/80/90/100 for % completed. Setting the value via context menu allows to set 0/25/50/75/100 only.  This wants to be unified first. Or the dropdown list in the dialog should be an edit field.

Comment 2

[Matthew (lilmatt) Willis]

Attachment: v0 - TRUNK - ToDoDialog neglected to get the item's percent complete onLoad

This patch only covers the original bug.

Comment 3

[Matthew (lilmatt) Willis]

(In reply to comment #1)
> Note: task dialog allows to set 0/10/20/30/...

I think that issue should be a separate bug (if it isn't already)

Comment 4

[Joey Minta]

Comment on attachment 216173 [details] [diff] [review]
v0 - TRUNK - ToDoDialog neglected to get the item's percent complete onLoad

The percent complete field is in the 'More' section of the dialog, so this value shouldn't be set until loadDetails().  (That keeps us faster at creating/loading the dialog.)

Comment 5

[Matthew (lilmatt) Willis]

Attachment: v1 - Now in the correct place per jminta comment

Comment 6

[Joey Minta]

Comment on attachment 216222 [details] [diff] [review]
v1 - Now in the correct place per jminta comment

r=jminta but whether we fix the menu-unification issue in this bug or in another, it needs to block 0.3a2.

Comment 7

[Matthew (lilmatt) Willis]

ssitter's bug isn't address by patch v1:
If you set your task (via the contextual menu) to one of the percentages that's not in the eventDialog's menulist (25% or 75%) and then check eventDialog, it shows "0%". 

The options I see are:
a) blow the contextual menu out to 0-100% by tens
b) add the "25%" and "75%" to eventDialog's menulist
c) leave the contextual menu alone but change the eventDialog menulist to a textfield, complete with integer checking, etc.

I think The Right Way to do it is c), but we could implement b) to keep from blocking 0.3a2

Comment 8

[Matthew (lilmatt) Willis]

patch v1 was checked in to trunk and moz1.8

ssitter's valid comment is now represented by bug 331814

resolving FIXED

Comment 9

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!

Comment 10

[Damian Szczepanik]

verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Sunbird/0.3

Comment 11

[Damian Szczepanik]

Litmus testcase 2607 created