Start a new topic
Solved

Chrome Key Sequence not working since update

Hi,


since Update 5.0.61428 Key Sequences are not working anymore on Web Page Connections (Chrome)


image


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

Just a small update: I've contacted the vendor (Essential Object) and provided a repro project for them. They blame it on the Chromium Engine but one of their competitor's product works fine with the keyboard input. Essential Objects is working on integrating the V77 engine and since they are aware of the issue now (they are also aware that their competition's product works correctly), I assume they will look into it. If they don't, I can explore integrating the component of the other vendor. Unfortunately the performance and quality of that other component is not as good as Essential Object's. So replacing it wouldn't be an option and shipping the other component side-by-side will increase the download package size by... a lot. I also have to find out if I can even host two different chromium engines in one app.


Anyhow, let's wait for their next release and see what they come up with. I'm really sorry about that and I wish I can do something to fix it...


1 person likes this

Thanks for confirming! I hope this release is more stable with key sequence tasks.


1 person likes this

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:

https://stackoverflow.com/questions/55068873/selenium-chrome-mobileemulation-not-allowing-sending-key-enter-or-key-return


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:

{WAIT:2500}$EffectiveUsername${TAB}$EffectivePassword${TAB}{ENTER}


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)

image



htm
(6.56 KB)

1 person likes this

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

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...


{WAIT:3000}{TAB}$EffectiveUsername${TAB}{BACKSPACE}$EffectivePassword${TAB}{TAB}{SPACE}


{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...

After a update to v5.1.build 61114 nothing has changed for me.

I've tried to completely uninstall RoyalTS and install it from scratch the newest version. But again: Nothing has changed. Insted of pressing ENTER, the auto sequence task types SHIFT+TAB. And sometimes the password is entered wrong also.

Now, I'm back on v5.0 build 61330 again - the last working version (with some embedded windows bugs in case of using RVTools or Hyena).

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.


Thanks! 

Login or Signup to post a comment