Closed Bug 349040 Opened 14 years ago Closed 14 years ago

Day/Week view: New created events don't show up until view is changed

Categories

(Calendar :: Calendar Views, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [patch in hand])

Attachments

(1 file)

Day/Week view: New created events don't show up until view is changed

Steps to Reproduce:
1. Start Sunbird with clean profile
2. Switch to Day view
3. Create event with Drag'n'Drop

1. Start Sunbird with clean profile
2. Switch to Week view
3. Create event with Drag'n'Drop

Actual Results:
The new event does not show up in calendar view but is displayed in unifinder.
After switching to another view or going one day/week forwards/backwards the event is displayed in view.

Additional Information:
If you delete that event the event disapears from unifinder but is still displayed in calendar view. Tested with storage and ics provider.

Works with Sunbird/0.3a2+ (2006-08-16-23)
Fails with Sunbird/0.3a2+ (2006-08-17-05)
Fails with Lightning/0.1+ (2006-08-17-06-mozilla1.8)
The only checkin between those builds that looks like it might have conceivably caused this was for bug 330496.  Joey suggests that the problem here might be observer-related.
*** Bug 349304 has been marked as a duplicate of this bug. ***
Confirming in day view.
Works for me in week view.

Note that also modification of an existing event is affected.

using Sunbird: 20060818 and
Lightning 20060818/BRANCH
Well, this is a regression that breaks one of the main 0.3 targets:
"Events/tasks are displayed at the correct position (based on time) in day/week view"
Flags: blocking0.3?
Does backing out bug 330496 make a difference here?
Flags: blocking0.3? → blocking0.3+
Attached patch patch v1Splinter Review
calIDateTime.compare compares dates only if one of the two values are date-only. This patch makes it so that both values are not date-only, instead of only one. This still makes the testcase in bug 330496 patch (except testcase4, but that should not pass), and makes this bug go away too.
(easy testcase: just modify an event. drag it to a different time)
Attachment #234696 - Flags: second-review?(jminta)
Attachment #234696 - Flags: first-review?(thomas.benisch)
Whiteboard: [patch in hand]
Comment on attachment 234696 [details] [diff] [review]
patch v1

r2=jminta
Attachment #234696 - Flags: second-review?(jminta) → second-review+
Comment on attachment 234696 [details] [diff] [review]
patch v1

mvl asked me to bogart tbe's review on this so it makes it in for tomorrow's test day

r1=lilmatt
Attachment #234696 - Flags: first-review?(thomas.benisch) → first-review+
checked in
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
*** Bug 349694 has been marked as a duplicate of this bug. ***
I've verified this is fixed in the Linux trunk nightly.
Marking VERIFIED, per comment #11.
Status: RESOLVED → VERIFIED
Not verified on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060821 Calendar/0.3a2+

But that is probably before the checkin. We'll see when the next trunk build is produced for windows.
You need to log in before you can comment on or make changes to this bug.