Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.4.0 Beta
-
None
-
OS X
-
ea8d4869b722f0eca2b7bbbdd77ac7e3a13ccd10
Description
In qtbase/examples/opengl/legacy/hellogl it can be reproduced like this:
void GLWidget::mousePressEvent(QMouseEvent *event) { lastPos = event->pos(); if (event->button() == Qt::RightButton) { QMenu m(this); m.addAction("test item"); m.exec(event->globalPos()); } }
You will get a warning like
void QWindow::setTransientParent(QWindow *) QWidgetWindow(0x118c39a10, name = "QWidgetClassWindow") must be a top level window
with a stack trace something like this
0 QWindow::setTransientParent(QWindow*) qwindow.cpp 1131 0x10969ac1a 1 QWidgetPrivate::setParent_sys(QWidget*, QFlags<Qt::WindowType>) qwidget.cpp 10516 0x10898b528 2 QWidget::setParent(QWidget*, QFlags<Qt::WindowType>) qwidget.cpp 10375 0x108971b07 3 QWidgetPrivate::init(QWidget*, QFlags<Qt::WindowType>) qwidget.cpp 1179 0x10896fe3c 4 QWidget qwidget.cpp 1026 0x1089701a9 5 QMenu qmenu.cpp 1333 0x108b3468f
I see a couple of problems:
1) if a widget tries to set its transient parent to a non-top-level window, why don't we go up the hierarchy to find the top-level one? (The reason that it's not top-level is that QGLWidget renders into a window which is an inner child of the parent widget's window.)
2) why is QMenu doing that? It has to control its own absolute position anyway, so the transient relationship is probably irrelevant.
Attachments
Issue Links
- resulted from
-
QTBUG-40195 [REG 4->5] Windows: Having winId inited for widgets creates very weird dialog positioning policy
- Closed
For Gerrit Dashboard: QTBUG-42464 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
99140,6 | a widget's window is transient for its parent's top-level window | 5.4 | qt/qtbase | Status: MERGED | +2 | 0 |