Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002496 [Squeak] Morphic minor always 01-16-06 04:54 03-14-06 16:11
Reporter aking View Status public  
Assigned To
Priority normal Resolution fixed  
Status closed   Product Version 3.9
Summary 0002496: Can't open world menu after halo's opened
Description Right click on the background and bring up the halos. Left or middle click to cancel them. From then on, left click or middle click will not bring up a popup menu. I have to press ESC or move a window before it starts working again.
Additional Information
Attached Files [^] (224 bytes) 01-20-06 01:04 [^] (2,006 bytes) 02-23-06 07:09
 WorldMenuPopupFix-wiz.1.cs [^] (3,383 bytes) 02-25-06 07:56

- Relationships
related to 0006975new  [RFE] Better event distictions between drag, click and mouse up. 

- Notes
(0003572 - 161 - 173 - 173 - 173 - 173 - 173)
01-20-06 01:07

Added a fix for this issue. The halo wasn't removed from the hand, only from its owner.

Why is the opening of the world menu delayed if the world has a morph?
(0003968 - 685 - 796 - 796 - 1086 - 1086 - 1086)
02-22-06 07:50
edited on: 02-22-06 08:08

Ha, you've found the smoking gun. (A bug that shows why doubleclick logic must be changed.)

Try this.
>Right click on the background and bring up the halos.
>Left or middle click to cancel them.
>From then on, left click or middle click will not bring up a popup menu.
But now left press and drag. The menu appears!

Alternately press and hold the mouse down w/o moving it. The menu appears!

These facts place this bug at the doorstep of clickstate
and the interaction of focus and click state.

Other related mantis bugs are Mantis 0001037 and 0001567 the latter has a preliminary update the clickstate code. Which may point to a way to correct this problem.

(0003969 - 731 - 825 - 825 - 825 - 825 - 825)
02-22-06 09:07

Ah well. Maybe not a smoking gun after all.

Look at the pasteup morph mouseDown and mouseUp actions.

Apparently after halos are pressed mouseDown in world will set a delayed WorldMenu alarm.
Mouseup will cancel it.
So clicking will usually set and cancel the world menu because of the mouse up action.

Once the state is not affected by a recent world halo the mousedown will cause immediate popup of the world menu thus clicking will seem to work.

The mouseDown action was long and complicated an I haven't really looked closely at it yet. Its a good candidate for some rewriting though just based on its length and complexity.

"Old bugs never die. They just become specs."

Yours in service, -- Jerome Peace
(0003993 - 1484 - 1714 - 1714 - 1714 - 1714 - 1714)
02-23-06 07:07
edited on: 02-23-06 07:20

Hi acon

You got the problem right in one. But maybe not the reason for it.
Historical research (Good ole 39.a with all changes from 3.0 )
Shows that the bug was introduced when dgd mistook:

self hand halo: nil "Which causes the hand to forget its halo. i.e. shake it off."

to mean the same thing as:

self hand removehalo. "Which I believe deletes the handMorphs halo if it is showing one."

He had a tendency to "fix things where they weren't broken" for the sake of clarity. Here he got the messages wrong.

I've uploaded a cs that reverts That line of PasteupMorph's mouseDown: to do the proper thing with the hand.

Your code will fix the problem but it may cause others. The hand in not the proper thing to send removeHalos to. Have you ever seen an hand with its own halos? I believe undoing dgd's change is the correct fix in this case.

>Why is the opening of the world menu delayed if the world has a morph?
That is a good question. I'm not sure why this is being done yet. It would make sense if you delayed a menu on mouse down so that mouse up would not activate a random menu item. I don't know if that meets the circumstances here. There have been five different authors mucking in this particular method. Someone may have been trying to preserve a piece of logic they didn't fully understand.



This changes just the line I've mentioned here. It works a charm for fixing the symptom.

(0004084 - 1904 - 2227 - 2227 - 2410 - 2410 - 2410)
02-25-06 08:06

From the preamble:

'From Squeak3.9alpha of 4 July 2005 [latest update: 0007002] on 25 February 2006 at 12:45:27 am'!
"Change Set: WorldMenuPopupFix-wiz
Date: 25 February 2006
Author: (wiz) Jerome Peace
Mantis bug 0002496 can't open world menu after halo's.

dgd was trying to allow easy selection on mouse down in a world morph. In restructuring the logic in PasteupMorph>>mouseDown: he 'cleaned up' the code for shaking of the mouse halo mistaking shaking with removing the halo. This left the halo deleted but unshaken which caused the boolean hand had haloes to get stuck and the menu not to appear when the mouse was clicked a second time.

That fixed I had a closer look at the logic and decided a redo was in order. So first I reverted to the previous version (You have to find it in 3.9a with all changes from 3.0) Then I added much gentler logic to achieve the easy selection. Along the way I separated out the predicate for easy selection so that it can easily be maintained w/o any more harm to the poor overworked mouseDown method.

I also restricted easy selection to world morphs. I remember it made a mess when used in a holder. And anyway the forced selection is still availible (shift drag).

It may be desirable in the future to extend easy selection to playfields. If so please amend the predicate and leave the mouseDown intact.

Yours in service --Jerome Peace

This supercedes the other fix I uploaded. I think it does a pretty good job of making the behavior work as intended rather than as written. And it will be a heck of a lot easier to adjust.

P.S. The reason for the delayed invocation of mouse up

clicking on the world removes the halos (from what ever morph they are on) and does nothing else.

mousedown hold on the world removes halos and brings up the menu.

As does clicking on the world when there are no halos present.
(0004096 - 129 - 129 - 129 - 129 - 129 - 129)
02-25-06 19:15

I have just stepped on this bug too. Maybe it helps to know that the bug is not present in 3.6 and 3.7 but we can find it in 3.8.
(0004471 - 4 - 4 - 4 - 4 - 4 - 4)
03-14-06 16:11


- Issue History
Date Modified Username Field Change
01-16-06 04:54 aking New Issue
01-16-06 04:56 aking Issue Monitored: aking
01-20-06 01:04 acon File Added:
01-20-06 01:07 acon Note Added: 0003572
02-22-06 07:50 wiz Note Added: 0003968
02-22-06 08:08 wiz Note Edited: 0003968
02-22-06 09:07 wiz Note Added: 0003969
02-23-06 07:07 wiz Note Added: 0003993
02-23-06 07:09 wiz File Added:
02-23-06 07:20 wiz Note Edited: 0003993
02-25-06 07:56 wiz File Added: WorldMenuPopupFix-wiz.1.cs
02-25-06 08:06 wiz Note Added: 0004084
02-25-06 19:15 cdan Note Added: 0004096
02-26-06 22:30 cdan Issue Monitored: cdan
03-14-06 16:11 MarcusDenker Status new => closed
03-14-06 16:11 MarcusDenker Note Added: 0004471
03-14-06 16:11 MarcusDenker Resolution open => fixed
03-14-06 16:11 MarcusDenker Fixed in Version  => 3.9
05-09-08 02:07 wiz Relationship added related to 0006975

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
86 total queries executed.
50 unique queries executed.
Powered by Mantis Bugtracker