After upgrading to UE 4.11, we’ve found that UMG steals both left-mouse-button-up events and right-mouse-button-up events.
Previously, our player controller would receive the mouse-up events properly. But after upgrading, releasing the mouse button while the mouse is over any UMG widget effectively “steals” the event from the player controller.
Hello Mothership.Entertainment,
I have a few questions for you that will help narrow down what issue it is that you are experiencing.
Quick questions:
Here’s an example blueprint only project that exhibits the behavior. However, I know now what was causing the problem. It was an undocumented behavior change (or, at least, we can’t find the documented change!) between 4.10 and 4.11.
If you load and play this test project, pressing the right mouse button will make a UMG widget visible. Releasing the mouse button anywhere except when the cursor is over the widget will make the widget hidden again. If the cursor is over the widget, the OnMouseButtonUp event never reaches the level blueprint code that hides the widget.
In 4.9 or 4.10, we were having issues where releasing mouse buttons when the cursor was over HUD widgets ended up with the player controller not getting the Mouse Up event - so we overrode the OnMouseButtonUp function in blueprint and just returned Handled.
But now that isn’t the case - and overriding OnMouseButtonUp caused this issue. So we’ve fixed it in our project, but I thought replying would be good because this is new behavior in 4.11!
Hello Mothership.Entertainment,
Thank you for responding with the additional information. I am happy to hear that you have things working on your end. I will be converting your last comment to an answer. Thank you for your time and information.
Make it a great day
Hi Rudy – Re-opening this bug. We’re seeing an issue with an important scroll box in our game where it steals the mouse-up events when you’re over a scroll box. I don’t see a way to fix it, and we definitely will need to fix this to ship our game.
I’ve modified the previous example to clearly demonstrate BOTH issues.link text
Also, not sure if this is the same bug or not, but you can also cause the bug to occur when an app is windowed by clicking and dragging inside the window and then releasing outside the window. The app never gets the mouse-up event if you do this.
Hello Mothership.Entertainment,
After running a few tests on the project that was provided I was able to find that this appears to be working as intended. The scroll box is currently set to visible and the on mouse up is being returned as handled. I was able to get this to functions as expected by setting onMouseUp to return unhandled and setting the scroll box to Hit test invisible (be sure to set the scroll box to hit test invisible and not just the scroll bar). I hope that this information helps.
Make it a great day
Please take a look at this new project. We have changed the WidgetWithScrollBox widget to return Unhandled for the “On Mouse Button Up” and we’ve changed the ScrollBox to be Self Hit Test Invisible - just as you suggest.
The only difference is that we’ve actually added children to the scroll box - which is how the widget would be used in-game.
Now, press the right mouse button and drag it over one of the buttons that are inside the scroll box. The scroll box will steal focus and the mouse cursor in all situations except when the child widgets are also Self Hit Test Invisible. I find it hard to believe that this behavior is expected.
You can change the button child widgets to be anything - even Text Boxes - but so long as their visibility is Visible, the Scroll Box steals the cursor.
Also, please try the final bug - press the right mouse button and drag the cursor outside of the viewport and then release it. The mouse event is not generated - and that behavior has changed since 4.10.
To put a finer point on it: this makes it impossible for us to know the actual, correct mouse button state.
Our game is a strategy game, and the player can rotate the camera by holding down the right mouse button. If they happen to drag and then release the right mouse button while it’s over a scoll box – BOOM! The player is now stuck rotating the camera even though no mouse buttons are down, and there’s literally no way for us to detect that any more …
… because we’ve now been deprived of the “mouse up” event that the player controller used to receive under 4.10, and there’s no way for us to check the mouse button states that doesn’t give us identical (invalid) results.
Hello Mothership.Entertainment,
After further testing I have written up a report (UE-29436) and I have submitted it to the developers for further consideration. I will provide updates with pertinent information as it becomes available. Thank you for your time and information.
Make it a great day.