GeopJr
[Bug]: I can open many dialogs many times
Describe the bug
There is a short time window before the modal dialog appears where you can still click the Reply button, so if you double-click it you end up with two modal dialogs one on top of the other.
Similarly, if I spam Ctrl+, I can generate as many Preferences dialog as I want, and with F1 I can create as many About dialogs as I want. I suspect the problem happens pretty much everywhere in the app.
I think Tuba should better track its state, especially regarding opened dialogs. The simple way to do this is to store that dialog's object in a field of the object that creates it, to ignore any subsequent creation requests if there already is a dialog, and to clear that field when the dialog is destroyed. That way you can only have a single instance of each dialog.
Steps To Reproduce
-
Double-click Reply on a message
-
Press F1 several times
-
Press Ctrl+, several times
Logs and/or Screenshots
Capture vidéo du 2024-07-03 10-06-17.webm
Instance Backend
Mastodon
Operating System
Fedora Linux 40.20240702.0 (Silverblue)
Package
Flatpak
Troubleshooting information
os: GNOME 46 (Flatpak runtime) prefix: /app flatpak: true version: 0.8.1 (production) gtk: 4.14.4 (4.14.4) libadwaita: 1.5.1 (1.5.1) libsoup: 3.4.4 (3.4.4) libgtksourceview: 5.12.0 (5.12.0)
Additional Context
No response
They are all the aftermath of moving to AdwDialogs from modals. Modals, being different windows, you also get the 'shortcut focus' so the app's shortcuts wouldnt work on them/while they are visible/while they are focused (im bad at explaining it, the gist is that the shortcuts dont work when theres a modal). But the new Dialogs are shown in the main window itself.
Not sure if that's something that should be dealt on libadwaita's side (I don't have the time to track it down rn), but it's common across all AdwDialog apps
Screencast from 2024-07-03 11-17-09.webm
The reply one, I can easily deal from our side I guess, but the others should probably be dealt across all apps. A quick fix from apps' side would be checking if Adw.Window#get_dialogs is empty
Ah indeed, thanks for the explanation, I didn't think about this: AdwDialog looks so much like a modal window that I forgot it's not an actual window. 🤦 Then indeed it's a libadwaita issue, it should block clicks and actions on the """parent""" window when an AdwDialog is presented.