Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-111916

Crash upon copy/paste on Mac in plugin situation

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P1: Critical
    • 6.5.1, 6.6.0
    • 6.3.2, 6.5
    • QPA
    • None
    • macOS
    • 3bedeb837 (dev), 477f4bb60 (6.5)

    Description

      We do have a crash issue with Qt in our app, if our app is used as a plugin in some hosts on Mac. We also believe the issue might affect standalone, if Qt and non-Qt UI is mixed.

      The root cause seems to be that respondsToSelector in https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/cocoa/qnsview_menus.mm#n61 more or less unconditionally claims that it supports cut/copy/paste/selectall selectors, however in forwardInvocation https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/cocoa/qnsview_menus.mm#n86 there is an additional check by casting to QCocoaNSMenuItem. This check fails for cut/copy/paste/selectall sent from the host, therefore the method forwards further to the super in line 97. However, as super doesn't support the cut/copy/paste/selectall selectors, this results in an exception.

      In a number of cases this exception wouldn't cause exactly a crash. Often the exception would be intercepted by the Mac OS, however generally the program state seems broken after this exception is thrown. The crash is one potential outcome of this exception. We are not sure, whether we can simply catch this  exception to prevent this program state inconsistency, or whether this is possible at all.

      We currently believe that there is an issue in Qt, as described above. Instead of claiming that the selector will be handled and then not handling it, the handling conditions must match between respondsToSelector and forwardInvocation. We currently have a local fix in Qt where we introduce a global runtime configuration flag for Qt, which simply forwards the calls to the super, effectively enforcing respondsToSelector returning "false", which covers our short-term needs, but we also believe this doesn't work as a proper solution.

      Ideally, we would expect to be able to receive the cut/copy/paste/selectall requests (and possibly other standard MacOS selectors, we're not sure yet) inside QWindow as well as QQuickItems, where the focused QQuickItem would receive the notifications related to the respective selectors and can decide to react to them or not react to them (in which case they are propagated further during the responder chain, as usual in Mac OS).

      FYI vestbo 

      Attachments

        Activity

          People

            vestbo Tor Arne Vestbø
            aqn Vadim Zavalishin
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: