A while ago somebody updated some code for system windows ( in 2.8 alpha ? ), 
more specifically it helped with the optional buttons. 
Those reside in aligment morphs and streched often outside the
bounds of the system window before the change i mention. 

Karl

"Norton, Chris" wrote:
> 
> Hi Jim.
> 
> Jim Benson wrote:
> "Part of this bug is the way that the AlignmentMorph draws. If you look at
> the method:
> 
> AlignmentMorph#drawSubmorphsOn:
> 
> You'll notice that it clips to the bounds of the owner Morph. In a
> SystemWindow, that includes the frame area. Consequently, the frame area
> gets over written. Note that this is also true of a SystemWindow without the
> window frame code filed in, in the example that you have a border width > 1
> for a regular SystemWindow. One solution is to check if the owner is a
> SystemWindow and ask for the inner bounds, but I'm not sure what the general
> purpose solution should be. I'd like to hear suggestions. I would think that
> you always want to write within the borders of the owner morph, but I don't
> know what the consequences of that are."
> 
> [Chris Norton]  I haven't given this much thought, but it strikes me that
> submorphs should never be allowed to write beyond the bounds of their
> owners.  Given that assumption, it would seem to me that all owners should
> support an "innerBounds" or a region that their submorphs can freely step
> on.  If all morphs support the "innerBounds" convention, then any given
> morph can only resize up to the size of it's owner's innerBounds.
> 
> What do you think?  I think this should be a convention that all morphs
> subscribe to.
> 
> Cheers,
> 
> ---==> Chris