Start a new topic

Chrome Key Sequence not working since update


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

I can confirm that the issue is still occurring with the latest v5 beta

1 person likes this

I've spent a couple of hours doing tests and research. While I still can't reliably reproduce what you are seeing, I sometimes get that the ENTER key is always not recognized from the key sequence task. I was able to workaround the issue using TABs to focus the log in button and then send a SPACE to hit the button.

During my research I also noticed a SO post here:

Selenium is used for web app testing and also allows to create test cases and send keyboard input. I'm more and more convinced that this is an issue deep down in Google's Chromium engine. I will do some more research. Maybe I find a workaround or a solution...

1 person likes this

Still not working... here are some Steps to reproduce:

I've attached an example page to try. (copy of the vmware vCenter login page)

Autofill does not work for this page so I've created a Key Sequence:


Username + Password is set set to "test"

Engine: Chrome (Dedicated, but non dedicated doesn't work also)

The key sequence enters "estest" in the first textbox and then a context menu pops up on the top left corner of Royal TS. (see screenshot)


(6.56 KB)

1 person likes this


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 :(

It did still not work like it was before the patches... but I was able to change the Key Sequence so that it now works...


{ENTER} had some strange behaviour... so I now Submit the form with SPACE on the Submit Button

Also I had the problem with one extra random Keystroke in front of the $EffectivePassword$ so I added the {BACKSPACE}... very strange but at least its now working...

I agree in that I no longer see the context menu being selected in the Chrome plugin in version 5.0.61429.

That is weird. Anyone else is seeing this?

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.


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:

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.


Login or Signup to post a comment