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

RESOLVED WORKSFORME

Status

P2
major
RESOLVED WORKSFORME
19 years ago
5 years ago

People

(Reporter: laurel, Assigned: eric)

Tracking

Trunk
mozilla1.0.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
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. ***

Comment 3

19 years ago
[nsbeta2-]
Whiteboard: [nsbeta2-]

Comment 4

19 years ago
nominate for nsbeta3 then.
Keywords: nsbeta3

Comment 5

19 years ago
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-]

Comment 6

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
*** Bug 40716 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

19 years ago
This works just fine for me. All areas appear correctly.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 9

19 years ago
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 → ---
(Assignee)

Comment 10

19 years ago
To Gary...
Assignee: evaughan → garyf
Status: REOPENED → NEW

Comment 11

19 years ago
*** Bug 43849 has been marked as a duplicate of this bug. ***
Target Milestone: --- → M18

Comment 12

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

Comment 13

19 years ago
I can repro this on Win98 using today's verification build.

Comment 14

19 years ago
*** Bug 45648 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
reassigning to saari.
Assignee: garyf → saari

Comment 16

19 years ago
So I just tried this on MacOS and it worked fine... does it happen every time?
(Reporter)

Comment 17

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

Comment 18

19 years ago
This is consistently happening on win32 commercial build 2000-07-17-09.

Comment 19

19 years ago
can't reproduce this anymore, tried using today's bits on Mac, Windows and Linux.
resolving as wfm.
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 20

19 years ago
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 → ---

Comment 21

19 years ago
Okay, I'll try the commercial builds then.
Whiteboard: [nsbeta2+] → [nsbeta2+] 7/24
(Reporter)

Comment 22

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

Comment 23

19 years ago
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)?

Comment 24

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

Comment 25

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

Comment 26

19 years ago
saari sez fixing bug 41740 (see patches) fixes this problem. mscott, what say 
you?

Comment 27

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

Comment 28

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

Comment 29

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

Comment 30

19 years ago
Per todays triage, moving to nsbeta2-.  Will relnote for PR2.
Keywords: relnote2
Whiteboard: [nsbeta2+] 7/24 → [nsbeta2-] 7/24

Comment 31

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

Comment 32

19 years ago
nsbeta3+
Whiteboard: [nsbeta2-] 7/24 → [nsbeta2-] [nsbeta3+]

Updated

19 years ago
Keywords: mailtrack

Comment 33

19 years ago
I don't see this on linux anymore... will try other platforms asap

Comment 34

19 years ago
Does anyone else see this still?

Comment 35

19 years ago
can't repro using today's bits on Win98 & Linux, resolving as wfm
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 36

19 years ago
Looks OK to me using aug25 commercial build, Linux rh6.0, NT 4.0 and mac OS 9.0
Status: RESOLVED → VERIFIED

Comment 37

19 years ago
Just saw this using 2000-09-26-09-MN6 linux commercial build.

Reopening. 
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 38

19 years ago
*** Bug 54228 has been marked as a duplicate of this bug. ***

Comment 39

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

Comment 40

19 years ago
nsbeta3-, nominate for rtm
Keywords: rtm
Whiteboard: [nsbeta2-] [nsbeta3+] → [nsbeta2-] [nsbeta3-]

Comment 41

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

Comment 42

19 years ago
*** Bug 54355 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

19 years ago
Keywords: relnote3

Comment 43

19 years ago
rtm+, but 'need info' until the fix is ready to land.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-] [nsbeta3-] [rtm+ need info]
(Assignee)

Comment 44

19 years ago
Pulling a build will update when I reproduce the problem.
Status: NEW → ASSIGNED

Comment 45

19 years ago
PDT marking [rtm need info] until patch and code reviews are available.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm+ need info] → [nsbeta2-] [nsbeta3-] [rtm need info]

Comment 46

19 years ago
*** Bug 54955 has been marked as a duplicate of this bug. ***

Comment 47

19 years ago
*** Bug 55526 has been marked as a duplicate of this bug. ***

Comment 48

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

Comment 49

19 years ago
Any update about the status of this bug? Thanks!
(Assignee)

Comment 50

19 years ago
I have been working on this but no luck yet. Its very ellusive tracking it down.

