Closed Bug 353060 Opened 18 years ago Closed 18 years ago

adjusted times lost if immediately double click event (calendarViewController)

Categories

(Calendar :: Sunbird Only, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: gekacheka, Assigned: gekacheka)

Details

(Keywords: dataloss)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060915 Calendar/0.3a2+

On Sunbird week view, if you drag an event or its begin time or end time, then immediately double click the event (say to edit its location), the dragged time changes are lost.

Reproducible: Always

Steps to Reproduce:
0. create an event if necessary.  (example: from 8-9)
1. Drag event, or its begin time, or its end time.  (example: drag end to 10.)
2. Mouse over event.  Note that new time(s) are known. (ex: 8-10).
3. Double click event.  

Actual Results:  
Event Dialog appears with old times  (example: start 8:00, end: 9:00)

Expected Results:  
Event Dialog appears with new times  (example: start: 8:00, end: 10:00)
Keywords: dataloss
OS: Windows 2000 → All
Hardware: PC → All
Version: unspecified → Trunk
(patch -l -p 2 -i file.patch)

Item with correct dates is passed to calendarViewController.modifyOccurrence,
but then on sunbird it is lost with call to editEvent().

            if ("editEvent" in window) {
                // Sunbird specific code
                editEvent();
            } else {
                // Lightning specific code
                itemToEdit = getOccurrenceOrParent(aOccurrence);
                modifyEventWithDialog(itemToEdit);
            }

The editEvent function when called with no parameters gets the
selected event, then does the same as the lightning branch above.

With this patch it calls editEvent() only if aOccurrence is unknown.

Tested on w2k, appears to work.
Attachment #238910 - Flags: second-review?(jminta)
Attachment #238910 - Flags: first-review?(mattwillis)
Comment on attachment 238910 [details] [diff] [review]
v1 patch calViewController.modifyOccurrence to skip editEvent if have occurrence

Works as advertised.
r=lilmatt
Attachment #238910 - Flags: first-review?(mattwillis) → first-review+
Assigning to gekacheka

Nominating for blocking since it's dataloss
Assignee: nobody → gekacheka
Flags: blocking0.3?
Whiteboard: [needs review jminta]
Comment on attachment 238910 [details] [diff] [review]
v1 patch calViewController.modifyOccurrence to skip editEvent if have occurrence

I can't find any code-paths that would results in aOccurrence being null here.  Shouldn't we just remove this clause (see also bug 346934), or am I missing something?
(patch -l -p 2 -i file.patch)

Testing: The unified approach also fixes this bug.  I vaguely recall the sunbird branch might have been there to deal with context menu edit-event, so I also tried all the context menus I could find (each grid view and list view) and they still work with this patch.

(The large patch for bug 346934 once fixed this bug as well, but it can no longer be applied.  Alternatives for fixing this bug:  (A) fix the large patch and review it.  (B) Use this small patch.  Since the large patch will need to be revised anyway, this small patch may still be a little useful in that (i) it gets this bug fixed quickly and (ii) it slightly reduces the review work needed for the large patch (and its urgency).)
Attachment #238910 - Attachment is obsolete: true
Attachment #239002 - Flags: second-review?(jminta)
Attachment #238910 - Flags: second-review?(jminta)
Landing the large patch before 0.3 was already deemed too risky by mvl last week. As a result, I'd vote for B.
Comment on attachment 239002 [details] [diff] [review]
v2 patch calViewController.modifyOccurrence to unify sunbird/lightning branches, + comments

+        var itemToEdit = getOccurrenceOrParent(aOccurrence);;
Extra semi-colon there.

+        }
+        // if modifying this item directly (e.g. just dragged to new time),
A new-line would be nice between these.

r2=jminta with that.
Attachment #239002 - Flags: second-review?(jminta) → second-review+
Patch (with nits) checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking0.3?
Resolution: --- → FIXED
Whiteboard: [needs review jminta]
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Sunbird/0.3
Status: RESOLVED → VERIFIED
Whiteboard: [litmus testcase wanted]
Litmus testcase 2427 created
Whiteboard: [litmus testcase wanted]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: