If I collapse the msgheader pane, and restart the app it's expanded when I read my mail.
This is very annoying, please fix this for 0.9 (nominating).
hwaara: Are you talking about the main Mail window (aka 3pane)? I noticed that when the message headers are collapsed in the message pane, this state is not remembered after a restart. If this is true then the component should be changed from Composition to Mail Window Front End.
No, I'm talking about the Message Header. The new one that mscott added, which can be collapsed. The one that displays From: and To: information when you view an email. That header's collapsed state isn't persisted.
Thanks for the clarification. What you just described is what I was also trying to describe. For this reason I'm changing the component to Mail Window Front End.
Component: Composition → Mail Window Front End
QA Contact: esther → nbaca
Agreed that we should persist this. If we get time to fix this it would be cool for 0.9.1 but we could probably live with this until 1.0
Target Milestone: --- → mozilla0.9.1
*** Bug 75522 has been marked as a duplicate of this bug. ***
I know prassanna was looking into this. adding her to cc.
Priority: -- → P3
Scott, can I take this one? I will soon attach the patch.
thanks for the patch prassana. We actually have a pref we want to hook into rather than saving the collasped state as a persist attribute. We have a pref which says whether you want to view: 1) brief, 2) normal 3) all headers. The "collapsed" view is really the brief view. The pref name is: mail.show_headers a value of 1 = brief 2 = normal 3= view all headers You'll notice in msgHdrViewOverlay.js where we read in this pref in onStartHeaders and then set the current view for the message appropriately. We need to tap into this code for persisting the msg header state. expanding it to make it work when Brief is selected.
reassigning to prassanna.
Assignee: mscott → prass
moving to 0.9.2. But since you have a patch, if you can go through the process to get this checked in in the next couple of days for 0.9.1 then that would be ok, too.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
moving to 0.9.3. Please hold onto the fix in case we can get this in later.
please attach a new patch, and remove this line: + alert("ToggleHeaderView called");
Haven't tried the patch, but the code looks good. r=hwaara
oh, except for the alert call of course. ;)
Sorry for not updating this bug earlier. I think this patch might not be the right fix. When brief is selected the header display is messed up.
I'm confused. If the menu can switch between all, normal and brief (which I don't observe) then what is the toggle on the brief display supposed to "restore" to?
Currently the toggle appears to switch between Brief and Normal. Jglick: How should the toggle work?
I just checked in a version of Prassanna's original patch which was to persist the brief mode (not through the menu which gets confusing) but through the toggle by persisting the state of the toggle. Now you can toggle between brief and normal (or view all headers once that's implemented) and it will be remembered across sessions. Adding vtrunk keyword for verification on the trunk.
Keywords: nsBranch, vtrunk
>Jglick: How should the toggle work? The toggle is for expanding/collapsing the contents of the "envelope" area. It is either expanded or collapsed and should be independent of the All/Normal/Brief Headers setting.
That's how we now have it hooked up too. (just like Jennifer described).
nbaca - can you help to make sure this fix is ok on the trunk? If so, it'll be a good candidate to land back on the branch.
Whiteboard: [nsbeta1+]Have Fix → [nsbeta1+][nsbranch+]Have Fix
prass, mind if I take this from you? I have the patch in my branch build just waiting to get commited =).
Assignee: prass → mscott
When the branch is open, please check this into it today.
Whiteboard: [nsbeta1+][nsbranch+]Have Fix → [nsbeta1+][nsbranch+,pdt+]Have Fix
Checked into the branch.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Branch build 2001-07-09-05: WinMe Branch build 2001-07-09-04: Linux RH 6.2 Branch build 2001-07-09-03: Mac 9.04 Fixed/Verified on the branch builds.
Linux (2001-07-10-08 trunk) Win32 (2001-07-10-06 trunk) Works fine in the trunk build. Unable to test Mac trunk because of trunk installation error.
This bug only had to be verified on mac trunk build. I verified this using today's trunk build on mac(2001071208). Marking this bug as verified since this is now verified on both branch and trunk builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.