Comment 51

19 years ago
Time to cut this one.  ->rtm-/future.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm need info] → [nsbeta2-] [nsbeta3-] [rtm-]
Target Milestone: M18 → Future

Comment 52

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

Comment 53

19 years ago
marking mostfreq, we have 9, putterman suggests we'll get more; I agree.
Keywords: mostfreq

Comment 54

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

Comment 55

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

Comment 56

19 years ago
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
(Assignee)

Comment 57

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

Comment 58

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

Comment 64

19 years ago
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
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 68

19 years ago
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 → ---
(Reporter)

Comment 69

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

Comment 70

19 years ago
hmm...I don't see this bug in today's branch builds on all platforms.
(Reporter)

Comment 71

19 years ago
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.
(Reporter)

Comment 72

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

Comment 73

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

Comment 74

19 years ago
er, I mean triggering, not causing :)

Comment 75

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

Comment 76

19 years ago
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, relnote3 → relnote
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] → [nsbeta2-] [nsbeta3-] [rtm-] relnote-user
(Reporter)

Updated

19 years ago
Keywords: relnote → relnoteRTM
(Reporter)

Comment 77

19 years ago
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. ***
(Assignee)

Updated

19 years ago
Target Milestone: Future → mozilla0.8
(Reporter)

Comment 79

19 years ago
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
(Reporter)

Comment 80

19 years ago
*** Bug 63532 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 81

18 years ago
update: seeing fairly frequently in latest (jan23) trunk commercial build, win98.

Comment 82

18 years ago
I've seen this too a couple of times but not a lot.

Comment 83

18 years ago
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9

Comment 84

18 years ago
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
(Reporter)

Comment 85

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

Comment 86

18 years ago
p2
Priority: P3 → P2

Comment 87

18 years ago
Just an update: I'm seeing this bug all the time these days. It is highly visible. 
(Reporter)

Comment 88

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

Comment 89

18 years ago
->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
(Reporter)

Comment 90

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

Comment 91

18 years ago
I just meant a test case that involved a simpler UI, to help isolate the
possible causes.

Comment 92

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

Comment 93

18 years ago
I will check out on IRC.
(Reporter)

Comment 94

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

Comment 95

18 years ago
nominating mozilla0.9. mail/news isn't too useful w/ this bug.
Keywords: mozilla0.9

Comment 96

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

Comment 97

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

Updated

18 years ago
Blocks: 73672

Comment 98

18 years ago
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.
Keywords: nsbeta2, nsbeta3, relnoteRTM, rtm → nsCatFood+
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] relnote-user

Comment 99

18 years ago
I'm still not noticing this at all, but I am seeing message bodies disappear
quite often.  

Comment 100

18 years ago
I will work on a simplified test case today (assuming I can whittle it down
to something simpler, and keep the relevant behaviour). 
(Reporter)

Comment 101

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

Comment 102

18 years ago
This used to happen from time to time.  In recent builds it happens just about
all the time.  It's getting much worse.

Comment 103

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

Comment 106

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

Comment 108

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

Comment 116

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

Comment 120

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

Comment 122

18 years ago
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
(Reporter)

Comment 127

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

Comment 128

18 years ago
->0.9.2, since there is now a usable workaround
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 129

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

Comment 130

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

Comment 131

18 years ago
cc: sol.  Sol - pls refer to Scott's previous comments to you.

Comment 132

18 years ago
I can't reproduce Sol's scenario using today's bits on Win98.

Updated

18 years ago
Blocks: 75643

Comment 133

18 years ago
I am also unable to reproduce using more recent builds.

Comment 134

18 years ago
->1.0
Target Milestone: mozilla0.9.2 → mozilla1.0

Updated

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

Comment 136

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

Comment 137

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

Comment 139

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

Comment 140

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

Comment 141

18 years ago
Bug 109950 covers "*"'s in the message headers.

Comment 142

17 years ago
nsbeta1- per ADT triage. 
Keywords: nsbeta1 → nsbeta1-

Comment 143

17 years ago
Is there anything reproducible left in this bug?
No longer blocks: 75643

Comment 144

17 years ago
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
Last Resolved: 19 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.