Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52pre) Gecko/20070415 Calendar/0.5pre Steps: * Set a color for a category * Create an event with this category. * Remove the color from the category. Result: * The colored border stays, even if the view is refreshed.
Created attachment 261664 [details] [diff] [review] Fix getPrefSafe I have tracked down the Problem. * getPrefSafe throws NS_ERROR_UNEXPECTED in , the rule is never deleted. * nsIPrefBranch::clearUserPref()  says it will delete the preference if there is no default value, but it doesn't until you restart the application. The preference stays with a null default value, which throws the above NS_ERROR. * The issue is fixed on trunk in bug 193332. This means we need to work around it. * The attached patch should function as a workaround.  http://mxr.mozilla.org/mozilla1.8/source/calendar/base/0  http://mxr.mozilla.org/mozilla1.8/source/modules/libpref/1
Assignee: nobody → bugzilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #261664 - Flags: first-review?(jminta)
Comment on attachment 261664 [details] [diff] [review] Fix getPrefSafe See also bug 340229.
Attachment #261664 - Flags: first-review?(jminta) → first-review+
This bug is rather visible and the patch is quite harmless. Therefore, I'm requesting blocking.
The fix in this patch is the same as in Bug 372626.
This can be checked in, as per the conference call.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
Checked in on MOZILLA_1_8_BRANCH and HEAD. -> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
verified on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206pre) Gecko/20070426 Calendar/0.5pre
Status: RESOLVED → VERIFIED
Litmus testcase 2625 created
You need to log in before you can comment on or make changes to this bug.