Closed Bug 57752 Opened 24 years ago Closed 21 years ago

Corrupted mail folder display when opening 3-pane mail view

Categories

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

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: rgavlin, Assigned: scottputterman)

References

(Blocks 1 open bug)

Details

(Whiteboard: [rtm-])

Attachments

(2 files, 1 obsolete file)

I have 3-pane mail view configured with mail folder top left, message list top right, and message preview bottom. Whenever I open mail, the mail folder display is corrupted. I must collapse and then expand a mail folder to refresh the display. This is painful.
Keywords: rtm
what do you mean by corrupted, do you have a screen shot?
Attached file Screenshots
For some reason, the mail/news folders tree pane in the 3-pane view has major refreshing/painting problems. I don't see the problem with other trees in the application. Unfortunately, the problem presents itself whenever I open mail for the first time. It is often a problem when I try to resize the width of the pane as well.
what format is your attachment in?
My attachment is a Winzip file containing 3 BMP files which can be viewed using the bundled Windows Paint program.
thanks. reassigning to hyatt. It looks like there are some tree paint problems going on. I haven't seen this in the folder pane except for the case where scrolling causes it to mess up.
Assignee: putterman → hyatt
marking rtm need info to get on radar, possibly another symptom of the tree synch problems Hyatt is currently addressing. If this problem is specific to that pane arrangement, could we just disable it, or release note it? That isn't the default, is it? cc jrgm, selmer
Whiteboard: [rtm need info]
So, there seems to be a problem with either calculating the preferred widths for that mail window layout style (vertLayout), or with persisting the correct values to localstore. In general, the folderPane in that layout seems to mostly come up with a width ~100px no matter what size this was left in when you last exited the mailnews window. (However, there are some "magic" widths that do seem to "persist" correctly. rgavlin -- can you try this. Open the mailnews window and then resize the folderPane to be really wide (~350px or so). Then close the mailnews window and start it up again, and repeat. You should see that the width that appears on the second open (~180px) will persist through repeated openings.) At any rate, when that folderPane comes up in the very narrow size, the tree is layed out for that width. However, it does not update when the pane is then widened (like any user would do). But whether the tree were hosed or not, that unusable width for the folder pane is the bigger bug here, since a user has to widen that pane everytime (when using the vertical layout style). Perhaps evaughan can have a look at this. Maybe there is a simple CSS fix for this problem. (Otherwise, I think mailnews may need to consider whether they want to ship this optional layout style, given that it's not usable).
Status: UNCONFIRMED → NEW
Ever confirmed: true
I tried the "magic" folderpane width trick and it worked as John Morrison suggested.
I miss the Outlook/Netscape 4.x layout style with the folders available in a drop-down box. This layout is the closest I've been able to get to my preferred layout with Mozilla. I hope you don't have to disable it. But, disabling is probably better than the current behavior.
Scott: the <tree id='folderTree' .../> has a 'style="width:0px"'. Removing that attribute clears up this problem (checked on linux and windows). I get a reasonable width for the folderPane and threadPane when I remove that attribute. I would say that that is the way to go for RTM. (This is more of a box bug than a tree bug anyways, and the stuff that hyatt is working on will not address this problem). Attaching a patch for review/test/checkin, etc. and assigning to putterman. (Leaving [rtm need info] -- this is a very safe fix, and the alternative is to ship with vertLayout broken).
Assignee: hyatt → putterman
*** Bug 57558 has been marked as a duplicate of this bug. ***
marking rtm-. This is not the default view and scrolling the folder pane or moving the splitter to the left and back again makes the folder names show up. I agree that this is not very good for people who use this view, but I don't think it's worth trying to get in. We should try to land this on the trunk though.
Whiteboard: [rtm need info] → [rtm-]
Is bug 57558 covered by this bug? I will wait and see when the patch gets into trunk builds.
QA Contact: esther → laurel
*** Bug 57531 has been marked as a duplicate of this bug. ***
What's the status of this bug?
This bug seems to be fixed.
Ron, are you still seeing this bug with a recent build?
I don't know if this is a related problem, but I lost my e-mail folders when switching to a three-pane mail view (two on top, one on bottom). Everything was okay at first, but after messing around with the folders a little bit, everything disappeared and I got a weird looking display. (See screenshot.) I never did get the folders back, which makes me hesitate to use the e-mail client! Thanks for all your efforts -Ed
I am experiencing this problem in v.1.5 final. If I chose the alternate mail/news window view (folder list - left top, message list - right top, message text full width - bottom) the folder list is corrupt when I open a mail news session (bunch of ? marks and other punct marks but no visible folder list. .bh.
Comment on attachment 18169 [details] [diff] [review] simple patch; remove the 'style="width:0px"' on folderTree Patch obsoleted by { 1.89 sspitzer%netscape.com Sep 14 2002 } which changed |style="width:0px;"| to |style="min-width: 250px;"| .
Attachment #18169 - Attachment is obsolete: true
Comment on attachment 71115 [details] Screen shot - after email folder loss in 3-pane view Related/Duplicate to bug 154234 !?
I believe Serge is correct in comment 24; Ed Suominen's screenshot looks quite similar to the problem in bug 154234. I'm pretty sure this bug has been addressed by the change noted in comment 23. The original bug may or may not be directly related to this change -- those bitmaps appeared to have the pane's content sized more narrowly than the pane itself. At any rate, marking this WFM; anyone is welcome to reopen if they've seen that problem in recent builds. I've never seen it since starting to work with Mozilla when 1.0 came out.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: