it is too easy to activate context menu item if mouse moves during right-click

Please see the following video:
https://youtu.be/5U9XQgf3NXI

When using Qt applications, it is very easy to accidentally activate a context menu item if the mouse cursor is not perfectly steady during the right mouse click that brings up the menu. This is worse with some widget themes (Breeze, Plastik) than others (Oxygen). As you can see in the video, in some cases the cursor only needs to travel 2 pixels between mouse press and release to activate the menu item.

Steps to reproduce:
1. Using Plasma 5 Desktop, open Dolphin and move it to the bottom right-hand corner of the screen.
2. Right-click (and keep the mouse button down) in the white space near the bottom right-hand corner of Dolphin. The context menu should open just above the mouse cursor.
3. Move the mouse up 2 pixels and release the mouse button.

Result: The bottom entry of the context menu is activated. The problem is that this all too often happens very quickly if my mouse is not steady, or my trackpad's accuracy sucks (which it does). For example, I can't tell you how many times I've accidentally disabled a clip in this manner when editing videos in Kdenlive.

Some possible solutions include:
1. If a right mouse click is short (very little time between mouse press and release), a context menu item shouldn't be activated on mouse button release. This is how GTK apps seem to handle this, and is probably the preferred solution.
2. Set a minimum number of pixels the mouse cursor must move between launching the menu (mouse right button press) and activating the menu item (mouse right button release).
3. Add a few pixels of padding region around the context menu where the cursor can exist without a menu item being selected. This solution already exists in the Oxygen widget style, as seen at the end of the video.
4. Have the context menu appear a few pixels away from the mouse cursor instead of right at the tip of the pointer. This solution would function similar to solution #3, but without causing potential changes to the appearance of the widget style.

Somebody else reported this bug a while back (bug #6632), but it was marked as invalid for some reason. This is definitely a valid usability bug, as you can see from my video. I had originally reported this bug on the KDE bug tracker (https://bugs.kde.org/show_bug.cgi?id=374311), but Christoph Feck informed me that the bug lies within Qt. Please let me know if you need any more information.

Here is a minimal example that can be used to reproduce the issue:

#include <QtWidgets>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QMainWindow mainWindow;

    QWidget *centralWidget = new QWidget;

    QMenu *menu = new QMenu(centralWidget);
    auto action1 = menu->addAction("Test 1");
    QObject::connect(action1, &QAction::triggered, [](){ qDebug() << "clicked"; });

    menu->addAction("Test 2");
    menu->addAction("Test 3");

    QObject::connect(centralWidget, &QWidget::customContextMenuRequested, [=](const QPoint &pos){
        menu->exec(centralWidget->mapToGlobal(pos));
    });

    centralWidget->setContextMenuPolicy(Qt::CustomContextMenu);

    mainWindow.setCentralWidget(centralWidget);

    mainWindow.resize(600, 600);
    mainWindow.show();

    return app.exec();
}