Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.11.2, 5.14.0
-
None
Description
Today, MouseArea proactively recalculates containsMouse when visible is toggled from false to true. This calculation incorrectly assigns true to containsMouse in the case where another MouseArea is layered on top and the mouse is over both mouseAreas. Consider the following code snippet which consists of two MouseAreas and a Timer.
Rectangle { color: mouseArea.containsMouse ? "green" : "red" MouseArea { id: mouseArea x: 0 y: 0 width: 100 height: 100 hoverEnabled: true visible: false } MouseArea { id: mouseArea2 x: 0 y: 0 width: 100 height: 100 hoverEnabled: true } Timer { interval: 1000 running: true onTriggered: { // At this point, mouseArea.containsMouse === true mouseArea.visible = true // At this point, mouseArea.containsMouse *stays* true mouseArea.x = 500 } } }
The MouseArea on the bottom is initially invisible, but gets toggled to visible after 1 second. This triggers the calculation for mouseArea.containsMouse and, if the mouse is over mouseArea and mouseArea2, mouseArea.containsMouse is set to true, changing the parent rectangle color from red to green. This would not have happened if both mouseAreas were visible from the start; only mouseArea2.containsMouse would have been true.
Now consider the fact that mouseArea2 also gets its x value changed. Because mouseArea2 is currently stealing mouse events from mouseArea, mouseArea fails to receive onExited() and containsMouse is left as true. This is why this bug can be particularly troublesome in practice.
Attachments
Issue Links
- relates to
-
QTBUG-36930 containsMouse property not updated correctly for overlapping mouse areas during dragging
-
- Open
-
-
QTBUG-42578 MouseArea containsMouse is not cleared if item moves out of mouse position
-
- Closed
-
-
QTBUG-42194 Provide a way to force re-evaluation of MouseArea's containsMouse property
-
- Closed
-