Closed
Bug 39655
Opened 25 years ago
Closed 17 years ago
Switch folder after resize msg pane hides header envelope until another resize
Categories
(SeaMonkey :: MailNews: Message Display, defect, P2)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla1.0.1
People
(Reporter: laurel, Assigned: eric)
References
Details
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details |
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.
Comment 1•25 years ago
|
||
#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
Comment 5•25 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-]
Assignee | ||
Comment 8•24 years ago
|
||
This works just fine for me. All areas appear correctly.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 9•24 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 → ---
Comment 11•24 years ago
|
||
*** Bug 43849 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Target Milestone: --- → M18
Comment 12•24 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•24 years ago
|
||
I can repro this on Win98 using today's verification build.
Comment 14•24 years ago
|
||
*** Bug 45648 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
So I just tried this on MacOS and it worked fine... does it happen every time?
Reporter | ||
Comment 17•24 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•24 years ago
|
||
This is consistently happening on win32 commercial build 2000-07-17-09.
Comment 19•24 years ago
|
||
can't reproduce this anymore, tried using today's bits on Mac, Windows and Linux.
resolving as wfm.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 20•24 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•24 years ago
|
||
Okay, I'll try the commercial builds then.
Whiteboard: [nsbeta2+] → [nsbeta2+] 7/24
Reporter | ||
Comment 22•24 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•24 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•24 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•24 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•24 years ago
|
||
saari sez fixing bug 41740 (see patches) fixes this problem. mscott, what say
you?
Comment 27•24 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•24 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•24 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•24 years ago
|
||
Per todays triage, moving to nsbeta2-. Will relnote for PR2.
Keywords: relnote2
Whiteboard: [nsbeta2+] 7/24 → [nsbeta2-] 7/24
Comment 31•24 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 33•24 years ago
|
||
I don't see this on linux anymore... will try other platforms asap
Comment 34•24 years ago
|
||
Does anyone else see this still?
Comment 35•24 years ago
|
||
can't repro using today's bits on Win98 & Linux, resolving as wfm
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 36•24 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•24 years ago
|
||
Just saw this using 2000-09-26-09-MN6 linux commercial build.
Reopening.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 38•24 years ago
|
||
*** Bug 54228 has been marked as a duplicate of this bug. ***
Comment 39•24 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•24 years ago
|
||
nsbeta3-, nominate for rtm
Keywords: rtm
Whiteboard: [nsbeta2-] [nsbeta3+] → [nsbeta2-] [nsbeta3-]
Comment 41•24 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•24 years ago
|
||
*** Bug 54355 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
rtm+, but 'need info' until the fix is ready to land.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-] [nsbeta3-] [rtm+ need info]
Assignee | ||
Comment 44•24 years ago
|
||
Pulling a build will update when I reproduce the problem.
Status: NEW → ASSIGNED
Comment 45•24 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•24 years ago
|
||
*** Bug 54955 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
*** Bug 55526 has been marked as a duplicate of this bug. ***
Comment 48•24 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•24 years ago
|
||
Any update about the status of this bug? Thanks!
Assignee | ||
Comment 50•24 years ago
|
||
I have been working on this but no luck yet. Its very ellusive tracking it down.
Comment 51•24 years ago
|
||
Time to cut this one. ->rtm-/future.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm need info] → [nsbeta2-] [nsbeta3-] [rtm-]
Target Milestone: M18 → Future
Comment 52•24 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•24 years ago
|
||
marking mostfreq, we have 9, putterman suggests we'll get more; I agree.
Keywords: mostfreq
Comment 54•24 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•24 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•24 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•24 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•24 years ago
|
||
adding self to cc list.
Comment 59•24 years ago
|
||
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.
Comment 60•24 years ago
|
||
Comment 61•24 years ago
|
||
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+]
Comment 62•24 years ago
|
||
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 63•24 years ago
|
||
Comment 64•24 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++]
Comment 65•24 years ago
|
||
I forgot to say "r=putterman"
I'll land the fix as soon as the tree opens.
thanks for the quick turn around, jar.
Comment 66•24 years ago
|
||
updating status whiteboard.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm++] → [nsbeta2-] [nsbeta3-] [rtm++] landing workaround today, 10-17
Comment 67•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 68•24 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•24 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•24 years ago
|
||
hmm...I don't see this bug in today's branch builds on all platforms.
Reporter | ||
Comment 71•24 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•24 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•24 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•24 years ago
|
||
er, I mean triggering, not causing :)
Comment 75•24 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•24 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.
Updated•24 years ago
|
Keywords: relnote → relnoteRTM
Reporter | ||
Comment 77•24 years ago
|
||
Just an update: seeing this a lot, very easy to get into this state with Win98
using oct30 rtm candidate.
Comment 78•24 years ago
|
||
*** Bug 55321 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.8
Reporter | ||
Comment 79•24 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•24 years ago
|
||
*** Bug 63532 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 81•24 years ago
|
||
update: seeing fairly frequently in latest (jan23) trunk commercial build, win98.
Comment 82•24 years ago
|
||
I've seen this too a couple of times but not a lot.
Comment 84•24 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•24 years ago
|
||
*** Bug 69369 has been marked as a duplicate of this bug. ***
Comment 87•24 years ago
|
||
Just an update: I'm seeing this bug all the time these days. It is highly visible.
Reporter | ||
Comment 88•24 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•24 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•24 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•24 years ago
|
||
I just meant a test case that involved a simpler UI, to help isolate the
possible causes.
Comment 92•24 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•24 years ago
|
||
I will check out on IRC.
Reporter | ||
Comment 94•24 years ago
|
||
*** Bug 73449 has been marked as a duplicate of this bug. ***
Comment 95•24 years ago
|
||
nominating mozilla0.9. mail/news isn't too useful w/ this bug.
Keywords: mozilla0.9
Comment 96•24 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•24 years ago
|
||
*** Bug 72619 has been marked as a duplicate of this bug. ***
Comment 98•24 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.
Whiteboard: [nsbeta2-] [nsbeta3-] [rtm-] relnote-user
Comment 99•24 years ago
|
||
I'm still not noticing this at all, but I am seeing message bodies disappear
quite often.
Comment 100•24 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•24 years ago
|
||
*** Bug 76483 has been marked as a duplicate of this bug. ***
Comment 102•24 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•24 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.
Comment 104•24 years ago
|
||
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 105•24 years ago
|
||
Comment 106•24 years ago
|
||
Joe, won't this make us slower since we're reflowing sometimes when we don't
need to?
Comment 107•24 years ago
|
||
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•24 years ago
|
||
Personally, I think it's the best way to force a reflow that we've got right
now, however hacky it is...
Comment 109•24 years ago
|
||
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...
Comment 111•24 years ago
|
||
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...
Comment 115•24 years ago
|
||
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•24 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.)
Comment 119•24 years ago
|
||
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•24 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.
Comment 121•24 years ago
|
||
a= asa@mozilla.org for checkin to 0.9
Comment 122•24 years ago
|
||
Do you know which build this fix will first appear in? I'm still seeing this in
2001-04-26-04.
Comment 123•24 years ago
|
||
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).
Comment 125•24 years ago
|
||
checked in workaround, marked 77581 fixed. Should this stay open for layout
problem, or create another bug?
Comment 126•24 years ago
|
||
fix checked onto .9 branch as well
Reporter | ||
Comment 127•24 years ago
|
||
Comment 128•24 years ago
|
||
->0.9.2, since there is now a usable workaround
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 129•24 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•24 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•24 years ago
|
||
cc: sol. Sol - pls refer to Scott's previous comments to you.
Comment 132•24 years ago
|
||
I can't reproduce Sol's scenario using today's bits on Win98.
Comment 133•24 years ago
|
||
I am also unable to reproduce using more recent builds.
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•23 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•23 years ago
|
||
Evaughan: will you be triaging this to a real 1.0 milestone? If not, is there
someone else who should own it?
Comment 138•23 years ago
|
||
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•23 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•23 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•23 years ago
|
||
Bug 109950 covers "*"'s in the message headers.
Comment 144•23 years ago
|
||
This occasionally comes back for some users, but it has always been hard to
reproduce reliably.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 145•17 years ago
|
||
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?
Comment 146•17 years ago
|
||
Two week past, no reply, WFM.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•