fix(contacts): Multiple friends contacts system dependent

[bodwok]

Looks like the issue related to graphics processing in Linux. On Fedora 35 it occurs if Wayland is used (setted by default). If switch to Xorg mode or run qTox with -platform xcb key on Fedora 35, then this error was not reproduced for me.
When using Wayland, if the ContentDialog closes, its destructor is not called immediately, but manages to initialize the currentDialog pointer in ContentDialogManager::onDialogActivate. Next the ContentDialog destructor is called, and currentDialog becomes a dangling pointer.

To get around this I added a flag that marks ContentDialog as invalid. Also another option that works for me too: use qtox -platform xcb.

Fix #6412

---

This change is 

[codecov-commenter]

Codecov Report

Merging #6621 (e510f91) into master (a300415) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

❗ Current head e510f91 differs from pull request most recent head 3dbaf68. Consider uploading reports for the commit 3dbaf68 to get more accurate results

@@            Coverage Diff             @@
##           master    #6621      +/-   ##
==========================================
- Coverage   11.75%   11.74%   -0.01%     
==========================================
  Files         303      303              
  Lines       20582    20589       +7     
==========================================
  Hits         2419     2419              
- Misses      18163    18170       +7     

Impacted Files	Coverage Δ
src/widget/contentdialog.cpp	0.00% <0.00%> (ø)
src/widget/contentdialogmanager.cpp	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a300415...3dbaf68. Read the comment docs.

[anthonybilinski]

Reviewable status: 0 of 1 LGTMs obtained

a discussion (no related file):
What's the root cause of the crash here?

It seems like on window close:

• ContentDialog::closeEvent emits willClose then accepts the event
• ContentDialogManager::addContentDialog connects ContentDialog::willClose to ContentDialogManager::onDialogClose
• ContentDialogManager::onDialogClose calls removeDialog
• contentdialogmanager.cpp's removeDialog, which deletes the ContentDialog

At some point(?) during this, the ContentDialog is destroyed by Qt due to setAttribute(Qt::WA_DeleteOnClose); in ContentDialog's constructor.

When the second dialog is being opened, Widget::openDialog calls Widget::addFriendDialog which calls into ContentDialogManager to get the content dialog for the friend.

So is there a race on destruction here, that the content dialog isn't being destroyed by the time Widget tries to get the current ContentDialog? If so I think we should address the race to make sure destruction is complete rather than create invalid objects that are semi-destructed.

Changing ContentDialogManager::addContentDialog to connect the willClose signal synchronously: connect(&dialog, &ContentDialog::willClose, this, &ContentDialogManager::onDialogClose, Qt::QueuedConnection); seems to stop the problem on Fedora 35 - so that may be an alternative.

---

[bodwok]

Reviewable status: 0 of 1 LGTMs obtained

a discussion (no related file):
Now I found that the difference between Xorg and Wayland (Fedora) in the return value of the isActiveWindow property:

• ContentDialog::closeEvent emits willClose then accepts the event
• ContentDialogManager::addContentDialog connects ContentDialog::willClose to ContentDialogManager::onDialogClose
• ContentDialogManager::onDialogClose calls removeDialog
• contentdialogmanager.cpp's removeDialog, which deletes the ContentDialog

If we continue your call list we will get (if using Wayland):

Without this PR:

1. ContentDialog::changeEvent (here isActiveWindow() == true and emit the activated signal)
2. ContentDialogManager::onDialogActivate (here the currentDialog pointer is set to the dialog that will be deleted)
3. ContentDialog::~ContentDialog

With this PR:

1. ContentDialog::changeEvent (here isActiveWindow() == false)
2. ContentDialog::~ContentDialog

The fix you suggested works and ContentDialogManager::onDialogActivate is not called before ContentDialog::~ContentDialog

---