nice wrote:
> nice wrote:
>> 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!
>>
> 
> 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...
> 

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