Virtual keyboard interface for form elements

Virtual keyboard interface for form elements

Hello all. Due to request, I have modified my Javascript Virtual Keyboard script into an Opera UserJS!

Once installed, just double click any text, password or textarea form input to display a virtual keyboard which can be used with the mouse. I was thinking the main use for this script could be for servers which have had their keyboards removed; so any HTML-based setup interfaces can be used without scrounging for a replacement keyboard. But there are other uses, like allowing input of localized special characters using mouse only, all that's required is to add your own keyboard layout following the instructions in the code!

Check out screenshots of the virtual keyboard in action:
Yahoo!
Opera Community
Google


Download the userjs


You can read more about the script, including how to add it to your own pages, so users of other browsers can access the interface as well!

Thank You! Thank You!

That was real fast, very nice work!
I owe you a

great! thanks!

I added the Lithuanian and Russian keyboard layouts prepared by Ramunas
I added the German keyboard layout prepared by QuHno
I added the French keyboard layout prepared by Hidden Evil

Would it be possible to implement this png as a button? sure, it is
There´s no need to identify input fields by a script (ok, might be a ´nice to have´ feature *g*)
A virtual keyboard button...that´s it

btw, up to now, I´ve thought Lucky Luke is fast...

thx in advance
Tim

The script was messing up on Facebook pages displaying tagged images. Seems the facebook API was duplicating one of my function names. I have fixed the userJS script and updated the version to 1.0b. There should be a lot less chance of conflicts on webpages now.

http://www.greywyvern.com/code/js/keyboard.userjs.js

Thanks again for working so hard during the (?) night!

edit: There seems to be a little glitch. When I cange the KB to an other language, it collapses...

