collapsed msgheader state isn't persisted

VERIFIED FIXED in mozilla0.9.3


18 years ago
14 years ago


(Reporter: hwaara, Assigned: mscott)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+][nsbranch+,pdt+]Have Fix)


(3 attachments)



18 years ago
If I collapse the msgheader pane, and restart the app it's expanded when I read
my mail.

Comment 1

18 years ago
This is very annoying, please fix this for 0.9 (nominating).
Keywords: mozilla0.9

Comment 2

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


Comment 3

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

Comment 4

18 years ago
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 
Component: Composition → Mail Window Front End
QA Contact: esther → nbaca

Comment 5

18 years ago
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
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1

Comment 6

18 years ago
*** Bug 75522 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
I know prassanna was looking into this.  adding her to cc.
Priority: -- → P3

Comment 8

18 years ago
Scott, can I take this one? I will soon attach the patch.

Comment 9

18 years ago
Created attachment 33294 [details] [diff] [review]
proposed patch

Comment 10

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

Comment 11

18 years ago
reassigning to prassanna.
Assignee: mscott → prass

Comment 12

18 years ago
Created attachment 34098 [details] [diff] [review]
updatde patch


18 years ago
Whiteboard: [nsbeta1+] → [nsbeta1+]Have Fix

Comment 13

18 years ago
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


18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 14

18 years ago
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");

Comment 16

18 years ago
Haven't tried the patch, but the code looks good. r=hwaara

Comment 17

18 years ago
oh, except for the alert call of course. ;)

Comment 18

18 years ago
Created attachment 39568 [details] [diff] [review]
patch without alert

Comment 19

18 years ago
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?

Comment 21

18 years ago
Currently the toggle appears to switch between Brief and Normal. 

Jglick: How should the toggle work?

Comment 22

18 years ago
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

Comment 23

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

Comment 24

18 years ago
That's how we now have it hooked up too. (just like Jennifer described).

Comment 25

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

Comment 26

18 years ago
adding nsbranch+
Whiteboard: [nsbeta1+]Have Fix → [nsbeta1+][nsbranch+]Have Fix

Comment 27

18 years ago
prass, mind if I take this from you? I have the patch in my branch build just
waiting to get commited =).
Assignee: prass → mscott

Comment 28

18 years ago
When the branch is open, please check this into it today.
Whiteboard: [nsbeta1+][nsbranch+]Have Fix → [nsbeta1+][nsbranch+,pdt+]Have Fix

Comment 29

18 years ago
Checked into the branch.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 30

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

Comment 31

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

Comment 32

18 years ago
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. 
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.