iOS (while updating) feeds touch events to QUIWindow -> weirdness!

[SGaist]

Hi,

@barbicels said in iOS (while updating) feeds touch events to QUIWindow -> weirdness!:

5.12.2

Not a direct answer sorry but did you try to test your issue with a more recent version of Qt to see if you get into the same kind of issue ? I understand you might be locked to that version of Qt but this would allow to ensure it's something that is affecting other versions of the 5.12 series as well as maybe the 5.15 or even 6.

[barbicels]

@SGaist
Argh, that was a typo, now edited. It’s 5.15.2 (LTS), open source.

[SGaist]

@barbicels said in iOS (while updating) feeds touch events to QUIWindow -> weirdness!:

@SGaist
Argh, that was a typo, now edited. It’s 5.15.2 (LTS), open source.

Damn ! So it's one less hope of it working on a later version. Can you try with 6.2 ?

[barbicels]

@SGaist
I shall have to try that, but it seems profoundly weird that iOS would dispatch a touch event while spinning its own update cycle, and only on newer hardware (suggesting some sort of race condition). Hard to see how Qt could be responsible for that behaviour, or work around it in any way that doesn’t effectively preclude the use of a Qt event loop as part of the GUI response to the touch event.

[SGaist]

Agreed

By the way, since you can reliably reproduce that behaviour, I think you should consider opening a ticket on the Qt bug report system. Even if not directly Qt's problem, it will at least make it known and possibly pushed upstream as well.

[barbicels]

@SGaist
Will do.
Meantime, searching for updateCycleEntry turned up some other very recent reports that likewise suggest a pattern of odd behavior on recent iPhones and with similar tracebacks, where GUI events are dispatched while inside updateCycleEntry:
1
2
3

[barbicels]

@SGaist
Using an event filter and category logging rules, I was able to distinguish the success (simulator and older iPhones) and failure (newer iPhones) cases:
The failure case results from the application window receiving an UpdateRequest event after the user touches the QML Switch item and before the resulting TouchEnd event causes that item’s onSwitchChanged handler to execute; in the success case, that update event is processed after the touch event.
That would explain why the iOS run loop is in its update cycle at the time, which in turn explains why the code that runs in response to the touch event doesn’t receive more update events in its nested Qt run loop as would be required to paint the confirmation dialog opened in response to the switch change.
Knowing that Nested Event Loops Are Bad, I have thrown a Qt.callLater into the onSwitchChanged handler so that the handler returns to the main event loop before JS invokes any QObject methods that could create a nested event loop leading to “stacked” QML event handling. This appears to work, so I’ll make the same change in other places where such event-handler “stacking” could happen, and hope for the best.
Thank you for the help and encouragement.

[SGaist]

Thanks for the detailed analysis and workaround !

I still think it's worth opening a ticket to make the situation known.

[barbicels]

@SGaist
Some later observations:

• Porting to Qt 6.2.2 did not fix the problem. A modal dialog (using QtQuick.Dialogs 1.2 MessageDialog) still does not paint if the C++ method (invoked by the onSwitchChanged event handler), which signaled QML to post the dialog, then spins its own event loop (to maintain its synchronous semantics, waiting for the user's response to the dialog) rather than returning to the main thread's base event loop. So, I can forget about that as a possible avenue for resolution.
• The workaround I described (using Qt.callLater so that the onSwitchChanged event handler can return to the base event loop, deferring the posting of the modal dialog and all logic that depends on the user's response to it) works to a degree, but a run of two or three of those dialogs in sequence causes some further event-handling weirdness that I still have to work out.
• Apple's recent macOS 12.2 update did not make any difference. My problem remains, though it's still only happening on newer iPhone models. As I wrote, above, there are other unresolved reports of odd crashes whose traceback shows touch events being dispatched from inside iOS's update cycle, which still strikes me as something that shouldn't happen. Maybe I'll bounce this off my old acquaintance Quinn at Apple Developer Support…

Thanks again for your interest!

[SGaist]

Then I confirm that it is worth a report :-)