Closed Bug 11478 Opened 21 years ago Closed 21 years ago

Mailnews thread pane no longer sizing to fit window


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

Windows NT


(Not tracked)



(Reporter: scottputterman, Assigned: scottputterman)


I'm starting out assigning this to layout, but maybe Hyatt would have an idea on
this as well.

Before the weekend, the Mailnews thread pane (where the headers are shown) used
to size to fit the window - that is, all columns in the tree would show up, as
well as a scrollbar.  Now, only the first two columns show up and you have to
resize the window so that it's pretty wide before you see all of the columns and
scrollbar.  It's like the way it was before we added the "table-layout: fixed"
style to the table.
Assignee: karnaze → hyatt
David, can you take a look at this. I haven't touched the table code during the
period in question.
Assignee: hyatt → alecf
OK, this is our problem, possibly. I'm going to reassign to Alec for help with
this but keep hyatt in the cc list and add Candice to the cc list.

Last week we changed 3panemail.html to 3panemail.xul.  I backed out this change
and sure enough this worked again.  The question is, what are we doing wrong in
mainews/base/resources/content/3panemail.xul that makes this not work out
correctly?  Is this one of those problems that will get solved when we move to
I don't see how this could be ours.
This is our 3pane XUL:
<!DOCTYPE window>

<xul:window xmlns=""
      onload = "">
<frameset rows="50%,50%">
  <frame name="thread" src="chrome://messenger/content/threadPane.xul"/>
  <frame name="messagepane" src="chrome://messenger/content/messagePane.xul"/>

looks right to me.

Any ideas on this?
Target Milestone: M10
moving to M10
I'm really lost on this one, I don't think this is us.
..passing off to hyatt. Thanks David..:)
Assignee: alecf → hyatt
Uhhh... I don't know that you can use frame sets in XUL.
You're going to want to switch to using evaughan's splitter eventually, and that
means making a XUL file composed of boxes, iframes, and splitters (no
framesets).  I would recommend just sticking with HTML until you're ready to
actually use the splitter widget.
FYI: Build 1999081101M9: Linux/Redhat 6.0

Overview: Can't resize the area between the thread pane and the Message
Envelope/Body using the divider. Must resize the entire window and then other
strange things happen.

Steps to Reproduce:
1. Open Mail
2. Select the Inbox and try moving the divider, up or down, between the thread
pane and the Message Envelope/Body. It doesn't resize.
3. Select a message in the thread pane and it displays its contents in the
Message Env/Body. Try moving the divider again. It doesn't resize.
4. Resize the entire window just a little and now I can move the divider down
and it resizes the Message Env/Body.
5. Moving the divider up is not increasing the size of the Message Envelope or
Messsage Body. It jumps a little and appears to be getting slightly smaller.
6. Without the mouse button pressed move the mouse over the divider and the
Message Env/Body appears to be getting smaller.
Adding nbaca to CC: list.
Closed: 21 years ago
Resolution: --- → WONTFIX
I don't consider it legal to be able to use framesets inside a XUL window like
that.  They technically have to comprise an entire HTML document, so expecting
a frameset to behave like an embeddable widget is asking a bit too much I think.

Switch over to using the <splitter>.
So, Scott - is there something you need to do different like what hyatt says?
Should I reopen this bug and assign to you then?
Component: Layout → Front End
Product: Browser → MailNews
QA Contact: petersen → lchiang
Resolution: WONTFIX → ---
Assignee: hyatt → putterman
Talked to Scott - there is still a problem from the user's perspective.  Reopen
and assign to Scott to implement what hyatt suggested.
Instead of logging a new bug, I thought i would bring this up here:

On Win and Linux M10 builds 1999082508, you can no longer get the scroll bar to
show up for the thread pane.  Before today, you could resize the window and the
scroll bar would appear, but this seems to be a regression.
Severity: normal → major
Hyatt sends this in email: "The bug 'tables ignore mcomputedwidth and
mcomputedheight' that I have is because of this problem."

Per jay's last comments, having no scroll bars warrants a higher severity.
Not that this means anything, but in my debug build from this morning I'm seeing
scrollbars with no problems.
Triaging to M11
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
I just checked in the fix with a lot of help from hyatt.
verified fixed on 9/3 builds on all 3 platforms
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.