Thanks, Stefan!!! I'll give it a shot once I can get a little free time.
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!
"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.
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.
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!
I agree in that I no longer see the context menu being selected in the Chrome plugin in version 5.0.61429.
also I can't use IE for testing since I'm using a secure gateway which is not supported with the IE engine :(
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...
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.
The above suggestion did not change anything. The issue is that the enter key does not work, no matter how slow you make it.
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.
No resolution as of now that I'm aware of. I can confirm it appears that key sequence tasks do not type inside the window that should be in focus and that something in the upper left-hand corner of the screen is selected. If I immediately select the window that should be in focus, key-sequence broadcasting executes as expected.
Has anyone found a fix for this? I am having the same problem. Even downgrading does not resolve the issue. So far, support has not offered a solution.
Hi Patrick,
I just tried to repro the issue but failed. It seems to work fine for me. Can you create a new web page connection in a new document from scratch and set it up so that it fails. Once you have done that, open a new support ticket with the document attached and your default settings by attaching the file %appdata%\code4ward\code4ward.RoyalTS.UserPreferences.config.
Thanks,
Stefan
I got the same error with version builds 61428, 61429, 61707. Now, I'm back at 61330 again.
But with this version I still have problems with VMware vSphere Center and Hypervisor web interfaces older than v6.7 in combination with key sequences of Royal TS build 61330 Chrome engine.
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