[squeak-dev] Bug in #tryInvokeHalo:

St├ęphane Rollandin lecteur at zogotounga.net
Thu Apr 25 07:58:34 UTC 2019

> I just tried those steps.  I can reproduce the problem when I click in
> the *gray area* (e.g., parent-most morph) on the right side of the
> halos, but when its in that same gray area on the left hand side, or
> any other morph like the Help button, it works.  Very strange.  There
> must be something unique about this particular "Same" game's Morph
> structure or w.r.t. how it interacts with the new implementation of
> #tryInvokeHalo:.  This is the first Morph I've seen behave this way.

No, the bug is very general - I just gave fast and easy steps to 
reproduce it. But you can just compose three morphs (Morph instances), a 
big one with two smaller ones as children, and you get the same problem 
in areas where the top morph overlaps a system window.

As I said, the problem is "simply" that #tryInvokeHalo: builds a stack 
of potential targets at the clicked point, then for some reason that I 
did not investigate discards the first one with the explicit comment 
"existingHalo is first on the stack, not a target", while it *is* the 
target here.



More information about the Squeak-dev mailing list