> > 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.

Strange, I just wrote the following code to try it:

| a b c| a := Morph new extent: 200 at 200.
b := Morph new color: Color green; position: 50 at 50.
c := Morph new color: Color yellow; position: 100 at 100.
a addMorphBack: b; addMorphBack: c; openInHand

and it worked.  But then, I did it again, and it didn't.

> 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.

Ah!  That's the clue we needed.  I'm not exactly sure why the halo
morph wouldn't be the top one on the stack either, but this patch uses
a much more-resilient way to do that.  Let me know if this works,
we'll commit it to trunk.

Best,
  Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PasteUpMorph-tryInvokeHalo.st
Type: application/squeak-changeset
Size: 2327 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190425/7d04e134/attachment.bin>