Important: Please read the Qt Code of Conduct -

Why is the action from a context menu on a popup dialog not triggered?

  • We have a dialog that derives from QDialog with roughly the following implementation:

    MyDialog::MyDialog(QWidget* parent)
        : QDialog(parent, Qt::Popup)
        connect(ui.textMetadata, &QTextEdit::customContextMenuRequested,
           this, &MyDialog::ShowContextMenu);
    void MyDialog::copyAsTextToClipboard(bool )
        QApplication::clipboard()->setText(data); // where data comes from within our application
    void MyDialog::ShowContextMenu(const QPoint &pt)
        QMenu* menu = ui.textMetadata->createStandardContextMenu();
        QAction* copyAsText = menu->addAction("Copy as text");
        connect(copyAsText, &QAction::triggered, this, &MyDialog::CopyAsTextToClipboard);

    This code worked fine when I didn't construct the dialog with Qt::Popup - however, when passing this flag MyDialog::CopyAsTextToClipboard never gets executed when clicking the Copy as text action. As a matter of fact, the default Select All action that is created by default in the context menu, is also not executed.


  • Lifetime Qt Champion


    Sounds like it could be a bug.

    You should check the bug report system to see if there's something about that.

  • @SGaist Hm, that would be quite unfortunate - I'll check.

    In the meantime, I realized that there is an additional piece of information that may be quite relevant to this, which is how the dialog is constructed. Most of the widgets in our application are always there, including dialogs - they are just not always shown. This particular case is constructed as a result of the right click on an underlying widget:

    void GenericHandler::GetPropertiesClicked(QWidget* widget)
        MyDialog dialog(widget);

    The panel is used to display metadata (not the Qt-stuff, but metadata relevant to our application) that comes along with the image data that is displayed on right-clicking the display and selecting an 'Show properties' option in the context menu that is popped up.

    So the dialog is destructed as soon as 'exec()' returns. I was wondering if there is a possibility that this causes the signal to never arrive when the dialog is in popup mode.

  • Lifetime Qt Champion

    Very important detail indeed. Your dialog is modal to the widget you pass as parent thus it will block all inputs on it. See the WindowModality enum.

  • @SGaist Thanx for answering - I thought I understand this, but the signal I expected to be arriving in the dialog, hence not the underlying (blocked) widget, and then be picked up by the handler, which is also implemented in the dialog itself. As far as I can tell all 'action' is happening, and restricted to the dialog itself, and not to the underlying, blocked widget.

    Or am I misunderstanding something here? The funny thing, when the same dialog is created and displayed like this without the Qt::Popup flag, these triggered signals do arrive.

  • Lifetime Qt Champion

    My bad, I've mixed your widget setup with another one. You understood right.

    Do you experience the same if you make a dialog instance on the heap with the dialog->setAttribute(Qt::WA_DeleteOnClose); and call open on it rather than exec ?

  • @SGaist Unfortunately that doesn't improve things.

    In the meantime I attached a debugger, and put a breakpoint in the QAction::activate implementation, which seems to the function that should handle all triggered actions. I never hit this breakpoint when I click the 'Copy as text' menu item, nor when I click the default constructed 'Select all' menu item.

    It seems almost as if the connection is not made for some reason, or destroyed before it is handled.

  • @SGaist I did some more investigation inside the debugger.

    • the QMenu::mouseReleaseEvent() method is called
    • However, the d->currentAction is nullptr, and for that reason the handler never executes d->activeAction()

    [EDIT] Diving further, it seems in QMenuPrivate::setSyncAction() the currentAction is not set, while it is set when not passing the Qt::Popup flag.

  • Lifetime Qt Champion

    On which OS are you currently ?

  • @SGaist The OS is windows 7, with qt 5.6.0.

  • @SGaist I managed to create a compilable example that reproduces the problem. Hopefully that helps.

    When using the line commented with OKE the line that prints some text to qInfo() is executed - when using the other line, that function is never executed (because the action is never 'activated')

    #include <QAction>
    #include <QApplication>
    #include <QFrame>
    #include <QMenu>
    #include <QtDebug>
    #include <QTextEdit>
    #include <QVBoxLayout>
    #include <QWidget>
    #include <QWindow>
    class Popup : public QFrame
            : QFrame(nullptr) // OKE
            //: QFrame(nullptr, Qt::Popup) // NOT OKE
        void SetInitialText(const QString& t)
        void ShowContextMenu(const QPoint& pt)
            auto menu = txt->createStandardContextMenu();
            auto custom = menu->addAction("Formatted copy");
            connect(custom, &QAction::triggered, this, &Popup::CustomActionTriggered);
            delete menu;
        void CustomActionTriggered(bool)
            qInfo() << "Custom action triggered";
        void Setup()
            layout = new QVBoxLayout(this);
            txt = new QTextEdit(this);
            connect(txt, &QTextEdit::customContextMenuRequested,
                this, &Popup::ShowContextMenu);
        QVBoxLayout* layout;
        QTextEdit* txt;
    void CreatePopup()
        auto popup = new Popup();
        popup->SetInitialText("Some text to display");
    int main(int argc, char** argv)
        QApplication app(argc, argv);
        QWidget window;
        QAction* showDialog = new QAction("Show dialog", &window);
        QObject::connect(showDialog, &QAction::triggered, []{ CreatePopup(); });
        return app.exec();

  • I also created a bug report for this, as I'm getting more and more convinced it really is a bug, see

  • Lifetime Qt Champion

    Thanks !

  • @SGaist According to comments in the bug report the posted code should work in qt 5.6.1, and I have been able to verify this is indeed the case. So I guess I should consider this question as 'answered' then. Thanx for the help