Hi,
I just spend an hour to repro the issue on my side and I'm still not seing the issue. What I did notice is some weird behavior when I use the HTML page, Patrick provided in this thread. I think some javascript may interfere and the key sequence is executed too fast. Can you try to increase the pause between keystrokes in the plugin settings to the max. (500 ms):
Let me know if this changes anything.
The above suggestion did not change anything. The issue is that the enter key does not work, no matter how slow you make it.
Thank you very much for the suggestion. I increased the keystroke pause interval to 500 for testing. Keystrokes did type much slower as expected during testing. Although this did not solve the issue at first, you brought up an excellent point. I added a {WAIT:500} at the beginning of the sequence, which appears to have resolved the issue in my newly created test web page connection (with Web Paged based on Internet Explorer). This does not resolve the issue with Chrome selected as the active plugin as Patrick Leber has pointed out in the forum.
Ultimately, I believe the Internet Explorer-based page did not finish loading, which prevented the default text field within the page from being selected before keystokes began typing. The core issue appears to be isolated to the Chrome plugin as the default text field is never selected after the page loads.
Hope that helps! Let me know if I can run any more tests for you.
It is so strange... I changed the timeout to 500 and it worked "better" for a short time...
"better" means it started typing in the form but somehow the password was always wrong... I've added some waits here and there for testing... but the typed password was always longer than it should be (it seemed that {TAB} in a password field was uses as a single character.
After a restart from royalts everything was like before... so no form input at all and a context menu on the top left corner...
also I can't use IE for testing since I'm using a secure gateway which is not supported with the IE engine :(
I agree in that I no longer see the context menu being selected in the Chrome plugin in version 5.0.61429.
Let me summarize what I'm reading here:
1. It seems that the issue is not always present. It seems random/sporadic. For some users it's not working at all, some users can make it work sometimes.
2. Older versions of the Chrome plugin does not seem to be affected by this issue.
3. There's no reliable repro steps for me to or a known trigger how to reliably force the issue on my side.
I think if I can get this reproduced on my machine, I can better investigate if there's a workaround or something.
I can try to make a beta release ready next week with the latest version of the chromium engine for you to test to see if this has already been addressed.
Also, one information would be interesting as well: when you see this issue, are there other connections open/active? Is this happening with all web sites or just specific ones?
To forward this to the vendor, we definitely need reliable repro steps in order to get them to have a close look what's going on.
So any information (trigger, pattern, repro steps) which helps me to reproduce the issue would be very helpful.
Thanks!
For me, it is not sporadic. Once I upgraded, a key sequence in Chrome could not use {ENTER}. I have even tried uninstalling and downgrading Royal TS, and that did not fix the issue. I don't know how to change the Chrome plugin version alone. It also appears that clicking buttons with auto fill is broken in the Chrome plugin. I have been talking with Patrik who is with Royal TS support, and he has reproduced the issue. It has also happened to my co-worker who uses Royal TS.
"when you see this issue, are there other connections open/active? "
Fails either way.
"Is this happening with all web sites or just specific ones?"
All websites using the Chrome plugin. IE Works fine.
I just did some more digging and suddenly I could repro the same issue! So I investigated and found a potential code snippet which could cause this issue. The focus handling of the web browser changed dramatically as I read on the vendor's forum, so maybe it's a weird race condition when the message pump is not quite ready when the key sequence kicks in.
Anyhow, I quickly compiled a version based on the 5.1 beta code base for you to try:
https://download.royalapplications.com/RoyalTS/RoyalTSInstaller_5.01.10613.0.msi
Please note, this release has not been fully tested and it may not be as stable as 5.0 right now. Please keep that in mind. It would just be interesting if my little fix worked.
Thanks!
Thanks, Stefan!!! I'll give it a shot once I can get a little free time.
I have installed and tested the beta, and that appears to correct the issue.
Tried the new version, it works better but its not like it was before
Something changed with the {TAB} Placeholder
{WAIT:2500}{TAB}$EffectiveUsername${WAIT:500}{TAB}{WAIT:500}$EffectivePassword${WAIT:500}{TAB}{WAIT:500}{WAIT:500}{TAB}{WAIT:500}{ENTER}
The username gets entered correctly but after the tab one character gets entered in the password field before the actual password, hard to explain.
Its like this:
*Key sequence starts with a wait*
*Tab to focus Username Field*
*Username gets entered correctly*
*short wait*
*tab to focus password field*
*one character gets entered in the password field ???*
*short wait*
*password gets entered in the password field (but is now wrong because of the one character)*
*tab two times to the submit button ends on the username field... so this is also wrong*
// Was on break while writing this message, after the break royal ts was unstable (could be because of the beta) so I restarted the app and now its like before... nothing gets entered and the context menu pops up in the top left corner again...
Hi Patrick,
the initial wait is quite short. Can you try to increase the first wait time? Maybe it's related to a specific web page? Do you see the same issue on other pages?
Anyone else has feedback on the beta release? For Artur it seems the issue has been resolved, correct?
I've increased the wait but it did not change anything.
But I noticed something.
If a key sequence starts there is a notification in the bottom left corner.
So I can see that the key sequence is already starting while the page shows up as loading on the bottom of royal ts.
Since I'm using a secure gateway the page takes some time to load.
I think the key sequence starts to soon and without focus on the chrome tab... the initial wait does not change the start of the key sequence itself
Patrick Leber
Hi,
since Update 5.0.61428 Key Sequences are not working anymore on Web Page Connections (Chrome)
I think the web page does not get the focus since the key sequence will run outside of the web page and is changing stuff in the royal ts interface
3 people have this problem