Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix crash on closing iOS chat dialog #3413

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ann0see
Copy link
Member

@ann0see ann0see commented Oct 14, 2024

Short description of changes

Using close() instead of hide() would crash the app as soon as one taps at the screen after closing the chat dialog. Due to a null pointer dereference (?).
I do not understand why the app crashes. Probably it's a qt bug.

ASSERT failure in QCoreApplication::sendEvent: "Unexpected null receiver", file /Users/qt/work/qt/qtbase/src/corelib/kernel/qcoreapplication.cpp, line 1587

Can't show file for stack frame : <DBGLLDBStackFrame: 0x7fcf61f51120> - stackNumber:3 - name:qAbort. The file path does not exist on the file system: /Users/qt/work/qt/qtbase/src/corelib/global/qglobal.cpp

https://qtcentre.org/threads/5572-QCoreApplication-postEvent-Unexpected-null-receiver (?)

CHANGELOG: iOS: Fix crash on Qt6 after closing the chat window.

Context: Fixes an issue?

Related to: #3406
Does this change need documentation? What needs to be documented and how?

Status of this Pull Request

Ready for review.

What is missing until this pull request can be merged?

Discussion. This is a hot fix...

Checklist

  • I've verified that this Pull Request follows the general code principles
  • I tested my code and it does what I want
  • My code follows the style guide
  • I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
  • I've filled all the content above

@ann0see ann0see added this to the Release 3.12.0 milestone Oct 14, 2024
@ann0see ann0see added the bug Something isn't working label Oct 14, 2024
@ann0see ann0see self-assigned this Oct 14, 2024
@@ -62,7 +62,7 @@ CChatDlg::CChatDlg ( QWidget* parent ) : CBaseDlg ( parent, Qt::Window ) // use
pMenu->addMenu ( pEditMenu );
#if defined( Q_OS_IOS )
QAction* action = pMenu->addAction ( tr ( "&Close" ) );
connect ( action, SIGNAL ( triggered() ), this, SLOT ( close() ) );
Copy link
Collaborator

@pljones pljones Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whilst we're doing this, I would like the two lines changed to match the addActions before and after that both include the action handler.

I'll also ask why this should be hide() for iOS and close() for Android -- I'm going to hazard a guess it should be the same request to Qt on both platforms and that Qt should do the right thing.

I'd even go as far as to suggest that having &Close on the menu bar in the app, regardless of platform, wouldn't necessarily be a bad thing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand hide() is close() minus deleting the dialog.
Somehow on iOS under Qt6 the dialog already gets deleted and close() may attempt to do it twice.

Potentially it's the same on android with Qt6 - but we don't know for sure yet.

Yes, we could add the close menu entry on all OS - on desktop it seems redundant however.

Copy link
Collaborator

@pljones pljones Oct 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd argue that UI consistency across platforms isn't "redundant" but makes for a more consistent user experience -- with the benefit of reducing code complexity and maintenance overhead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The close entry on desktop OS is redundant since there's a close button in the window manager.

It does not make sense to hide the close button in a menu on mobile OS (at least iOS, where there's no back button).

@ann0see
Copy link
Member Author

ann0see commented Oct 19, 2024

@softins I've pushed a new build with this + the icon PR on TestFlight.

@softins
Copy link
Member

softins commented Oct 24, 2024

Thanks for the updated Testflight. I've tried it out, and can confirm it doesn't crash, and the icon looks fine.

But I have found some oddities regarding the Chat window, which while fairly minor, would be worth investigating.

When opening the Chat window, it does not cover the main menu bar, but instead adds its own menu bar below it:

2024-10-24 11 37 42

Closing and re-opening it makes no difference.

This is in contrast to the Settings window, which replaces the main menu bar with its own, and the Connect window, which doesn't have a menu bar at all (it is exited with either Cancel or Connect).

Having connected to a server with a welcome message, the Chat window automatically displayed as usual, but still with the main menu bar showing:

2024-10-24 11 38 40

I closed it, disconnected and connected again to check, and it was the same.

I then tapped in the text box to type a message, and the on-screen keyboard appeared, correctly moving the window upwards. After typing the message and pressing Send, the keyboard disappeared again as normal, but now the Chat window was correctly showing without the main menu bar:

2024-10-24 11 40 52

The very first time I tried this Testflight, and also when I was trying the previous one, the Chat window showed with the message entry box and Send button half off the bottom of the screen. But I have failed to reproduce this behaviour since, so maybe it was a hangover from the older version?

@softins
Copy link
Member

softins commented Oct 24, 2024

Also, at one point after this, I tapped on Connect in the main window, and the Connect dialog showed at the wrong size:

2024-10-24 11 51 34

Tipping the iPad to rotate to portrait mode and back to landscape mode reset the dialog size to full screen correctly.

I'm not sure what I did to provoke that behaviour.

@ann0see
Copy link
Member Author

ann0see commented Oct 24, 2024

I did notice problems like this on the main mixer board too. All can be fixed by rotating the device.

I believe it's due to an overflow introduced by some widget (see the UI issues mentioned in #3406)

@ann0see
Copy link
Member Author

ann0see commented Oct 24, 2024

Maybe #3397
Could fix this. I'd like to investigate the UI issues separately.

@softins
Copy link
Member

softins commented Oct 24, 2024

Maybe #3397 Could fix this. I'd like to investigate the UI issues separately.

Fair enough. As this PR fixes the crash it's supposed to, I'm happy to approve and leave the UI for separate investigation.

@ann0see ann0see requested a review from gilgongo October 24, 2024 13:08
Using close() would crash due to a null pointer dereference
@ann0see
Copy link
Member Author

ann0see commented Nov 12, 2024

@gilgongo @pljones Not sure if you can test this, but I'd like this to be merged.

The TestFlight link is in the chat.

@pljones
Copy link
Collaborator

pljones commented Nov 13, 2024

I've no way to test it.

@@ -61,12 +61,11 @@ CChatDlg::CChatDlg ( QWidget* parent ) : CBaseDlg ( parent, Qt::Window ) // use

pMenu->addMenu ( pEditMenu );
#if defined( Q_OS_IOS )
QAction* action = pMenu->addAction ( tr ( "&Close" ) );
connect ( action, SIGNAL ( triggered() ), this, SLOT ( close() ) );
QAction* closeAction = pMenu->addAction ( tr ( "&Close" ) );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this added to the QMenuBar rather than the edit menu, like for Android? Have we checked if that's the source of the problem?

QMenuBar* pMenu = new QMenuBar ( this );

@gilgongo
Copy link
Member

I'm unable to test on iOS either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Triage
Development

Successfully merging this pull request may close these issues.

4 participants