In the compose window, the splitter separating the compose area and the addressing widget can be dragged down completely to hide the compose area. Is that wanted? Should we set a minheight on the <editor id="content-frame"> element?
Yes we should impose some minimal size for the compose area.
Created attachment 8586932 [details] [diff] [review] patch
Comment on attachment 8586932 [details] [diff] [review] patch Review of attachment 8586932 [details] [diff] [review]: ----------------------------------------------------------------- Looks reasonable, but if you're touching it please move the id attr first.
Attachment #8586932 - Flags: review?(mkmelin+mozilla) → review+
Created attachment 8588371 [details] [diff] [review] patch v1.1 Thanks. I have done the same thing for Seamonkey, however I have not tested if it actually works.
Not sure if this happens on TB as well, but if you keep dragging the splitter down then the bottom of the window keeps jumping further down until it is off the bottom of the screen. Not sure if this intended / expected.
No, I can't see that. On TB the splitter just hits "a wall" and does not move further. The window itself does not move or enlarge. With the patch the "wall" is 100px above the status bar of the window. Without the patch the wall is 0px above the status bar so the compose area is completely obscured. But I have tried to install Seamonkey (the latest version for win32 I found is 2.34a1). Without the patch I could drag the splitter BELOW the bottom edge of the compose window. So it obscured the status bar and vanished behind the bottom of the window. The bottom did not move so it clipped the splitter and everything. The patch only had the effect that the splitter pushed the status bar 100px before itself. But they still could be dragged below the window bottom. I found out this effect can be disabled by removing the "resizeafter=grow" attribute from the splitter. That attribute is used nowhere else in the tree, except 2 uses in SM.
Flags: needinfo?(acelists) → needinfo?(iann_bugzilla)
Neil, do you know if resizeafter=grow on splitters is actually still useful/needed for SM? It seems it is the only user left: http://mxr.mozilla.org/comm-central/search?string=resizeafter&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central
(In reply to aceman from comment #7) > Neil, do you know if resizeafter=grow on splitters is actually still > useful/needed for SM? I believe it's needed for bug 60864, although it might be possible to work around the problem in code (see bug 514416 for a similar problem involving splitters).
I think Neil answered the query.
OK, I see. But TB is not affected by bug 60864 even without resizeafter=grow. Maybe because the addressing area can't be completely collapsed. And it also does not have the collapsible toolbars. And the side-effects (dragging splitter and status bar outside of window?!) of resizeafter=grow in SM seem crazy to me, maybe even worse than bug 60864 :) But we do not need to fix that in this bug. Ian, just decide whether the patch here adds any value for Seamonkey. If not, I can easily drop the SM part.
Comment on attachment 8588371 [details] [diff] [review] patch v1.1 I guess this is better than existing behaviour r=me
Attachment #8588371 - Flags: review?(iann_bugzilla) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 40.0
You need to log in before you can comment on or make changes to this bug.