keymanapp / keyman Goto Github PK

We need to review this on each modern browser and if it works reliably, we can upgrade KMW keyboards to support both.

https://msdn.microsoft.com/en-us/library/ie/ff974894(v=vs.85).aspx
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.location

Arising from the Keyman Developer demo during Bootcamp

Attached keyboard demonstrates the issue. Q key is 'phone' or 'tablet'. Easiest to run this in Keyman Developer web debugger.

chrome_emulator_iphone6plus.zip

Currently, any device with a touch screen is treated like a mobile device and has its inputs covered with the blocker elements to absorb touch handlers. This causes problems for users of touch screen laptops because the blocker element does not respond to being clicked on, preventing users from selecting the input underneath. In addition to this, using the blocking element via the touch screen does not allow the user to type with their keyboard.

While these issues mostly effect users on touchscreen laptops, the typing problems could also extend to users of tablets with keyboard attachments.

To work around this problem on my employer's website I've had to modify the util code relating to device identification. I changed it so that if the device is touchable but also has a form factor of desktop, the touchable field is set to false. I considered running the desktop initialization separately instead, but I noticed a lot of functions that run differently on touchable devices and decided not to.

Another thing worth noting is that passing the blocking element to KeymanWeb.attachToControl() allows to it work with keyboard input, but it does allow the user to move the caret with arrow keys (moving me away from using that).

There should be no mouse events in the touch interfaces because this causes duplicate events.

It would be great if you could add support for these flags in KeymanWeb on those browsers that support l/r ctrl/alt.

I get the error: Extended shift flags LALT, RALT, LCTRL, RCTRL are not supported in KeymanWeb.

Thanks and regards,
John

A separate, embedded font specified for the OSK is not being applied.

removeKeyboards should return true if keyboard(s) were successfully removed, and false otherwise. It shouldn't throw an error.

See http://www.tavultesoft.com/forums/topic.php?ForumTopicID=367&ForumPostID=1242 for back story.

If you define a nextlayer property for a given key, this overrides the output rule defined for the key, so it becomes a plain modifier key. This is probably not a good situation -- ideally, the nextlayer control should allow output, then swap layers.

A workaround is to use the layer(<name>) statement in the keyboard source for the associated rule instead.

There appears to be some inconsistencies in how the OSK is constructed with respect to the emulator in Chrome. This should be reviewed.

• Review use of .kmw-portrait/.kmw-landscape classes

• Scaling for keyboard per devices in the test window (this code may need cleanup yet):

    tavultesoft.keymanweb.getOskHeight = function() {
      if(tavultesoft.keymanweb.util.device.formFactor == 'phone') {
        if(tavultesoft.keymanweb.util.portraitView()) {
          var height = 428;
        } else {
          var height = 220;
        }
        height=height/2; //tavultesoft.keymanweb.util.getViewportScale();
    
      } else {
        if(tavultesoft.keymanweb.util.portraitView()) {
          var height = 264;
        } else {
          var height = 350;
        }
        height=height/tavultesoft.keymanweb.util.getViewportScale();
      }
      return height;
    };
  

• Review the key sizes, etc, against all common keyboards before we go live with this.

Keyman for Android does not support SPACEBAR and ENTER on external keyboards. The issue lies in KeymanWeb code.

Issue moved from private as the fix is applied to KeymanWeb.

The current keyboard loading and registration process has some inefficiencies that need to be resolved.

• If a keyboard has already been loaded by KeymanWeb, adding a new stub that uses a loaded keyboard will attempt to reload the keyboard by making cloud requests and injecting script tags before realizing, at the last moment, that it's already loaded the thing.

• Stub processing is deferred until initialization can fully proceed and is directly linked to how the initial active keyboard is set. That needs to be decoupled.

If you include <script src='keymanweb.js'></script> more than once, KeymanWeb should be smart enough to not instantiate multiple times...

The Khmer keyboard here at least gives the following error when you click the bookmarklet:

KeymanWeb: Invalid call to r.keymanweb.com - page missing

