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
Mumble spams username dialogs when using the 'autoconnect on startup' option #3191
Comments
Please explain what you're trying to do, and how. The title of this issue has nothing to do with autoconntect or username text boxes. It seems like you're saying Mumble is endlessly popping up dialog boxes that ask for your username. Is that correct? |
@mkrautz Yes that is correct. Upon launching mumble, that is what occurs. I've found a workaround which is basically just to hold Otherwise, if I let it continue, it eventually freezes the desktop environment. I'm using the latest snapshot provided by the Ubuntu PPA. |
So... What feature are you using for auto-connecting? Do you click on a URL? |
@mkrautz GUI-based 'Reconnect to last server on startup' which technically works but it is odd that it always asks me for my username. It's supposed to remember that right? |
After entering your username and clicking ok, does it successfully connect? |
@Kissaki Did you try to reproduce? I think it might have been broken by the new ServerHandler/ServerResolver changes... |
No, did not try. |
@Kissaki The username is pre-filled correctly (so it's remembering) but it isn't remembering that it should automatically bypass this screen altogether as I've already selected my username in the past and set up auto-reconnect, etc. And technically I can't click ok in the normal sense. I have to hold I only noticed it was no longer working smoothly a month or so ago but for a long time prior, it was working smoothly. To clarify, I'm pretty sure it always preselected my last username rather than making the assumption that I wanted to juts autoconnect with that username. So in that sense, autoconnect was never working but at that point I was able to click OK in a smooth manner. |
OK, I've managed to reproduce this. It happens when a server doesn't have a username associated with it in the database... But: we don't allow you to store a server without a username. What kind of server are you connecting to? Is it one you've added yourself as a favourite? The way I managed to reproduce this was to add a new favourite server, and then manually go in the DB and set its username to an empty string:
This is a bug, but I'm wondering how come you have a server without a username associated with it in your DB when the UI doesn't allow that? Maybe we allowed it in previous versions of Mumble? |
OK, so it is related to the new resolver infrastructure. |
…problem. This ensures that we apply all globally visible state from the lookedUp() method before we attempt to auto-connect. The previous block of code would, when auto-connect is enabled, call accept() to perform the auto-connect. In case the selected ServerItem has no username set, accept() will trigger a dialog box to appear asking the user to input their desired username. Unfortunately, showing this dialog causes Mumble to enter the event loop before the lookedUp() method anticipated it to be entered. The point at which the auto-connect happens, is before the lookedUp() method has had time to update the global state of the ConnectDialog to reflect the successful host lookup. In practice, this meant that the auto-connect would be triggered many, many times in a row. In this scenario, Mumble would open a new username dialog box for each auto-connect attempt. This would cause Mumble to become unresponsive, because Mumble would spawn infinitely many username dialog boxes. The code of the lookedUp() method was re-arranged in 4d6e28e, which introduced this problem. Fixes mumble-voip#3191
Fix available at #3198 |
It's my own Ubuntu host server. I'm the admin. I imported the user cert from a backup. |
I see this in the terminal and mumble's autoconnect spams an absurd amount of username text boxes on top of one another at an unprecedented rate. Freezes the gnome interface usually if I can't kill it in time.
The text was updated successfully, but these errors were encountered: