Closed Bug 39655 Opened 24 years ago Closed 16 years ago

Switch folder after resize msg pane hides header envelope until another resize

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: laurel, Assigned: eric)

References

Details

Attachments

(4 files)

Using 2000-05-16-08m16 commercial build linux rh6.0
Using 2000-05-16-09m16 commercial build mac OS 9.0
I'm not seeing on NT 4.0

ref related bug #37399

The message header envelope area doesn't display if you've resized the message
pane in one folder then switch to another folder and select a message.  In order
to see the header envelope area you must again resize the message pane in the
newly selected folder.

Steps to reproduce:

1.   Go to mail 3-pane window (message pane open), login to mail account (I used
IMAP) and select a message in the Inbox.  Header envelopes display fine.
2.   Drag the thread/message pane splitter downward some to resize the display
area of the message pane. 
3.   Switch to another mail folder with messages and select a message.

Result:  the header envelope area doesn't display at all until you resize the
message pane again.
QA Contact: lchiang → laurel
#40716 is a dup.  here's how I can easily reproduce:

load my imap inbox, read a message (I can see the header envelope)
click on a newsgroup, read a news message (I can't see the header envelope,
until I click the grippy and resize the message pane.)

marking nsbeta2.
Keywords: nsbeta2
*** Bug 40716 has been marked as a duplicate of this bug. ***
[nsbeta2-]
Whiteboard: [nsbeta2-]
nominate for nsbeta3 then.
Keywords: nsbeta3
If this is the same problem I'm seeing I think we should take another look at
this for beta2.  Almost every time I run nowadays I lose the envelope in the
message pane which makes me have to restart because it's pretty hard to read
mail without it.  It seems to happen randomly for me (I haven't yet tried the
steps below) but it pretty much always happens eventually within a session.

I think this is nsbeta2 because I don't think the workaround is very obvious.
Also, despite what the summary says, I'm pretty sure I'm never resizing the
message pane or the mail window.

So, I'm asking PDT to look at this again by removing the nsbeta2-



Whiteboard: [nsbeta2-]
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
*** Bug 40716 has been marked as a duplicate of this bug. ***
This works just fine for me. All areas appear correctly.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Well I only tried it on windows and it appears only to happen on mac and linux. 
Gary want to take a look?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
To Gary...
Assignee: evaughan → garyf
Status: REOPENED → NEW
*** Bug 43849 has been marked as a duplicate of this bug. ***
Target Milestone: --- → M18
I see this on windows all the time. It definetly isn't a Mac or Linux only bug.
Just show a message in your inbox, switch to another folder and show a message
in that folder. Notice that the toolbars in the message pane have gone away and
you have to resize to see them again.
I can repro this on Win98 using today's verification build.
*** Bug 45648 has been marked as a duplicate of this bug. ***
reassigning to saari.
Assignee: garyf → saari
So I just tried this on MacOS and it worked fine... does it happen every time?
I just tried again with mac and I'm not seeing it.  I'm still seeing it every
time with my IMAP account on linux.

As you can tell from the comments over time on this bug, it seems to hit
different people on different platforms.
This is consistently happening on win32 commercial build 2000-07-17-09.
can't reproduce this anymore, tried using today's bits on Mac, Windows and Linux.
resolving as wfm.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
Happens for me using NT4.0 with 2000-07-18-10 commercial build.
Happens for me using linux rh6.0 with 2000-07-18-08 commercial build.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Okay, I'll try the commercial builds then.
Whiteboard: [nsbeta2+] → [nsbeta2+] 7/24
Finally seeing it with mac OS 9.0 and 2000-07-18-10 commercial build.

If you don't see it on the first folder switch, switch to another folder or back
to the previous/first one.  If you switch a time or two and read a message in
the folder you switch to you will see it.  
I keep trying with the commercial bits on Win2K and I still don't see it, going
back and fourth between folders/messages.