When using the KeymanWeb ToggleUI, removing a keyboard with a call to KeymanWeb.removeKeyboards() while exactly 2 keyboards are loaded causes the ToggleUI to break. From what I've looked at when doKeyboardUnregistered is called the event handler for ToggleUI doesn't remove the removed keyboard from its internal keyboard array. This then leads to all kinds of issues when it attempts to switch the button back into single course mode.

Currently, minified KeymanWeb includes a __BUILD__=xxx; line which ends up assigning that value to window.__BUILD__. Similarly, dfltLayout is also global.

KeymanWeb in kmwcallback.js:795 tests for the device.browser in a specific set but fails to remember that 'web' is a grouping of all the web browsers and should only exclude 'native'.

When registering a keyboard in KMW, the developer must include a 'language' member in the object with an array of language objects. However, the name of this member in the cloud API is 'languages'.

See http://help.keyman.com/developer/engine/web/2.0/webapi.php vs http://help.keyman.com/developer/engine/web/2.0/reference_kmw20_core_addKeyboards.php (recently updated to match implementation)

Hi,

Thanks for the great library!

We're using Version 1.0 and are considering moving to version 2.0 (which I'm currently testing), however we're facing an issue with using the keyboard in an application that relies on onChange events firing (for example - in a 3rd party library like this https://github.com/gcanti/tcomb-form).

As you probably know, onChange events only fire when an input is manipulated via a user action, however we need these to fire when someone clicks one of the keys in the virtual keyboard.

While I can track typed-values using code like this:

{code}
myInput.addEventListener(
'keyup',
function() { console.log('test') },
false);
{code}

I can't seem to figure out how to listen to the event that corresponds to someone clicking a key via the moust (or for the matter, can't find a way to manually trigger an onChange event via KeyManWeb). Tried adding event listeners via kmw.addEventListener and kmw.osk.addEventListener, and had a through read of the documentation.

Any help would be appreciated.

In cases where KeymanWeb attempts to display two or more messages through util.alert or util.wait, the later message will simply overwrite the former, erasing all evidence of the original message.

If you create a touch layout with e.g. 5 rows on base layer but only 4 rows on subsequent layers, you'll get an error in adjustHeights function which does its calculations based on the first layer and then applies them to all layers identically.

The nextlayer property for keys in a touch layout determines the next layer to be selected after the key is pressed and its output generated. However, currently the nextlayer property overrides output so no output is generated. Furthermore, if the keyboard code sets the next layer via the layer() statement, this will be overridden by the touch layout key's nextlayer property (which it shouldn't be).

So there are two separate issues to resolve:

1. The over-eager processing of nextlayer when the key is being processed in osk.clickKey:

      // Process modifier key action
      // TODO: Fixup the duplication of nextlayer processing here and below.
      //       This breaks the `nextlayer` property on keys with output
      //       even though it does the right thing for modifier keys. 
      if(osk.selectLayer(keyName,nextLayer)) return true;

2. The trashing of any layer change set by the keyboard code, further on in osk.clickKey:

      // Test if this key has a non-default next layer
      if(typeof e.key != 'undefined' && e.key['nextlayer'] !== null) osk.nextLayer=e.key['nextlayer'];

When this is resolved, we need to ensure that existing keyboards do not regress in their modifier key functionality. The behaviour needs to be identical on native and embedded versions (pay particular attention to the longpress keys).

This issue was identified during work arising from #115.

http://caniuse.com/#feat=mutationobserver

http://leaverou.github.io/stretchy shows one way to do it.

The moveToNext function in keymanweb.js never actually checks if the target it wants to focus on exists or not, causing errors when it doesn't. I've seen this come up in my implementation for my employer where moveToNext is called and no other inputs exist on the page.

Android 4.3 and older versions should prioritise SVG because this renders correctly on the built-in browser used for the on screen keyboard in Keyman Pro, and also improves usability in apps.

SVG is not great because it doesn't do complex script but for the OSK it is sufficient.

