Buttons become erratically activated; odd selection with grouping containers

[berryma4]

@kasemir @shroffk @jbobnar
If you move your mouse in the purple rectangle up and down on the right side, you will see the action buttons become selected, and can be click.

[berryma4]

file:
https://drive.google.com/open?id=0B_ikNAN_jxjPaU82RmxmV2NaUkU

[berryma4]

I do not see this in 4.1.x, but I do in 4.2.x and 4.3.x.

[kasemir]

We've had a case of buttons that got mysteriously clicked.

Clicking into a Text Entry field would cause a totally different Button to be clicked.
By changing that button style from Custom (draw2D) to Native (SWT button) the problem went away.

We would not figure out why just that one Text Entry field cause that one Button to get activated.
Copied/pasted the Text Entry -> copy would not have the same effect.
Moved the widgets around -> No change.

[kasemir]

Luca reported a "PV set by clicking unrelated widgets" issue in email:
"The problem is that if I click on some of the Text Update widgets the Boolean Button on top-left part of the GUI switches its status."

[kasemir]

Eric, your example display shows the exact problem we had.
For some weird reason, the 'Custom' buttons get the focus while the mouse is in a totally different section of the display, and a click will then activate their action.
Changing the button to 'Native' fixes it.

[kasemir]

The groups may be a clue: For Widgets inside a group, their X/Y coordinate is relative to the Group. Draw2D-based widgets seem to confuse the mouse position relative to a group with absolute mouse position within the display.

[kasemir]

Eric, any recollection how you got the issue?
When I un-group the buttons, the problem is gone.
When I then re-group the buttons, the problem is still gone.
So how to create a display that exhibits the issue in the first place?

[kasemir]

The 'Classic' buttons are based on org.csstudio.swt.widgets.figures.ActionButtonFigure.
In there, I can instrument the mouseEntered() method:

      public void mouseEntered(MouseEvent me) {
            System.out.println("Mouse entered @ " + me.x + ", " + me.y);

When I now move the mouse over the real button in the issue.opi, I see X coordinates around 30 .. 100.
The same mouseEntered, however, is also triggered when moving over certain areas of the purple group, where the printout shows X coords around 390..460.

Looks like a bug in Draw2D.

I can hack around it in the mouseReleased() method:

     public void mouseReleased(MouseEvent me) {
            if (me.button != 1)
                return;
            if (! containsPoint(me.getLocation()))
            {
                System.out.println("Bogus click");
                return;
            }

--> Now the bogus clicks are ignored.

[kasemir]

This commit works around the issue.
The button will still falsely appear selected, but the click is ignore unless the mouse is really in the button.
Unclear if there's a better way that would fix the underlying mouse coordinate confusion.