I saw this in my application and thought what have I done, how am I going to reproduce this and show it? It must be my binding or something…
I have two textboxes on a form
Well, in a brand new window without any binding and just two textboxes, if i repeat the above steps, the cursor goes back to the first textbox for a split second and then goes to the second …
I’ll keep investigating.
Confirmed fixed, Luca!
Thank you very much.
Sent it to you in a zip.
Can I have the fix to make sure this is the problem?
Because it depends on the sequence of events and if wisej has something to update on the textbox losing the focus. If the selection is set before the focus update then it’s fine, or if there is not selection change it’s also fine. To reproduce consistently I removed Wisej focus management in the test and let the browser handle it.
Another issue can be that now Wisej executed the actions after yielding to the browser to let it update the screen.
In any case, it’s very easy to fix.
Now if I say I understood, I’ll be lying…
The question is, can it be fixed? And why don’t I see it on all forms? And why couldn’t you reproduce it? Concerning browsers, it shows up in Chrome, IE, Edge, Firefox. In Opera the result is much worse, since the focus is completely lost and after a few tab clicks it focuses on a hidden control showing its border… Is it an effect of the latest build/latest qooxdoo?
It’s the selection range. Wisej is also able to manage the selectedText, start, length in the text fields. But apparently some browsers change the focus, some don’t, chrome was undecided, and it has been an issue for a while. So qooxdoo normalized it to always set the focus when setting the selected text. When wisej updates the controls on the client it may update the selection too and it will cause the focus to jump back.
You can enable console logging on the client using “debug”:true. In VS you can see the traces from Wisej in view->output. I don’t think it will help by looking at the logs. A lot of stuff happens simultaneously. But I think you are right, it’s related to firing back the events. I will try that. I have an idea of what it may be.
This won’t be easy…
Well, it has to do certainly (big word!) with the text change event. I can see it also when tabbing between the textboxes, not only when mouse-clicking.
The reason I suspect the text change is that if I press a letter in the textbox and tab to the next textbox, the cursor comes back, and if I tab again, the focus moves to the next textbox. If however, after the first return to the first textbox, I type another letter and tab, the cursor returns to the first control, i.e., whenever there is a change, it returns, if there is no change it proceeds…
I have removed my textbox validation events (which fired on text change) but the behaviour is the same. I have seen it a couple of times (but not always) disappear, if I do not run in debug mode. I also played with both values of the “optimizeFrames” flag, true and false, but didn’t see a difference.
Hi Alex, I can’t reproduce. Will keep trying. I have seen something similar in the past and it was caused by a mismatch between the focused control on the client and the server.