How fast is the machine you're seeing this on? Have you ever seen this with POP
(which is what I'm using)?
I see it on on Win NT box with a debug build. 450MHZ machine with 256MB of RAM.
I see it with pop, news and imap folders. 
Okay, I've seen this once so far, and I got a bunch of RDF asserts in a QI in
the rule graph where the type was unknown instead of iSupports...

does this sound right? Can I sit with someone who can reproduce this?
saari sez fixing bug 41740 (see patches) fixes this problem. mscott, what say 
you?
Nope, those changes didn't make a bit of difference for me. I should point out
that I never see these assertions when switching folders and seeing the toolbar
disappear. 
Ok, you're right. I just tried this and it doesn't make a bit of difference for
me, either. I don't even have to touch the splitter to make it happen:

1. Open Inbox.
2. Select message ==> Headers and message are displayed
3. Select new folder ==> Headers and message are clobbered
4. Select message ==> message is displayed, no headers
5. Touch splitter, header pops into view.

So...how are the headers *hidden* in step 3? Without knowing much, my guess is
that a frame is not responding to a style change reflow or something. It then
becomes visible when it receives a resize reflow. Hyatt, whatdya think of that
theory?
the headers are hidden by hiding the toolbar. Then when we unhide the toolbar, 
it doesn't respond to that attribute change until you resize or others modify 
the window.
Per todays triage, moving to nsbeta2-.  Will relnote for PR2.
Keywords: relnote2
Whiteboard: [nsbeta2+] 7/24 → [nsbeta2-] 7/24
Looks like a timing related style reflow issue. Maybe a style reflow is getting 
incorrectly dropped. Doesn't happen if you only have a few messages in each 
folder, thus my timing comment.
nsbeta3+
Whiteboard: [nsbeta2-] 7/24 → [nsbeta2-] [nsbeta3+]
Keywords: mailtrack
I don't see this on linux anymore... will try other platforms asap
Does anyone else see this still?
can't repro using today's bits on Win98 & Linux, resolving as wfm
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
Looks OK to me using aug25 commercial build, Linux rh6.0, NT 4.0 and mac OS 9.0
Status: RESOLVED → VERIFIED
Just saw this using 2000-09-26-09-MN6 linux commercial build.

Reopening. 
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 54228 has been marked as a duplicate of this bug. ***
reassigning to evaughan; last time I looked into this it seemed to be related to
getting or not getting a style change reflow.
Assignee: saari → evaughan
Status: REOPENED → NEW
nsbeta3-, nominate for rtm
Keywords: rtm
Whiteboard: [nsbeta2-] [nsbeta3+] → [nsbeta2-] [nsbeta3-]
I see this problem all the time on WinNT4. I'm currently running the commercial
build - 2000-09-26-08.

All I need to do is switch from one folder to another and then select a message.
If the message envelope doesn't disappear after the first folder switch/message
select, it will certainly disappear if I try a couple more times.

If others are experiencing this problem with the same frequency as me, I
consider this a must fix for RTM.
*** Bug 54355 has been marked as a duplicate of this bug. ***
Keywords: relnote3
rtm+, but 'need info' until the fix is ready to land.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-] [nsbeta3-] [rtm+ need info]
Pulling a build will update when I reproduce the problem.
Status: NEW → ASSIGNED
PDT marking [rtm need info] until patch and code reviews are available.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm+ need info] → [nsbeta2-] [nsbeta3-] [rtm need info]
*** Bug 54955 has been marked as a duplicate of this bug. ***
*** Bug 55526 has been marked as a duplicate of this bug. ***
I get this all the time too, and I'm not sure most users are going to know 
what's going on, or how to work around it. We should definitely try and get 
this in rtm.
Any update about the status of this bug? Thanks!
I have been working on this but no luck yet. Its very ellusive tracking it down.
Time to cut this one.  ->rtm-/future.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm need info] → [nsbeta2-] [nsbeta3-] [rtm-]
Target Milestone: M18 → Future
cc'ing trudelle.

Why is it time to cut this one?  This is one of mailnew's highest duplicate
bugs. Is it going to be impossible to solve?
marking mostfreq, we have 9, putterman suggests we'll get more; I agree.
Keywords: mostfreq
This has *huge* user impact. I, among others, encounter this every day, and I'm
positive this will leave a negative impression on our customers. Additionally,
I'm not convinced this has run it's course in terms of investigation. Evaughan,
we need a solid asessment of whether or not this can be fixed soon. Can you make
this a top priority?
I minussed this based on the triage criteria we've been seeing from PDT. I
didn't think that they'd take a safe fix for this at this late date. I'd be
happy to reconsider this if that is not the case, but don't want my engineers
wasting time on bugs that won't make N6.  Please feel free to escalate as
appropriate, although with so little time left, it may not make it to the top of
our priority list in time.
Scott Putterman says that PDT thinks this is still worth working on, so ->[rtm
need info]/M19
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] → [nsbeta2-] [nsbeta3-] [rtm need info]
Target Milestone: Future → M19
Still working on this one. I still don't know why it happens. But I just 
finished my two other PDT+ bugs to this is now my top priority.
adding self to cc list.
good news, at least for the mailnews client.

we have a work around for this problem.

basically, we force it to redraw by setting the collapsed attribute on the box
that contains the headers to "true" and then "false."

I'll attach the fix.

this is a low risk work around for rtm.  this workaround will prevent the end
user from wondering where the headers went.

right now, we do this workaround on every message.  we only need to do it on the
first message we display after switching folders.  the performance degradation
from doing it on every message doesn't seem too bad, but if we decide it is we
can add more logic to only do the work around after switching folders.

the patch has been sr=mscott.
setting to rtm plus for the work around to get some PDT exposure.

after we get it checked in, we still need to come up with a fix for the trunk.

I'll work with evaughan to reduce the mailnews problem to a simpler test case
for him to debug and fix.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm need info] → [nsbeta2-] [nsbeta3-] [rtm+]
we've got a new patch.

I tried out this patch on linux, and noticed a flicker when going through
messages in my inbox.  (winnt didn't flicker.)

this new patch only does the workaround, the first message *after* you reroot
the message pane to a folder.

there is no flicker now because when we reroot, the message pane is blank.

sr=mscott
It is really too late for this... but we still have some urgent bugs that have
to land.  Please land this fix asap, and we'll include it.

marking rtm-double-plus.

The work-around (resize) is extremely hard to discover IMO, and getting this out
of the way will greatly enhance user perception (looking like you don't display,
may be as bad as not displaying, or just going away :-(  ).

Thanks for the effort!  Nice thinking in terms of safety, an usability!
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm+] → [nsbeta2-] [nsbeta3-] [rtm++]
I forgot to say "r=putterman"

I'll land the fix as soon as the tree opens.

thanks for the quick turn around, jar.
updating status whiteboard.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm++] → [nsbeta2-] [nsbeta3-] [rtm++] landing workaround today, 10-17
fix checked into the branch and the tip.

I'm going to mark this bug fixed, so that QA can verify, and then start a new
bug one on the real problem once I get a simple test case for evaughan.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
I'm still seeing this on linux rh6.0, using 2000-10-18-09 mn6 branch commercial
build, modern skin.
Haven't seen yet with mac, am working on reproducing for Win98.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It's definitely harder to get into this state than it has been in the past few
weeks... I can't get into that state now on my linux machine -- I'd gotten it
several times, then exited and now I can't reproduce.,

Comments from some other folks?
hmm...I don't see this bug in today's branch builds on all platforms.
I noticed when I'm getting the no header effect on linux that I'm using
Next(Unread) when there's a new message or two at the bottom of the thread pane,
so when I've just changed back to the inbox, clicking Next causes the pane to
scroll to the new message at bottom.

To recap what I'm doing:
1.  Login to IMAP inbox, sort with newest at the bottom of thread pane.
2.  Mark a couple messages at the bottom of thread pane unread.
3.  Switch to another folder with lots of messages.
4.  In the second folder, select a message. Resize the message pane.
5.  Go back to Inbox, click Next button.
6.  At this point is where I sometimes hit the no header envelope condition.
Was able to finally reproduce on Mac with today's commercial branch build, same
steps.  It took a couple switches back and forth among folders (repeated steps a
couple times) then happened using Next Unread in Inbox.
I've seen this once or twice on linux with today's build :(
I'll also try to see if I can figure out what's causing it
er, I mean triggering, not causing :)
I still don't think this is worth working on, especially with the reduced
frequency of occurrence.  rtm-/future
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm++] landing workaround today, 10-17 → [nsbeta2-] [nsbeta3-] [rtm-]
Target Milestone: M19 → Future
I still see this all the time - every day. It is very easy for me to get into
this state.

Currently using 2000-10-22-08, commercial on Win NT4.
Keywords: relnote2, relnote3relnote
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] → [nsbeta2-] [nsbeta3-] [rtm-] relnote-user
Keywords: relnoterelnoteRTM
Just an update:  seeing this a lot, very easy to get into this state with Win98
using oct30 rtm candidate.
*** Bug 55321 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla0.8
nominating for next release... I haven't been seeing this lately, but I be it
still occurs.  Noticed a new bug report logged about this.
Keywords: nsbeta1
*** Bug 63532 has been marked as a duplicate of this bug. ***
update: seeing fairly frequently in latest (jan23) trunk commercial build, win98.
I've seen this too a couple of times but not a lot.
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9
I'm also seeing this every day, and I think it makes MailNews a pain to use
for everybody who has more than one folder, so I'm increasing the severity.

For me it's very hard to get the headers back once they've vanished.
Resizing the message pane doesn't help. I have to click on the splitter to
close the pane, click on it again several times until it appears again.
I don't know if I really have to click there several times or if this is
just very slow.

Then the message pane is very small (less than one line high), so I have to
resize by dragging the splitter. Again, this process is very slow (Mozilla
seams unresponsive and the CPU usage seams to go up).

All in all, it takes somewhat between 15 to 30 seconds to get the headers
back, and that's a real pain when it happens most of the times when
switching folders.
Severity: normal → major
*** Bug 69369 has been marked as a duplicate of this bug. ***
p2
Priority: P3 → P2
Just an update: I'm seeing this bug all the time these days. It is highly visible. 
Adding another update to the pile: I agree with Suresh.  With current builds,
this happens for me on each and every folder switch -- across accounts, within
account, all types of accounts.  It is very in-your-face these days.
->moz0.9.1, would be good if we had a simple test case (outside of full
mail/news) that can reproduce this.
Target Milestone: mozilla0.9 → mozilla0.9.1
I'm not sure what you mean by "outside of full mail/news". But within mailnews,
all it takes is steps such as these (remember this has morphed a bit since
originally written):
1.  Open a profile, select/login to IMAP inbox. Select a message, header
envelope appears.
2.  Select Local Folders (acct level).
3.  Select the IMAP inbox again, select a message.  No header envelope displays
until you move the splitter to resize the message/thread panes.
I just meant a test case that involved a simpler UI, to help isolate the
possible causes.
It would be great if this does make it for 0.9.1.  Lisa, I know that there are
people who have provided test cases for layout.  Is there someone who can try to
come up with something simulating the problem in mailnews?
I will check out on IRC.
*** Bug 73449 has been marked as a duplicate of this bug. ***
nominating mozilla0.9. mail/news isn't too useful w/ this bug.
Keywords: mozilla0.9
no help from IRC folks.  Will have to cc: jrgm on this to see if he can have
time to create a simple test case.
*** Bug 72619 has been marked as a duplicate of this bug. ***
Blocks: 73672
This bug seems to have become much more prevalent with the new outliner widget
in mail.  Moving to nscatfood+, removing crufty old keywords & whiteboard status
junk.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] relnote-user
I'm still not noticing this at all, but I am seeing message bodies disappear
quite often.  
I will work on a simplified test case today (assuming I can whittle it down
to something simpler, and keep the relevant behaviour). 
*** Bug 76483 has been marked as a duplicate of this bug. ***
This used to happen from time to time.  In recent builds it happens just about
all the time.  It's getting much worse.

