Hi Stef,

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.

The problem with reverting the change to tryInvokeHalo: is that it
reverts what that change fixed.  I think it won't be very hard to step
through that in the debugger and see why its happening.  I'll try to
take a look tomorrow or this week.

I also support Marcel's idea of defining how we want it to work in some tests.

Best,
  Chris



On Wed, Apr 24, 2019 at 7:13 AM Stéphane Rollandin
<lecteur at zogotounga.net> wrote:
>
> Hello all,
>
> To see a bug in the halo targets dispatch mechanism, do the following:
>
> - Open a fresh image, use the alphabetical list from the "new morph..."
> item in the World menu to get a SameGame morph.
>
> - Put the SameGame morph above the "Welcome to Squeak" window.
>
> - Blue click three times in a row within the SameGame inner part: this
> will give a halo to one of the small square tiles.
>
> - Now blue click on the grey border of the SameGame morph (say, at
> left): instead of that morph getting the halo, it will go to the
> "Welcome to Squeak" window in the back. That is the bug.
>
> Reverting #tryInvokeHalo: in PasteUpMorph to its previous version fixes
> it (the current implementation discards the first morph in the targets
> stack, which happens in this case to be the target we do want).
>
>
> Stef
>