Operating System (Linux/Mac/Windows/iOS/Android):
Windows 8.1 Pro.
Delta Chat Version:
1.4.2, 1.4.3, 1.10.0, and 1.12.0.
Expected behavior:
Fluent typing.
Actual behavior:
Typed characters are accepted at about one character per three seconds. ;)
Steps to reproduce the problem:
-- Install Delta Chat and type username and password.
Screenshots:
N/A.
Logs:
N/A.
Remarks:
-- The other fields (in section "Advanced") can be filled out fluently.
-- There is no such issue in version 1.3.4.
Is anything weird in the logs? Because in general we didn't change anything on the stuff that responses to username/password changes. What is currently happening, is that each time username changes, we check if we need to show some additional information from the provider db if the user needs to set up something specifically. We could debounce this and only do it every x ms. But it's weird that this seems to happen on the password too. Are you sure that you can reproduce it with the password?
EDIT: Ohh it looks like many components update if we change username/password. That could be the problem.
Is anything weird in the logs?
No, unfortunately not.
But it's weird that this seems to happen on the password too. Are you sure that you can reproduce it with the password?
Yes, it is reproducible on username and password. That could explain why settings in the "Advanced" section (like ports and securities) are not updated automatically after I enter my Posteo email address. I wanted to file a new issue for this, but I think I better wait for this fix first. ;)
That could explain why settings in the "Advanced" section (like ports and securities) are not updated automatically
AFAIK such thing is not implemented, the advanced settings are just an overwrite, leave the fields empty and the core fills them out internally.
For the original issue: on username type in we ask the local provider db what provider the user is using on every keystroke, that could case some lag on weak devices.
AFAIK such thing is not implemented, the advanced settings are just an overwrite, leave the fields empty and the core fills them out internally.
@Simon-Laux Thanks, I did not know that. If this is true, why do the default settings for IMAP and SMTP port not comply with those for Posteo from the provider database after I have entered my Posteo mail address?
on username type in we ask the local provider db what provider the user is using on every keystroke, that could case some lag on weak devices.
@Simon-Laux I would not call my Convertible PC (HP Elitebook Revolve 810 G2) with 8 GB RAM (39% free) a "weak device"... ;)
@gerryfrancis I believe we should discuss the posteo thing in a seperate issue.
@Simon-Laux I would not call my Convertible PC (HP Elitebook Revolve 810 G2) with 8 GB RAM (39% free) a "weak device"... ;)
I didn't knew what device you were using :wink:, but for me on my devices this bug is not very visible, so I assumed that your device must be weaker than mine.
I believe we should discuss the posteo thing in a seperate issue.
@Simon-Laux I have just created a new thread for it in the forum. ;)
for me on my devices this bug is not very visible, so I assumed that your device must be weaker than mine.
@Simon-Laux ... or you probably type too slow. ;) (Just kidding.) Maybe we should leave this open for a while so other users can report their experience on this.
Can reproduce this in a windows 10 vm :D
Can reproduce this in a windows 10 vm :D
@Jikstra Haha, another one with a slow machine! ;) (Just kidding.) Great, thanks for confirming!
Still an issue in version 1.10.0.
same here (Deltachat desktop V1.10.0 (Linux) ) lag while typing username and password.
and for the record i didn't have this problem in previous versions
with cpulimit I can reproduce this on the username/email field but not on the password field.
Update: I can now also reproduce the thing with the password field. (when lowering the cpu limit even further)
@Simon-Laux These lags seem to last for the time someone needs to fill in username and password. When finished, type response returns back to normal.
@gerryfrancis I'm begin to think these two bugs are related sound file stays in pending #1547 because this problem happens in low CPU(based on what @Simon-Laux says) and the pending problem has nothing to do with internet connection or email provider. maybe the problem is with using GPU
as you can see in the picture, CPU and RAM behaviour did not change while Deltachat was lagging

maybe the problem is with using GPU
@vbeh No, because the cursor still flashes when this occurs.
The problem is most likely that we are not debouncing the call to the backend to get the additional provider information.
https://github.com/deltachat/deltachat-desktop/blob/master/src/renderer/components/LoginForm.tsx#L119
This method is getting called every time we input a letter into the username field. Doing it 30ms after the last entered letter should be enough.
The provider info is not the only thing, I de-bounced it, but this doesn't explain everything as there are still lags in the password field that also occur inside the username field even after the provider info was de-bounced.
I suspect the handleCredentialsChange function is doing to much stuff, (and its also called on every character change that occurs inside the input field.
@Simon-Laux To my knowledge, version 1.3.4 was last one that did not have this issue. Maybe that helps.
Still an issue in version 1.12.0.
I can confirm that it works fine in version 1.13.0 RC1, thanks! :+1: