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

RESOLVED FIXED in 1.0b7

Status

defect
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: ssitter, Assigned: Fallen)

Tracking

({regression})

Dependency tree / graph
Bug Flags:
blocking-calendar1.0 +

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

10 years ago
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.
Reporter

Comment 1

10 years ago
I think this is another regression from Bug 475715.
Blocks: 475715
Reporter

Updated

10 years ago
Flags: wanted-calendar1.0?
Flags: blocking-calendar1.0?
Reporter

Comment 2

10 years ago
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.

Comment 3

10 years ago
Posted 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
Status: NEW → ASSIGNED
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.
Reporter

Comment 5

10 years ago
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.
Duplicate of this bug: 345410
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.

Comment 9

9 years ago
(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
Status: ASSIGNED → NEW
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]
Duplicate of this bug: 421986
Posted 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
Status: NEW → ASSIGNED
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 15

8 years ago
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.
r+
Attachment #547954 - Flags: review?(bv1578) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7dbc9c5c2b41>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 8 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.