Closed Bug 342341 Opened 19 years ago Closed 19 years ago

New preferences: New created categories are not stored and selectable

Categories

(Calendar :: Preferences, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: mattwillis)

References

Details

(Keywords: regression)

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060621 Sunbird/0.3a2+ New preferences: New created categories are not stored and selectable Steps to reproduce: 1. Open Sunbirds preference dialog, select Categories tab 2. Create a new category -> new category is displayed 3. Leave dialog with OK 4. Create new event/task and select category created above -> not ok 5. Open Sunbirds preference dialog again, check categories -> not ok Actual Results: The new category is not selectable in event/task dialog. The new category is not shown preference dialog dialog when opening again. Expected Results: The new category is selectable and can be edited in preference dialog. Additional Information: Same error with linux build. No JavaScript errors are shown. Worked in old preferences dialog.
Assignee: base → mattwillis
This fixed it for me.
Attachment #226643 - Flags: first-review?(jminta)
Comment on attachment 226643 [details] [diff] [review] rev0 - removes some remnants of oldprefs This doesn't feel right on first look. According to XULPlanet, setting a preference's value actually sets the preference. On non-instant apply platforms, this seems like it could cause problems, since our cancel handler only resets categories. Or is the prefwindow smart enough to handle that cancel?
*** Bug 342830 has been marked as a duplicate of this bug. ***
Comment on attachment 226643 [details] [diff] [review] rev0 - removes some remnants of oldprefs minusing per previous comment and IRC discussion.
Attachment #226643 - Flags: first-review?(jminta) → first-review-
Flags: blocking0.3+
Keywords: regression
(In reply to comment #2) > Or is the prefwindow smart enough to handle that cancel? It appears to be. I tested this on WinXP and the dialog acts as I expect. Changes are saved when clicking "OK" and not when clicking "Cancel"
Comment on attachment 226643 [details] [diff] [review] rev0 - removes some remnants of oldprefs rerequesting
Attachment #226643 - Flags: first-review- → first-review?(jminta)
Comment on attachment 226643 [details] [diff] [review] rev0 - removes some remnants of oldprefs r=jminta based on the <preference>-does-not-watch-<textbox> explanation.
Attachment #226643 - Flags: first-review?(jminta) → first-review+
patch checked in on MOZILLA_1_8_BRANCH and trunk -> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060823 Calendar/0.3a2+
-> VERIFIED
Status: RESOLVED → VERIFIED
Whiteboard: [litmus testcase wanted]
Litmus testcase 2627 created
Whiteboard: [litmus testcase wanted]
Component: Internal Components → Preferences
QA Contact: base → preferences
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: