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.

#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.

*** Bug 40716 has been marked as a duplicate of this bug. ***

[nsbeta2-]

nominate for nsbeta3 then.

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-

Putting on [nsbeta2+] radar for beta2 fix.

*** Bug 40716 has been marked as a duplicate of this bug. ***

This works just fine for me. All areas appear correctly.

Well I only tried it on windows and it appears only to happen on mac and linux. Gary want to take a look?

To Gary...

*** Bug 43849 has been marked as a duplicate of this bug. ***

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.

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.

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.

Okay, I'll try the commercial builds then.

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.

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+

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

Looks OK to me using aug25 commercial build, Linux rh6.0, NT 4.0 and mac OS 9.0

Just saw this using 2000-09-26-09-MN6 linux commercial build. Reopening.

*** 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.

nsbeta3-, nominate for rtm

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. ***

rtm+, but 'need info' until the fix is ready to land.

Pulling a build will update when I reproduce the problem.

PDT marking [rtm need info] until patch and code reviews are available.

*** 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.

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.

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

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.

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!

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.

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.

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.

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

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.

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. ***

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.

*** 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

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.

*** Bug 69369 has been marked as a duplicate of this bug. ***

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.

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.

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. ***

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.

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

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.

I am also unable to reproduce using more recent builds.

->1.0

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)

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?

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.

Is there anything reproducible left in this bug?

This occasionally comes back for some users, but it has always been hard to reproduce reliably.

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.