[squeak-dev] Bug in #tryInvokeHalo:

Marcel Taeumel marcel.taeumel at hpi.de
Wed Apr 24 12:46:58 UTC 2019


Hi Stef,

I recall a discussion about this halo-dispatch behavior with Chris not too long ago. We do need tests for this halo dispatch to both document and verify the desired behavior.

Maybe we can try list and discuss the desired dispatch here, then we can try to write tests for it. (Blue-click) event simulation is not that hard. See UserInputEventTests >> #blueMouseDownAt: and MorphicEventTests.

Best,
Marcel
Am 24.04.2019 14:13:17 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190424/0ca2d1c7/attachment.html>


More information about the Squeak-dev mailing list