@TBuktu:
That might not be possible without massive code changes because AFAIK JS code in buttons is restricted to a length of about 950 chars in total. The script will blow up to >20000 chars after removing comments, putting all in one line, escaping several chars to the button format (Space = %20, "= %22 etc.) and adding the button specific code...

An external solution like the one used by the developer console might be possible, maybe we can talk the opera People into hosting the script on a permanent basis (so that we don't steal the bandwidth from GreyWyvern) or, even better:
integrate it into the Opera source. That could solve the dead key (i.e.: ´`^˚ (...)) problem too

Oh, and I´ve thought the script would have been reduced.
The goal is a virtual keyboard, activated by button and the input from this virtual keyboard is sent to the field where the cursor is placed
But if it is only my wish...it is not worth investigating such a big time and effort

Tim

Originally posted by QuHno:

That might not be possible without massive code changes because AFAIK JS code in buttons is restricted to a length of about 950 chars in total. The script will blow up to >20000 chars

AFAIK, bookmarklets don´t have a lenght limit anymore

Originally posted by QuHno:

edit: There seems to be a little glitch. When I cange the KB to an other language, it collapses...

Ooooooooooops! Fixed this!
http://www.greywyvern.com/code/js/keyboard.userjs.js

Originally posted by TBuktu:

The goal is a virtual keyboard, activated by button and the input from this virtual keyboard is sent to the field where the cursor is placed

In all seriousness, I am interested in knowing how this would be useful for you. The current version requires no buttons, instead a double-click on "the field where the cursor is placed" automatically opens the keyboard for that field. I would think this method is much simpler than having a keyboard hanging around all the time while you're filling out a form. The only use for it I can see is if you are filling out a large form, then your method avoids the double click each time.

In any case, the two different behaviours would not be compatible, and I would probably have to end up maintaining two versions.

The big fixes I have in mind for new versions is support for layout-specific dead keys and a snazzier look.

2Screenshot.png
Here's a screenshot of it in action

New version today! Now supports a range of keyboard dead keys. Plus you can add your own!

http://www.greywyvern.com/code/js/keyboard.html

BOH! The Crapmaster of Yahoo! germany uses the following Code
<input class="plong inputtext" type="text" id="p" name="p" accesskey="s">
That breaks the Virtual-Keyboard

What ... .... comes to their minds?

I've been making a few tweaks over the past few hours and likely fixed your problem because the virtual keyboard works for me on Yahoo! Germany. You're using it on the search box at the top, right?

Make sure download the latest version (refresh if necessary):
http://www.greywyvern.com/code/js/keyboard.userjs.js

Thanks for checking

It was the latest version but there must be something with my settings, it still doesn't work on one of my computers (Vista). Checking with an other one (XP), it worked. The Opera version and settings are the same but it might be the different firewall...

No need to worry about, all other tested pages are fine

Originally posted by QuHno:

It was the latest version but there must be something with my settings, it still doesn't work on one of my computers (Vista)

If you open the Error console in this browser when trying to use the keyboard on that page, does it reveal anything further about the error(s)?

There were 2 JS errors and several CSS errors in the console, but AFAICS they all seem to be Y!de errors or "JS not loaded" errors because of my urlfilter.ini

JavaScript - http://de.yahoo.com/
Inline script thread
Error:
name: TypeError
message: Statement on line 13: Could not convert undefined or null to object
Backtrace:
  Line 13 of inline#5 script in http://de.yahoo.com/
    (document.getElementById("sethomepage")).parentNode.style.display = ! YAHOO.Fp.shp ? "block" : "none";
  Line 15 of inline#5 script in http://de.yahoo.com/
    YAHOO.Fp.eyebrow = (function ()
{
  (document.getElementById("sethomepage")).parentNode.style.display = ! YAHOO.Fp.shp ? "block" : "none";
}
);
YAHOO.Fp.eyebrow();
JavaScript - http://eur.a1.yimg.com/java.europe.yahoo.com/eu/ads/sp2js/sp2flash6.js

Das verlinkte Skript wurde nicht geladen. (translation: linked script not loaded)

I can send the complete output to you, if you are interested (CSS Errors included, if the keyboard is there but just doesn't show because of some crappy CSS Code on that page)

Maybe an onload event handler helps against that, but I am not sure how it would behave with pages that are partially down and never fire up the onload event - but don't worry about that, it might be a country related problem (they change some parts of the page according to the IP) or a specific problem with my own settings.

No need to change your script because of that


BTW: How about using the browser language settings (accept language) as default keyboard instead of the US in one of the next versions?

Originally posted by QuHno:

There were 2 JS errors and several CSS errors in the console, but AFAICS they all seem to be Y!de errors or "JS not loaded" errors because of my urlfilter.ini

It seems likely that the error is halting script execution so the keyboard is never initialized.

Originally posted by QuHno:

BTW: How about using the browser language settings (accept language) as default keyboard instead of the US in one of the next versions?

You can set the default keyboard the script uses by changing the value of the "this.VKI_kt" variable to the name of the keyboard you want. I can't really use language settings since even users of the same language can prefer different keyboards. Better to let them select their own default when they install the script.

BTW, I have added a few more tweaks to the script, including improvements in how dead keys are handled visually. Check it out Make sure you refresh the pages and scripts to get the latest versions.
http://www.greywyvern.com/code/js/keyboard.html

Originally posted by GreyWyvern:

It seems likely that the error is halting script execution so the keyboard is never initialized.

That seems likely, indeed. Now there is just the question if it can be initialized "by force"...
I'm not sure, but I remember having read that there is a mechanism to initialize scripts before the page contend is loaded. I think it is done in the browser.js when changing pages like yahoo

You can set the default keyboard the script uses by changing the value of the "this.VKI_kt" variable to the name of the keyboard you want.

I had figured that out

I can't really use language settings since even users of the same language can prefer different keyboards. Better to let them select their own default when they install the script.

Agreed, it seems to be the best behavior. I didn't think about the 3 different settings for German keyboards alone (Standard/Austria/Swiss) and about countries with more than one language, like - let me think about it just a minute: Canada

Now added: Greek and Polish Programmers (special thanks to moose) keyboard layouts!
http://www.greywyvern.com/code/js/keyboard.html

I have changed the trigger from the load event to the DOMContentLoaded event which may help bypass the Yahoo! errors if they happen onload. If Yahoo! is running those scripts inline, though, they will still be running before the keyboard UserJS.

de.yahoo.com now works for me
It was my urlfilter.ini that caused the main JS error. Now I have modified it a little bit and the new version of the virtual keyboard works even with the other errors on that page. The old one still doesn't work here but that is obsolete now
Thanks again!


edit:
I have made some little changes to my private version of the script. If some users might want to customise their versions too:

Line 48, border a little bit red and background like the page background:
data:text/css,#keyboardInputMaster{position:absolute;border:2px groove #ff5555;background-color:inherit;

I just think about customising the look of the keys to a little bit 3D style, maybe when I'm back from work ...

Line 68, to emulate the behavior of my 3D keyboard:
this.VKI_deadkeysOn = true;

Line 69, chauvinistic reasons :
this.VKI_kt = "Deutsch"; // Default keyboard layout

Line 113, see change above:
this.VKI_layout.Deutsch = [ // German Standard Keyboard

Line 291, 294, 304, 305, unescaping umlauts:
clearer.appendChild(document.createTextNode(unescape("L%F6schen"))); // was: Clear



PS: Adding some more comments in places safe to change could make customizing easier for users with less JS expierience (i.e. me)

@GreyWyvern

You ´re right. Doubleklick works fine.
Unfortunately the keyboard appears in every case...just when im doubleklicking.
Sometimes, I like to use the normal keyboard as usual
Might be a personal problem with the touchpad respektively with my nervous index finger *g*

Thanks anyway
Tim

Originally posted by TBuktu:

Might be a personal problem with the touchpad respektively with my nervous index finger *g*

Valeriana!

Of cause you could write a onNTimesClick routine and replace the ondoubleclick event handler in line 249 or just change the doubleclick settings of your touchpad, too...

Now updated to version 1.3 !
http://www.greywyvern.com/code/js/keyboard.html

- Interaction styling changes (Alt, AltGr, Shift)
- Justified keys - last key expands to fit width
- If no dead keys in layout, dead key checkbox is hidden
- Option to disable dead keys per keyboard
- Added the Number Pad layout

version 1.4!!
BTW, as your site don't has RSS feeds, please update this topic with the news. So we can stay tuned! Thank you!

Sorry There isn't all that much difference between 1.3 and 1.4. Just styling and the version number in the corner.

You can get it here, as always!
http://www.greywyvern.com/code/js/keyboard.html

Originally posted by GreyWyvern:

Sorry There isn't all that much difference between 1.3 and 1.4. Just styling and the version number in the corner.

... and customisation hints at your webpage. A very important update IMHO

Do you think it would be useful against keyloggers? I don't know very much about JS

Originally posted by YinYanger:

Do you think it would be useful against keyloggers? I don't know very much about JS

For loggers which simply intercept signals between the keyboard and the OS, for sure. For keyloggers which more closely integrate with the browser you are using, I'm not so sure. Those latter kinds of programs may be able to read the contents of form elements no matter what you use to fill them, but I'm no expert on that.

I've worked in the security realm and there are two types of keyloggers last I checked: hookers and pollers.

Hookers actually hook into the interface between the keyboard and the computer. Pollers repeatedly ask the keyboard interface if a key was pressed. Neither of these times would detect data entered from the virtual keyboard as it is actually mouse input. This is not to say a keylogger couldn't be bundled with some other info stealing mechanism but based on the 2 type of keyloggers, they would not detect this data.

And what about keyloggers that take screen-shots of the clicked area? They can trap the onClick events on JS's? Just curious...

I've found another very nice Javascript Virtual Keyboard (but don't works in Opera) at
http://sourceforge.net/projects/jsvk

An to the author: what about a checkbox to optionally see the NumPad attached to the selected layout?

Best regards!

Originally posted by YinYanger:

I've found another very nice Javascript Virtual Keyboard (but don't works in Opera) at
http://sourceforge.net/projects/jsvk

That's a nice keyboard, but the code is huge!

Pros
- It supports many more keyboard layouts than mine ever could, including things like multi-key kanji-suggest! I can only dream of supporting a Chinese/Japanese/Korean keyboard
- It seems to mimic keyboard codes so pressing a key may actually trigger a keypress event which can trigger other scripts.
- It has a backwards-L Enter key! Mine can't do that because the keys are all table cells.

Cons
- The visible layout of the keys is pretty much static. eg. you can't change how many keys appear in a row, so you can't do unusual layouts like a number pad, or the US keyboard which does not have a backwards-L shaped Enter key.
- The keyboard has to appear within the flow of the document, or as a popup window. Adding it as a dynamic layer would probably not be that hard to hack in, though.
- Like you said, doesn't work in Opera.
- Because the code is so large, it's probably not something you would make into a UserJS.

Originally posted by YinYanger:

An to the author: what about a checkbox to optionally see the NumPad attached to the selected layout?

It would make the keyboard quite wide :| But it is possible and I can see how it could be useful. Perhaps in an upcoming version I will add it.

Originally posted by GreyWyvern:

Like you said, doesn't work in Opera.

Actually, it works (almost). My adBlocking.js UserJS was blocking it. I liked its visual, but it is *too* heavy!!! I really prefer yours! And having it into Opera Portable as a UserJS it's great!!

Originally posted by GreyWyvern:

It would make the keyboard quite wide

That's why I said "a checkbox to optionally...". But the only needed characters would be the digits (and maybe the currency chars).

Another suggestion would be to define the layouts in a external file. This way we can add our own layouts (in my case, a brazilian portuguese layout) without interfere in your logic.
As an example, I can think in the great OSpell ( http://opera.gt500.org/ospell/ ). The trick is to have 2 .js files: OSpell.js for the core and a-OSpell_prefs.js for the preferences. As the UserJS files are loaded alphabetically, a-OSpell_prefs.js it's loaded first

Originally posted by YinYanger:

And what about keyloggers that take screen-shots of the clicked area? They can trap the onClick events on JS's? Just curious...

This would be a combination tool of a keylogger + screen capturer. Keyloggers don't take screenshots. period. This solution is not fool-proof or hack-proof but no keylogger that i've ever worked with monitors mouse clicks. They only interact with the keyboard.

See this article at http://authentium.blogspot.com/2007/03/virtual-keyboards-offer-zero-protection.html
Long time ago I heard about keyloggers that take a shot of the region around the mouse position where you click. The these screen-shots are sent to the keylogger's owner.
This is why my bank has a virtual keyboard as an applet with digits that disappear when you click them and the digits position changes every time you log-in.

Originally posted by YinYanger:

See this article at http://authentium.blogspot.com/2007/03/virtual-keyboards-offer-zero-protection.html

That's quite interesting, but take what he's saying with a grain of salt. He's pushing his own keylogger-security software. It's in his own best interest to badmouth his competition.

I agree with you, GreyWyvern.
But (again)

Originally posted by YinYanger:

Long time ago I heard about keyloggers that take a shot of the region around the mouse position where you click. Then these screen-shots are sent to the keylogger's owner.This is why my bank has a virtual keyboard as an applet with digits that disappear when you click them and the digits position changes every time you log-in.

Version 1.4a released. This is a small update which changes the display method so that the keyboard is completely removed from the document when it is hidden. This prevents it from appearing due to conflicting CSS media styles such as when you press Shift+F11 in Opera.

http://www.greywyvern.com/code/js/keyboard.html

Now updated to version 1.5.
- Italian and Spanish (Spain) keyboard layouts added by dictionarist.com

http://www.greywyvern.com/code/js/keyboard.html

Now updated to version 1.6.
- Hebrew keyboard layout added by Enon Avital

http://www.greywyvern.com/code/js/keyboard.html

Just for reference, greasemonkey scripts actually require the scripts to end in *.user.js. Opera's don't. Its strange you have opera using *.user.js and the greasmonkey script using *.gmscript.js. However, in opera files ending in *.user.js do not fire until DOMContentLoaded or Load (not sure which) to remain compatibile with most greasemonkey scripts.

I performed a diff of the files and they are very very similar. I think it would make your life much easier if you just used one file (the *.userj.s one) and made it function for both. Opera supports the same eventTarget model (element.addEventListener) that ff does. That seems to be a lot of the differences. You use elem.addEventListener('click',...) in ff but elem.onclick = ... in opera.

Great script btw...

Now updated to version 1.7
- Arabic keyboard layout added by Srinivas Reddy
- Same UserJS file now works for both Opera and Firefox

http://www.greywyvern.com/code/js/keyboard.html

Very cool. Thanks. Good idea to combine the two.

Now updated to version 1.8
- Various performance fixes (thanks, fearphage, for prodding me into it *hehe* )

http://www.greywyvern.com/code/js/keyboard.html

Now updated to version 1.9
- Hungarian keyboard layout added by Antal Sall

http://www.greywyvern.com/code/js/keyboard.html

that's really a great script! cheers!

Now updated to version 1.10
- Slovenian keyboard layout added by Miran Zeljko

http://www.greywyvern.com/code/js/keyboard.html

Now updated to version 1.11
- Position:fixed tweaks for browser updates since first release
- Fix for IE6 bug with covering select elements (static version only)
- Burmese keyboard layout added by Cetanapa

http://www.greywyvern.com/code/js/keyboard.html

Hi All

I am a newbie

How do you download this script and where and how do you install it?

I am on Win XP SP3 Using Opera 9.52

Thank you very much

Terry

Here the Documentation how to enable UserJS: Adding User JavaScripts
Downloading is easy: Rightclick on the URL of the script and "Save Linked Contend as..." in your UserJavascript folder.