b5b2640a65
QHeaderView sorting may be triggered when the user performs some mouse interactions that should really not result in sorting. Generally speaking, this happens when the user: * presses on a non-movable section (A) * moves on another section (B) * releases on that section resulting in B becoming sorted / flipping sorting. (Non-movable is required, otherwise dragging would cause section moving, not sorting.) To make the matter worse, QHeaderView doesn't check that the release happens within its geometry. This makes sense when moving sections: one is able to drag a section horizontally/vertically even if the mouse leaves the QHeaderView. But when not moving sections, this means that one can * press on section (A), * move the mouse anywhere vertically (for a horizontal bar, mut.mut for a vertical) above or below another section (B), that is, outside QHeaderView's geometry * release the mouse and cause B to be sorted. Fix it by 1) remembering which one was the section that the user originally clicked on; that's the only one that can possibly become sorted (if we're not moving and other conditions hold). No other variable seemed to remember this. 2) on release, check that it happens within that section's geometry. If so, sort. Pick-to: 6.0 5.15 Change-Id: Icfb67662221efbde019711f933781ee1e7d9ac43 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> |
||
|---|---|---|
| .. | ||
| auto | ||
| baselineserver | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| .prev_CMakeLists.txt | ||
| CMakeLists.txt | ||
| README | ||
| tests.pro | ||
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.