Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.15.2
-
macBook Pro, Catalina 10.15.7, Magic Mouse, trackpad
-
macOS
Description
A customer is receiving rare cases where when QNSView mouse scrollWheel method is invoked with it's event phase set to NSEventPhaseEnded, and a look through the event queue finds another scroll wheel event with momentumPhase set to NSEventPhaseBegan, but where the assumption is broken in this case - that momentum scroll wheel event contains nonzero pixelDelta or nonzero angleDelta.
It doesn't seem to matter which scroll area is scrolled - it has been reproduced in 2-3 entirely different areas of the application. As this is so rare, it has not been reproduced in a simple Qt example (it seems to only occur on the order of once a month a so of active use of the Qt 5.15.2-based application)
The assertion happens at src/plugins/platforms/cocoa/qnsview_mouse.mm:654.
As this is a Q_ASSERT, it only occurs when the application is compiled debug, so end customers are not affected, however, the customer was wondering why this was a fatal error (causing the application to stop), rather than just logged.
The customer has a macBook Pro and a Magic Mouse, and uses both. He's not clear if the reproduction occurs with one or the other of those input devices. He also uses something called MagicPrefs which I see has not been maintained for some years, and uses deprecated and reverse-engineered private Apple APIs - I wonder if it may be affecting this.
Here is a backtrace showing this assert in Qt 5.15.2:
ASSERT: "pixelDelta.isNull() && angleDelta.isNull()" in file /local/S/workspace/qt_maya/src/qtbase/src/plugins/platforms/cocoa/qnsview_mouse.mm, line 658 Stack trace: 4 libsystem_kernel.dylib 0x00007fff6b76833a __pthread_kill + 10 5 libsystem_c.dylib 0x00007fff6b6ef808 abort + 120 6 libQt5Core_debug.5.15.2.dylib 0x0000000127a1d0d8 qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 24 7 libQt5Core_debug.5.15.2.dylib 0x0000000127a1f52e QMessageLogger::fatal(char const*, ...) const + 446 8 libQt5Core_debug.5.15.2.dylib 0x0000000127a136f7 qt_assert(char const*, char const*, int) + 87 9 libqcocoa_debug.dylib 0x0000000176bec548 -[QNSView(Mouse) scrollWheel:] + 1336 10 AppKit 0x00007fff2e997d5d -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6512 11 AppKit 0x00007fff2e9961c9 -[NSWindow(NSEventRouting) sendEvent:] + 349 12 libqcocoa_debug.dylib 0x0000000176bfbe0c -[QNSPanel sendEvent:] + 764 13 AppKit 0x00007fff2e994d36 -[NSApplication(NSEvent) sendEvent:] + 2370 14 libqcocoa_debug.dylib 0x0000000176c0635c -[QNSApplication sendEvent:] + 76 15 AppKit 0x00007fff2eaf1f3b -[NSApplication _doModalLoop:peek:] + 388 16 AppKit 0x00007fff2ec8440c __33-[NSApplication runModalSession:]_block_invoke_2 + 69 17 AppKit 0x00007fff2ec843b4 __33-[NSApplication runModalSession:]_block_invoke + 78 18 AppKit 0x00007fff2eaf04c4 _NSTryRunModal + 100 19 AppKit 0x00007fff2ec842af -[NSApplication runModalSession:] + 128 20 libqcocoa_debug.dylib 0x0000000176bff83a QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 650 21 libQt5Core_debug.5.15.2.dylib 0x0000000127d3bdc7 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 119 22 libQt5Core_debug.5.15.2.dylib 0x0000000127d3bfee QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 526 23 libQt5Widgets_debug.5.15.2.dylib 0x00000001240833af QDialog::exec() + 367 24 libSharedUI.dylib 0x000000010c0345a8 (anonymous namespace)::MayaDialog(TargParser&, QFileDialog::FileMode, QString const&, QString const&, QString const&, QString&, QStringList&, QFlags<QFileDialog::Option>) + 3704 25 libSharedUI.dylib 0x000000010c032d2c TmayaFileDialogCmd::doCommand(TargList&) + 1932
This bug was introduced by feature linked with this issue: QTBUG-65160 : macOS: Teach QWheelEvent to handle a new ScrollMomentum phase