During debugging and testing for issue #29, I found that the on-screen keyboard code constantly re-assigns text to the OSK spacebar, triggering a DOM mutation with every keystroke and another 40 or so upon toggling the OSK itself.

https://developers.google.com/web/fundamentals/getting-started/primers/promises

We want (and have) a non-blocking init, but there are certain API calls or page code setups that rely upon init() having been called and fail if we don't wait until initialization has already occurred. Promises provide a way to have Javascript reliably execute a block of explicitly post-initialization code and could be used to handle these cases.

Using Keymanweb 2.0 build 396.

Can dynamically add a keyboard from a html select list on a form, but cannot display the keyboard to the form. The user must manually mouse click on the keyboard from the keyboard menu to display the keyboard.

Here is the code:

(function(kmw) { 
    kmw.init();   
    if ($("#id_language_code").val() == 'ar' ) {
        kmw.addKeyboards('arabic_101'); // this will add the keyboard.
        kmw.setActiveKeyboard('Keyboard_arabic_101','arb'); // this should display the vkb .
    } else if ($("#id_language_code").val() == 'ru' ) {
        kmw.addKeyboards('russian'); // this will add the keyboard
        kmw.setActiveKeyboard('Keyboard_russian','rus'); // this should display the vkb 
    }       
}...

The code appears to be correct, but the API does not work as documented.

The only thing it presently does is talk about its failure to register. The console provides no useful information - not even if it's a simple id mismatch with the keyboard to be loaded. We should fix that and provide a little error report.

See https://github.com/tavultesoft/keymanweb/pull/18/files source/keymanweb.js:3510

No matter the actual language or keyboard installed on a system, Keyman labels the default keyboard "English." Shouldn't we perform an actual check somewhere to detect the language and run with that? What if someone wishes to use an alternate name for it?

We need to review this on each modern browser and if it works reliably, we can upgrade KMW keyboards to support both.

https://msdn.microsoft.com/en-us/library/ie/ff974894(v=vs.85).aspx
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.location

Ctrl+Alt key sequences not displaying in onscreen keyboard although we can successfully input characters.

keyboard layout: el_togo
repo: https://bitbucket.org/enablinglanguages/globalbility_project/src/35654d99094891366f20c8bb9c32caf30a1e3cdf/el_togo/?at=master

Some OSK functions can be called early while resources are still loading, if the user interacts with the page, and this can cause an error.

https://bugs.chromium.org/p/chromium/issues/detail?id=676808 describes why and optional workaround

OSK keys on iPhones truncate key text in landscape mode - CSS needs adjusting

In prep for open-sourcing our KMEA/KMEI code and relocating it to this repo, it's noteworthy that we could use some cleanup and refactoring of the embedded-related code paths existing in KMW.

A few note-worthy points:

• keymanweb.fullInitialization is basically just an inverted keymanweb.embedded flag, but isn't nearly as explicit.
• The util.wait function is only ever declared for 'native' mode and basically serves as an embedded marker; the code has a lot of if(typeof(util.wait) == 'function') tests that equate to if(!keymanweb.embedded).
• Accordingly, the code would be simplified if we change those tests to use of the embedded flag and also create an empty stub function for util.wait and util.alert in kmwembedded.js that does nothing.

KeymanWeb does not always set input element directionality correctly when changing input from LTR to RTL language. If an element is empty, it should always change element directionality when the input language directionality changes. (If the element already contains text, the text content will have mixed directionality when new text is added, so changing element directionality automatically is not appropriate.)
In most cases, directionality will be applied correctly by going back to an LTR language then re-selecting the wanted RTL language.

In particular, it doesn't properly shift the bit-array parameter, causing an array-out-of-bounds error that prevents many symbols from working on touch-optimized keyboards and that locks KMEA into desktop mode since the error is presently uncaught when text is entered through an external keyboard.

See keymanweb.executeHardwareKeystrokeInternal, line 513. To prevent overall breakage, either lines 500-517 should be wrapped in a try-catch or line 465 of executeHardwareKeystroke should.

Whenever KeymanWeb is initialized and it seeks out controls as targets for KeymanWeb, it also sets these controls with the formatting necessary to properly display text from the new keyboard. This is fine.

What is not fine is when read-only input elements or kmw-disabled elements are automatically reformatted as well; KeymanWeb shouldn't be affecting these controls if it's not handling their input.

The source is in keymanweb.js's function keymanweb.setupDesktopElement.

The bookmarklet typically loads KeymanWeb after page initialization is complete. This means that kmwinit.js calls keymanweb.init(null); without giving the bookmarklet a chance to set different initialisation arguments.

An appropriate fix would be to postpone initialization to happen async by wrapping the init() call in kmwinit.js with setTimeout(). This would mean that the bookmarklet could inject its own call to init() which would then take precedence over the call in kmwinit.js, but we wouldn't lose the initialization for other pages.

In the numeric/symbol layer, the long press doesn't produce an output. In the default layer, however, it works just fine.

The current code produces lots of warnings when compiled with the latest version of Google Closure.

When using KeymanWeb on a touchscreen device, the keyboard will not work with inputs added to the page after KeymanWeb has initialized. Specifically, new inputs do not get the blocking element added to them that captures the touch event to open the keyboard.

My limited knowledge of web development tells me that automatically setting up the touch stuff on new inputs would not really be a feasible addition, but it would be useful to at least move the touch input initialization into functions that developers can call to add inputs on their own.

At my company I've had to work around this issue by adding the kmwInput property to my new inputs and rerunning the setupTouchDevice function.

Putting the existing touch input setup code blocks into functions doesn't seem too difficult and I may try to fix it myself if I find the time.

Regardless of attachType value, the current initialization code runs setupDesktopPage/setupTouchDevice and adds all controls to the internal input list (keymanweb.inputList) that do not explicitly disable KeymanWeb detachment, even when it is set to manual.

This is likely to cause errors, at minimum, on touch devices when the TAB key is pressed to swap inputs.

After the MutationObserver PR sequence ( #71, #77, #80 ), attachToControl no longer fully covers all use cases... and in fact, never quite did everything necessary for desktop control setup as it was. Additionally, our online documentation makes mention of a detachFromControl method to be implemented soon.

As the MutationObserver code actually provides tons of infrastructure toward both these objectives, the code's ready for refactoring to establish detachFromControl as an actual API function while doing rewriting attachToControl to make a version handling all cases while renaming the old version if it cannot otherwise easily be refactored.

Original issue: https://github.com/sillsdev/keyman-archive-android/issues/7
Then opened as https://github.com/sillsdev/keyman/issues/10 (refer for more screenshots)

Issue by MakaraSok
Thursday May 11, 2017 at 02:52 GMT
Originally opened as https://github.com/sillsdev/keyman-android/issues/7

The Khmer characters on each key are too big and they can't been seen. This is with the Khmer NiDA keyboard from the Keyman keyboard repository.

Please see the screenshot here:

When using a device with a touch screen, the blocking elements added by KeymanWeb are created at the same size as their base input. To deal with the issue of inputs that change size, those inputs get a "resize" event added to them that then calls resizeInput on the blocker element on top of them.

The problem is that resize events seem to only be supported by the window , meaning they cannot be fired (even manually) in the input element.

I tried to get around this by calling the resizeInput function on the blocking element, but that didn't work as anticipated. While the blocking element expanded to fully cover the expanded size of the input, the fake input inside of it did not. It instead remained the same size and moved position to the top left corner of the input.

I've attached three screenshots showing the problem. The first shows the input being covered as expected, the second what happens when the input is made larger (which was also programmed to fire the resize event), and the third what happens after calling the resizeInput function on the blocking element (specifically the one with the "keymanweb-input" class).

Pull request #30 has a fix for INPUT and TEXTAREA elements on mozilla (standards-based) browsers. Need to verify the same fix for older IE and contentEditable code paths as well.