Closed Bug 329912 Opened 14 years ago Closed 11 years ago

Item dialog does not remember last 'Details shown or not' state

Categories

(Calendar :: Calendar Views, defect)

x86
All
defect
Not set

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: jim, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

We need a setting for the New Event dialog box to default with MORE expanded.  I need to be able to see that the alarms is on.  In fact, I should be able to set a default of the alarm being set to something other than None.

Reproducible: Always

Steps to Reproduce:
1.Add event in Lightning
2.New Event window opens with a MORE button on lower right.
3.Click MORE button and set alarm as needed
4.OK to close New Event window
5.Open event for edit and see that MORE button is back.

Actual Results:  
New Event window is not remembering that user expanded window for alarm.

Expected Results:  
If MORE button was used to create then window should open with expanded view.

I believe a global default for the alarm setting would ease the problem, but without that, I would like to see the New Event window remember the status of the More Button.
The dialog ought to remember whether or not it was showing 'More' last time you closed it and re-open in that state.  The bug for an alarm default is bug 329855.  I'd argue that this bug should either be marked as a duplicate of that one, or closed as worksforme, if it's referring to the More issue.  Opinions?

(In the future, limiting bug reports to only one issue will help make triaging them and then fixing them much easier.)
I see your logic and I will have to look at how bug 329855 didn't show when I searched.

I suppose this issue only deals with the default or remembered status of expanded MORE on the New Event window.  So, can I just change the name?  Why would we change it to WORKSFORME?  Is there a work-around?.. or a solution?
With the current trunk version of Sunbird 0.3a1+ and Thunderbird 3.0a1 (20060306)+ Lightning the expanded / not expanded status of the dialog is remembered correctly. (Tested on Windows 2000)

With the branch version of Thunderbird 1.5 (20051201)+ Lightning the status is *not* remembered correctly.

Because the Lightning source code is the same in both cases this might be a toolkit bug that is fixed on trunk but not on branch.
Summary: global Alarm defualt ON → Item dialog does not remember last 'Details shown or not' state
There's a new dialog on the way, see https://bugzilla.mozilla.org/show_bug.cgi?id=324657. I can't see a reason for addressing this issue, since the new dialog won't have a details-button.
Confirming based on ssitter's comments.  I think this is a significant usability and I'd be curious if other folks agree.  If it's painful enough, please nominate for blocking0.3.

The previous comment isn't relevant in the 0.3 timeframe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patch uses document.persist to force the new collapsed state to be stored.
Assignee: nobody → jminta
Status: NEW → ASSIGNED
Attachment #231186 - Flags: second-review?(dmose)
Attachment #231186 - Flags: first-review?(michael.buettner)
Wouldn't it be a good idea to #ifdef the document.persist statement to be used in branch builds only? For trunk builds it seems to be redundant, isn't it?
(In reply to comment #7)
> Wouldn't it be a good idea to #ifdef the document.persist statement to be used
> in branch builds only? For trunk builds it seems to be redundant, isn't it?
> 
pre-processing files ruins line numbers and thus make debugging user-reported bugs much harder.  I'd like to stay away from such an approach unless we're absolutely forced to.
Comment on attachment 231186 [details] [diff] [review]
use document.persist

r=mickey
Attachment #231186 - Flags: first-review?(michael.buettner) → first-review+
Comment on attachment 231186 [details] [diff] [review]
use document.persist

r=dmose with a tweaked comment.
Attachment #231186 - Flags: second-review?(dmose) → second-review+
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Not quite fixed yet. If you open events on one calendar and then on another, the preference is not saved. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Confirmed. Before this patch it worked in Sunbird, but after this patch it's broken in Sunbird too now. 
If I just open and close the dialog the 'more' state is remembered once, after that it's set back to 'less'.
*** Bug 347650 has been marked as a duplicate of this bug. ***
Assignee: jminta → nobody
Status: REOPENED → NEW
Component: Lightning Only → Calendar Views
OS: Windows XP → All
QA Contact: lightning → views
Version: unspecified → Trunk
Duplicate of this bug: 367323
Duplicate of this bug: 386175
Duplicate of this bug: 386951
Is the bug still valid? Prototypes are enabled by default now.
(In reply to comment #18)
Yes. The issue still exists in this dialog. The decision if the prototype dialog will stay the default dialog is not yet done therefore all issues regarding the event dialog are still valid.
After fixing bug 403886 and bug 417539 this dialog and this issue doesn't exists anymore -> resolving INVALID.
Status: NEW → RESOLVED
Closed: 14 years ago11 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.