Details
-
Bug
-
Resolution: Incomplete
-
Not Evaluated
-
None
-
4.8.4
-
None
-
Windows, Linux
Description
Qt instantiates and dispatches secondary events while processing events from the system event queue in many places.
For example, src/gui/kernel/qapplication_x11.cpp; line number ~= 4520 has the following code:
QApplicationPrivate::sendMouseEvent(widget, &e, alienWidget, this, &qt_button_down,
qt_last_mouse_receiver);
if (type == QEvent::MouseButtonPress
&& button == Qt::RightButton
&& (openPopupCount == oldOpenPopupCount))
Notice that QCotextMenuEvent was manufactured and delivered regardless if the original MouseButtonPress event was filtered. It appears that the "if" condition should have evaluated the result of the sendMouseEvent() call that precedes it.
This issue occurs in numerous places through out Qt for different OS configurations. For example, the same patter can be found in src\gui\kernel\qapplication.cpp; line nubmer ~= 4129 where Qt fabricates a HoverMove event while processing a MouseMove event without consideration for whether the MouseMove was filtered.
Also, Qt fabricates Leave, HoverLeave, Enter, and HoverEnter events when processing a MouseButtonRelease event, again without regard for whether the MouseButtonRelease was filtered. See, src\gui\kernel\qapplication.cpp; line nubmer ~= 3151 and 3185