Seeing this every day on two different machines (one Win2k PIII 1GHz, the other
a WinNT 4.0 PIII 650), and it's been around since at least 0.7. Making mail very
painful to use.
Judging by the lack of activity on this bug since RTM, it seems that nobody in
layout will have time to provide a fix for this any time soon.... so we need
another workaround that works, now that the last workaround stopped working.  

I just so happen to have a brand-spanking new workaround for us all to enjoy.

Setting the style attribute on an element causes it's frames to be destroyed and
re-created, thus initiating a reflow.  So, by simply re-setting the style
attribute on msgHeaderView to whatever it's current value is (even if that value
is ""), we force a reflow, and the header always gets updated after you switch
folders. Woohoo!

With this workaround in we can remove the old workaround, which was only
slightly yuckier.
Joe, won't this make us slower since we're reflowing sometimes when we don't
need to?
timeless tells me that frame-recreation after setting the style attribute is a
serious perf bug that will be fixed someday, so my workaround isn't such a good
idea.
Personally, I think it's the best way to force a reflow that we've got right
now, however hacky it is...
I'd take a performance hit in order to get correctness.  

this bug has been haunting us for a while.

any idea on how bad the performance hit is?  stephend, do you have the cycles to
run with this patch and compare message display (and multiple delete) times with it?
Will do today.  I'll be in the lab testing Shaver's perf patch for msg compose,
so I might as well get 2 tests done (his patch shouldn't affect ours). I'll post
results of Joe's patch here.  Win98 will have to do, it's the only OS that I can
build on...
I doubt there would be much of a performance hit.  The extra reflow only takes
place on the first message after you switch folders.
Okay, so realizing Joe's patch may be just a temp "fix", I ran the build on
Windows 98 (same machine as my performance tests) and here's what I came up with:

To save space on an already hugely commented bug, I'll just attach my
comments/timings.
I'm not sure I count for r=stephend@netscape.com, but I've applied, built, ran 
with and timed the patch with my tree, so I guess that counts, somewhat.  Looks 
good to me.  It's so nice not to have headers disappearing...
the shaver / hyatt patch was for reply and should not affect us here, right?

just to make sure I got it right:

hewitt's patch slows us down by 33% percent on your low end machine.
(33% slow down, 2 seconds slower, 6 -> 8 seconds)

I can test on a high end machine and see what I get.  (I'm guessing that the
beefier the machine, the less impact.)

I'd take correctness vs. the slow down, but I'd like the real fix most of all.

perhaps hewitt's hack can inspire a correct fix within layout?
Seth: my intepretation of the results shows a speedup in today's build with the 
patch applied compared to the 13th (granted that that's probably attributable 
to many different things)
Blake's right.  The main thing here is that I saw no slowdown.  I'll test the
comm builds tomorrow to see how they're doing in regards to the 13th.
Shaver's patch (which included a patch from Hyatt) was for message compose, but
he said if anything, it should only speed us up in message display (although he
wasn't certain his patch was capable of doing such.)
I must have read the numbers wrong.

if no performance hit, then I'm all for this (until the real problem is fixed.)

worth taking for 0.9, too.

we should keep the layout bug open (since it is still valid) and open a bug to
remove the hack when the problem is fixed.

r=sspitzer, approach bienvenu for a sr=.  too bad mscott's not around, he'd be
an ideal reviewer since it is msg display.
sr=bienvenu - yes, the performance results were confusing because the 4/23
results are actually faster, obviously not as a result of this patch. Since it
only affects the first message load after a folder switch, it's not the end of
the world if it slows us down a little until a better fix can be found.
a= asa@mozilla.org for checkin to 0.9
Do you know which build this fix will first appear in? I'm still seeing this in
2001-04-26-04.
Whens this getting checked into the trunk ?
Can't speak directly for Joe, but pretty sure he'll land it Monday, when he
returns (or maybe this weekend).
checked in workaround, marked 77581 fixed.  Should this stay open for layout
problem, or create another bug?
fix checked onto .9 branch as well
FYI:  workaround bug 77581 -- looks good after a days use of apr27 commrcial
trunk build win98, mac OS 9.0 and linux rh6.2.  Any comments on current
workaround fix will be/should be logged in bug 77581.
->0.9.2, since there is now a usable workaround
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I think I've found a way to reliably reproduce this bug. I don't believe this is
a "corner case", and therefore, I think it should stay open, and we should try
to find a fix for 0.9.1.

Using 2001-04-30-04 (commercial) on WinNT.

1. Launch MoJo
2. Start Mail (Tasks | Mail); supply password when prompted
3. Select Inbox
4. Select the thread of an unread message

Result: the message contents and envelope display correctly in the lower right
pane of Mail.

5. Change the status of the message back to "unread" by clicking on the grey dot
in the thread pane and turning it back into a green dot (the unread indicator).

Note: When you do this, the contents of the message pane are wiped out - this
might be a separate bug.

6. Now select from the thread pane a message that you have previously read.

Expected result: Message pane is updated to display the message body *and* the
message envelope.

Actual result: Message pane is updated and only displays the message body, not
the message envelope. Must resize the message pane to force the message envelope
to display.
Sol,

Part of what you are seeing sounds like 78529 I saw on the 4/30 build but which
has since been fixed.  If you get a more recent build, do you still see this?
cc: sol.  Sol - pls refer to Scott's previous comments to you.
I can't reproduce Sol's scenario using today's bits on Win98.
Blocks: 75643
I am also unable to reproduce using more recent builds.
->1.0
Target Milestone: mozilla0.9.2 → mozilla1.0
Blocks: 104166
Just so you all know http://bugzilla.mozilla.org/show_bug.cgi?id=103021 is a
100% testcase for a slightly edge-case bug involving this.
in bug 108638 (reported on Win98) headers vanish if you:
ctrl+a to select all messages, then click a message to undo selection.
Reporer believes he must select another folder to see headers again.
On Linux, resize window or pane: Headers snap back in place.
Evaughan: will you be triaging this to a real 1.0 milestone?  If not, is there
someone else who should own it?
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
I'm not sure about the status of this bug. But, I see this again using
yesterdays commercial bits on win2k.  

When I try to read a msg, the headers doesn't show up. Reading another msg shows
the headers. (Note the there are other bugs about headers displaying *'s)

Should I open a new bug to track this? 
Keywords: nsbeta1
I think its a new bug - the header area is appearing, but the headers themselves
are showing "*"'s - seems like the header listener isn't firing the first time a
message is loaded in a folder
Bug 109950 covers "*"'s in the message headers.
nsbeta1- per ADT triage. 
Keywords: nsbeta1nsbeta1-
Is there anything reproducible left in this bug?
No longer blocks: 75643
This occasionally comes back for some users, but it has always been hard to
reproduce reliably.
Product: Browser → Seamonkey
No comments in almost six years. WFM on "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008032901 SeaMonkey/2.0a1pre". Is ANYone still seeing this bug?
Two week past, no reply, WFM.
Status: REOPENED → RESOLVED
Closed: 24 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: