[squeak-dev] regular Browser still messing the lowerPane

Ah, i thought i got a solution applying mantis patch for
DependentsArray, but no, it still bugs from time to time.
After some time, the code pane does not occupy the whole window,and/or
overlaps with class comments...

The problem is located in the method below. Sometimes, no AlignmentMorph
will have a layoutFrame bottomFraction = 1.
Consequence is that the #browserLowerPane property is then missing, what
you can observe by exploring the BrowserCommentTextMorph in the
dependents of a broken Browser.

If someone want to help tracking, simply add following halt:


BrowserCommentTextMorph>>noteNewOwner: win
        super noteNewOwner: win.
        self setProperty: #browserWindow toValue: win.
        win ifNil: [ ^self ].
        win setProperty: #browserClassCommentPane toValue: self.
        self setProperty: #browserLowerPane toValue: (win submorphThat: [ :m |
m isAlignmentMorph and: [ m layoutFrame bottomFraction = 1 ]] ifNone: [
                self halt: 'DEBUG ME, I JUST LOST MY LOWER PANE'. nil]).


Of course, since I added the halt, the bug refused to show up!

I suspect it is related to World loop and other-complicated morph layout
management. Maybe if some Morph wishing to display happens to inquire
its bound, fullBounds or something that triggers some bound/layout
machinery just before the BrowserCommentTextMorph had time to install
correctly...

My clues: if you try to debug with 'toggle breakpoint on entry' on above
method, then the bug will show every time.

Broken AlignmentMorph has a bottom layout of 0.75.
This is the layout of the PluggableTextMorph holding code before the
BrowserCommentTextMorph is removed.
I guess this layout propagates incorrectly to the above AlignmentMorph,
don't really know how (too hard to debug a World loop without interacting!).

A possible workaround might be to search for alignmentMorph with a
bottomFraction = 0.75 or maybe nil ifNone... and fix it back to 1.
But I don't like such heavy workarounds.

Nicolas

nice wrote:
Ah got a reliable way to reproduce it!

Select a class so as to show the class comment, collapse the browser,
expand it, et voila, the halt is encountered...

In SystemWindow>>collapseOrExpand, self addMorph: ...

I suspect (self world startSteppingSubmorphsOf: m) is triggering a
layout inquiry, and this inquiry is messing the morph layout before all
sub morphs had a chance to regenerate...

Only a guess...

Nicolas

nice wrote:
Wrong guess, it was much simpler:

When the BrowserCommentTextMorph is active, then the code AlignmentMorph
bottomFraction is 0.75 not 1...

So, when expanding the window, no AlignmentMorph will have a
bottomFraction = 1.

This is at http://bugs.squeak.org/view.php?id=7012 (and sorry Ken, just
forgot to classify Tools...).

Nicolas