Closed Bug 482110 Opened 16 years ago Closed 13 years ago

calendar stays hidden after adding event to it; new event not visible


(Calendar :: General, defect)

Not set


(Not tracked)



(Reporter: ssitter, Assigned: Fallen)



(Keywords: regression, Whiteboard: [not needed beta][no l10n impact])


(1 file, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090307 Calendar/1.0pre

In the past many users complained that they were unable to create events. Investigation showed that creation was successfully but the events were created in a calendar marked as hidden. Therefore the new event was not visible to the user.

Sunbird 0.7 introduced the following behavior: If an event/tasks is added to a hidden calendar the calendar gets visible. This behavior is regressed in Sunbird 1.0pre.

Steps to Reproduce:
1. Untick the checkbox for the selected calendar to mark it hidden
2. Create new event in the default calendar

Actual Results:
Calendar stays hidden, new event is not shown.

Expected Results:
Calendar is not hidden, new event is shown.

This used to work in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 Calendar/1.0pre.
I think this is another regression from Bug 475715.
Blocks: 475715
Flags: wanted-calendar1.0?
Flags: blocking-calendar1.0?
This regression has been introduced after the 0.9 release. 
It should be decided if it must be fixed before the 1.0 release or not.
Attached patch [short] patch-v1 (obsolete) β€” β€” Splinter Review
IMHO this feature is useful, for an instant I thought there was a bug about new events creation.
This patch restores the 0.9 version's behavior for new events and modified events.
Assignee: nobody → bv1578
Attachment #420058 - Flags: review?(philipp)
OS: Windows XP → All
Hardware: x86 → All
Attachment #420058 - Attachment description: patch-v1 → [short] patch-v1
I believe this was changed because of the cached calendar. onAddItem was called in cases that made sense for the caching mechanism, but were automated additions, not user controlled. This gave the user the feeling that having a calendar unchecked would not stick.

Not sure how we should proceed on this one, I'll ask dbo when he comes back and would appreciate your opinion in the meanwhile.
You probably mean Bug 412963.

Maybe split the behavior? If you (manually) add a new event the calendar gets visible and you see the new event. But if you modify an event (e.g. dismissing alarm) the calendar stays invisible (fixing Bug 405480).
We could surely split the behavior by checking if certain attributes changed, but that wouldn't help with the cached calendar. If a remote user adds an event to the calendar and the local cached calendar synchronizes, I believe onAddItem is also called. We can't differentiate between user adding items and the cache adding items atm. Doing so would probably break the encapsulation we currently have with the cache.
Attachment #420058 - Flags: review?(philipp) → review-
Comment on attachment 420058 [details] [diff] [review]
[short] patch-v1

I don't think we can take this patch as it is due to the caching issue. I've pinged Daniel for an opinion, but this patch will probably a lot larger than expected to fix this issue correctly.
(In reply to comment #8)
> (From update of attachment 420058 [details] [diff] [review])
> I don't think we can take this patch as it is due to the caching issue. I've
> pinged Daniel for an opinion, but this patch will probably a lot larger than
> expected to fix this issue correctly.

OK, I change the status to NEW, so someone more skilled can take over the issue.
Assignee: bv1578 → nobody
I think we can properly fix this by enabling the calendar from the UI side where needed:

* Create a utility function that ensures a calendar is visible
* From certain UI places (views, today pane, task mode, ...), call this function just before addItem is called

This will keep the calendar hidden when in cached mode and still make it visible for the user when adding items. Decathlon, do you want to create a patch for this solution?
Flags: wanted-calendar1.0?
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Attached patch Fix - v2 β€” β€” Splinter Review
Sorry, I couldn't stop thinking about this bug. The solution was much easier than I thought, this should take care!
Assignee: nobody → philipp
Attachment #420058 - Attachment is obsolete: true
Attachment #547954 - Flags: review?(bv1578)
Whiteboard: [not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs review]
The last change is of course not needed, pretend its not there :)
Comment on attachment 547954 [details] [diff] [review]
Fix - v2

It seems working fine, for cached calendars too.
It also fixes Bug 405480 if that one is the wanted behavior.
Attachment #547954 - Flags: review?(bv1578) → review+
Pushed to comm-central <>
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Whiteboard: [not needed beta][no l10n impact][needs review] → [not needed beta][no l10n impact]
Target Milestone: Trunk → ---
Target Milestone: --- → Trunk
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.
Target Milestone: Trunk → 1.0b6
You need to log in before you can comment on or make changes to this bug.