diff options
author | Carlos Manuel Duclos Vergara <carlos.duclos@nokia.com> | 2010-03-03 10:06:17 (GMT) |
---|---|---|
committer | Carlos Manuel Duclos Vergara <carlos.duclos@nokia.com> | 2010-03-03 10:11:49 (GMT) |
commit | 9b50db437abb5766751d00e5c51fadd0bc79b6d4 (patch) | |
tree | 26242c47c3a22b87b2251c7319edc0c53cace35c /src/corelib | |
parent | d521453b6f77d59864638a80e7bacfad8664380a (diff) | |
download | Qt-9b50db437abb5766751d00e5c51fadd0bc79b6d4.zip Qt-9b50db437abb5766751d00e5c51fadd0bc79b6d4.tar.gz Qt-9b50db437abb5766751d00e5c51fadd0bc79b6d4.tar.bz2 |
Bug with toolbar focus on Mac
Before doing anything we need to make sure that we don't leave anything
in a non-consistent state. When hiding a widget we need to make sure that
no mouse_down events are active, because the mouse_up event will never be
received by a hidden widget or one of its descendants. The solution is
simple, before going through with this we check if there are any
mouse_down events in progress, if so we check if it is related to this
widget or not. If so, we just reset the mouse_down and then we continue.
In X11 and Windows we send a mouse_release event, however we don't do that
here because we were already ignoring that from before. I.e. Carbon did
not send the mouse release event, so we will not send the mouse release
event. There are two ways to interpret this:
1. If we don't send the mouse release event, the widget might get into an
inconsistent state, i.e. it might be waiting for a release event that
will never arrive.
2. If we send the mouse release event, then the widget might decide to
trigger an action that is not supposed to trigger because it is not visible.
Task-number: QTBUG-8604
Reviewed-by: denis
Diffstat (limited to 'src/corelib')
0 files changed, 0 insertions, 0 deletions