Prevent oversized QToolButton menu from moving to primary screen

The QMenu pop-up used with a QToolButton could unexpectedly move to the
primary screen if it was too big to fit on the owning widget's screen.

The cause of the issue is that QMenu is a top-level window, and can not
infer its screen from any parents. Its positioning is therefore done
using heuristics in QToolButton. These heuristics attempt to calculate a
best guess point relative to the screen that contains the QToolButton.
If these heuristics result in a point that is outside all screens, the
QMenu's own screen takes precedence, and this is always the primary
screen. This way, the QMenu ends up at the calculated position, but
relative to the wrong screen.

This patch works around this issue by ensuring that the first estimate
for the pop-up position is always within the same screen as the
QToolButton. The danger with this workaround is that the menu may end up
in an inconvenient location. This does, however, seem to be handled by
subsequent adjustments in QMenuPrivate::popup.

Fixes: QTBUG-118695
Pick-to: 6.5
Change-Id: Ibb4a1c82e827c57bbb0798a6c6f5eecb6d639c62
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 70404a2773293e4f3a763aa2f057f1d6569e8661)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

src/widgets/widgets/qtoolbutton.cpp

@@ -722,8 +722,13 @@ static QPoint positionMenu(const QToolButton *q, bool horizontal,
             }
         }
     }
+
+    // QTBUG-118695 Force point inside the current screen. If the returned point
+    // is not found inside any screen, QMenu's positioning logic kicks in without
+    // taking the QToolButton's screen into account. This can cause the menu to
+    // end up on primary monitor, even if the QToolButton is on a non-primary monitor.
     p.rx() = qMax(screen.left(), qMin(p.x(), screen.right() - sh.width()));
-    p.ry() += 1;
+    p.ry() = qMax(screen.top(), qMin(p.y() + 1, screen.bottom()));
     return p;
 }