refactor(web): active element management in relation to OSK display control ✂️ #5644

jahorton · 2021-08-26T08:49:35Z

Addresses aspects of #5026.

Follows #5633.

Fixes #5026. (Finally!) This PR finally centralizes management of KMW's active element logic and fixes a few niche scenarios that went relatively undetected until now.

One of the worst aspects of "spaghetti code" in relation to the OSK is how entangled some of its display aspects have been with the web engine's active-element management. While this PR doesn't get everything cleaned up perfectly for active-element tracking, its biggest success is that all logic where the two subsystems intersect has now been centralized within the setters of two properties.

While not actually refactoring OSK code in this PR, it's prep work necessary to continue along the lines of the other ✂️
PRs.

User Testing

SUITE_IN_APP: Host app tests.

All behavior exhibited here should feel "normal". These tests are solely to ensure that nothing got accidentally broken.

Platform / keyboard mode combinations

GROUP_IOS_APP: iOS / Keyman app
GROUP_ANDROID_APP: Android / System keyboard

Suite tests

TEST_NORMAL_LOAD: Ensure that the keyboard displays and works correctly when first loaded up.

Be sure to test one or two keystrokes; ensure that the key produces the expected output.
TEST_ROTATE_P-TO-L:
1. With Keyman not active, load it in a portrait orientation.
2. Once loaded, rotate the device to a landscape orientation.
  - On Android devices, you may need to press something like this for the rotation to occur:
  - The test "passes" if the OSK rotates properly.
TEST_ROTATE_L-TO-P:
1. With Keyman not active, load it in a landscape orientation.
2. Once loaded, rotate the device to a portrait orientation.
  - On Android devices, you may need to press something like this for the rotation to occur:
  - The test "passes" if the OSK rotates properly.

SUITE_DOM: Site-based tests.

All behavior exhibited here should feel "normal". These tests are solely to ensure that nothing got accidentally broken.

OS / Browser combinations

GROUP_WIN: Windows / Firefox (or Chrome, but just one)
GROUP_ANDROID_DOM: Android / Chrome
GROUP_IOS_DOM: iOS (via Simulator) / Safari
- Note: touches near the bottom of the screen may have some interference from Safari; it likes to display the navigation button bar and "shove" KMW's OSK up a bit. This is expected and not a bug; the relocated OSK should function fine afterward.

For each of these, make use of the "Tests the new Attachment/Enablement API functionality" test page.

Suite tests

TEST_NORMAL_USE: Ensure that the keyboard displays and works correctly when first loaded up.
1. Click the "Create Inputs" button one time.
2. Click / touch the new page element. The OSK should display.
3. Use the OSK to type one or two keys. The keys should produce their expected output.
4. Click / touch a blank area of the page. The OSK should automatically hide.
TEST_ELEMENT_HOPPING:
1. Click the "Create Inputs" button one time and the "Create Textarea" button one time.
2. Click / touch the first of the new page elements. The OSK should display.
3. Click / touch the other page element. The OSK should remain visible.
4. Click / tough the first element again. The OSK should remain visible.
5. Click / touch a blank area of the page. The OSK should automatically hide.
TEST_SPECIFIC_KEYBOARDS:
1. Click the "Create Inputs" button three times.
2. Click / touch Dynamic area #0.
3. Click the element's "Set to Dzongkha" button.
4. Change the keyboard to French.
5. Click Dynamic area #1's "Set to Dzongkha button.
6. Click Dynamic area #1. The Dzongkha keyboard should be displayed.
7. Click Dynamic area #2.
8. Change the keyboard to Lao.
9. Click Dynamic area #0. The French keyboard should be displayed.
10. Click Dynamic area #2. The Lao keyboard should be displayed.
11. Click Dynamic area #1. The Dzongkha keyboard should be displayed.
12. Click Dynamic area #0's "Clear Keyboard" button.
13. Click Dynamic area #0. The Lao keyboard should be displayed.

SUITE_CJK: Tests CJK keyboard functionality

OS / Browser combinations

GROUP_MAC: macOS / Firefox

Use the standard "Test unminified KeymanWeb" page.

Suite tests

TEST_JAPANESE_TYPING: Verify that a CJK keyboard still works.
Test sequence
1. Under "Add a keyboard by keyboard name", type japanese, then click Add.
2. Select the Japanese keyboard. The OSK should change shape notably:
1. Type a. A "picker" displaying a few options should display:
1. Type 2. The second option should replace the context.
TEST_JAPANESE_FOCUS: Verify that a CJK keyboard is shown and hidden properly without interfering with a page's UX.
1. Select the page's textarea element. The OSK's title bar should appear (as with step 2 for the _TYPING test).
2. Click a blank area on the page. The OSK should automatically hide and the caret should disappear from the textarea.
  - Just in case, "caret": the blinking vertical line segment that lets you know where new characters will appear in the context.
3. Select the page's input field (the second editable control). The OSK should reappear under the newly-selected control.
4. Select the page's textarea element again. The OSK should remain visible, and the caret should move from the input control to the textarea control.

So, fun fact... the TEST_JAPANESE_FOCUS test above actually fixes an issue that currently exists both on master and on stable_14.0 that had gone unnoticed until this PR's development.

keymanapp-test-bot · 2021-08-26T08:49:40Z

User Test Results

✅ SUITE_IN_APP: Host app tests.

✅ GROUP_IOS_APP: iOS / Keyman app
- ✅ TEST_NORMAL_LOAD (PASSED): The keyboard loads and works as expected.
- ✅ TEST_ROTATE_P-TO-L (PASSED): The keyboard rotates seamlessly. Lovin' it.
- ✅ TEST_ROTATE_L-TO-P (PASSED): The keyboard rotates seamlessly. Lovin' it.
✅ GROUP_ANDROID_APP: Android / System keyboard
- ✅ TEST_NORMAL_LOAD (PASSED): The keyboard loads without Fatal Error and works as expected.
- ✅ TEST_ROTATE_P-TO-L (PASSED): No issue found.
- ✅ TEST_ROTATE_L-TO-P (PASSED): No error after setting Keyman as the system and default keyboard on Android 5.0 and 6.0.

✅ SUITE_DOM: Site-based tests.

✅ GROUP_WIN: Windows / Firefox (or Chrome, but just one)
- ✅ TEST_NORMAL_USE (PASSED): No issue found. Works as intended.
- ✅ TEST_ELEMENT_HOPPING (PASSED): No issue found.
- ✅ TEST_SPECIFIC_KEYBOARDS (PASSED): No issue found.
✅ GROUP_ANDROID_DOM: Android / Chrome
- ✅ TEST_NORMAL_USE (PASSED): Similar minor issue with Safari on iOS. See right below.
- ✅ TEST_ELEMENT_HOPPING (PASSED): The OSK doesn't shown and hide as intended, but the OSK won't appear when clicking in the input area after clicking on the blank area. The culprit might be the same as that of the issue found right above. Since this has nothing to do with hopping, it's marked as PASSED.
- ✅ TEST_SPECIFIC_KEYBOARDS (PASSED): No issue found.
✅ GROUP_IOS_DOM: iOS (via Simulator) / Safari
- ✅ TEST_NORMAL_USE (PASSED): The OSK does show and hide with a little bit of time between touching the inputs and empty area. (notes)
- ✅ TEST_ELEMENT_HOPPING (PASSED): No issue found.
- ✅ TEST_SPECIFIC_KEYBOARDS (PASSED): No issue found.

✅ SUITE_CJK: Tests CJK keyboard functionality

✅ GROUP_MAC: macOS / Firefox
- ✅ TEST_JAPANESE_TYPING (PASSED): The keyboard works as indicated.
- ✅ TEST_JAPANESE_FOCUS (PASSED) (notes)

jahorton · 2021-08-26T08:54:35Z

web/source/dom/domManager.ts

+    get lastActiveElement(): HTMLElement {
+      return DOMEventHandlers.states._lastActiveElement;
    }

-    clearLastActiveElement() {
-      DOMEventHandlers.states.lastActiveElement = null;
+    set lastActiveElement(Pelem: HTMLElement) {
+      DOMEventHandlers.states._lastActiveElement = Pelem;
+
+      if(this.lastActiveElement == null && this.activeElement == null) {
+        this.keyman.osk.hideNow(); // originally from a different one, seemed to serve the same role?
+      }
    }

-    getActiveElement(): HTMLElement {
-      return DOMEventHandlers.states.activeElement;
+    get activeElement(): HTMLElement {
+      return DOMEventHandlers.states._activeElement;
    }

-    _setActiveElement(Pelem: HTMLElement) {
-      DOMEventHandlers.states.activeElement = Pelem;
+    set activeElement(Pelem: HTMLElement) {
+      DOMEventHandlers.states._activeElement = Pelem;
+
+      var isActivating = this.keyman.uiManager.isActivating;
+
+      // Hide the OSK when the control is blurred, unless the UI is being temporarily selected
+      const osk = this.keyman.osk;
+      const device = this.keyman.util.device;
+      if(this.keyman.osk) {
+        if(!Pelem) {
+          if(this.keyman.osk && !isActivating) {
+            this.keyman.osk._Hide(false);
+          }
+        } else {
+          // Force display of OSK for touch input device, or if a CJK keyboard, to ensure visibility of pick list
+          if(device.touchable) {
+            osk._Enabled = true;
+            osk._Show();
+          } else {
+            // Conditionally show the OSK when control receives the focus
+            if(this.keyman.isCJK()) {
+              osk._Enabled = true;
+            }
+            if(osk._Enabled) {
+              osk._Show();
+            } else {
+              osk._Hide(false);
+            }
+          }
+        }
+      }
    }


The biggest win: this area now encompasses all the manners of how the web engine's active-element management controls OSK activation and visibility.

OSK activation and visibility have been noted within #5633 to need significant cleanup; by centralizing the related aspects here, we'll be able to move forward more clearly on the OSK activation & visibility subsystems as a whole. Previously, their entanglement was simply too great.

… for prior commits

…factor/web/active-element-integrations

darcywong00 · 2021-09-03T08:34:41Z

Can probably reformat TEST_SPECIFIC_KEYBOARDS: so GitHub doesn't link the issue/pull request for #1 and #2.

darcywong00 · 2021-09-03T08:39:00Z

web/source/dom/domEventHandlers.ts

      var keyboardID = this.keyman.core.activeKeyboard ? this.keyman.core.activeKeyboard.id : '';
      var langCode = this.keyman.keyboardManager.getActiveLanguage();

      if(PInternalName !== undefined && PLgCode !== undefined) {
        keyboardID = PInternalName;
        langCode = PLgCode;
      }
-
-      var lastElem = DOMEventHandlers.states.lastActiveElement;

      if(lastElem && lastElem._kmwAttachment.keyboard != null) {
        lastElem._kmwAttachment.keyboard = keyboardID;


Won't this now modify the parameter lastElem?

To directly answer your question, yes, it does modify (a property of) the parameter.

That said, that parameter references a KMW-managed property of a persistent, global page element. The parameter is passed to this method for exactly this reason - to perform related updates to the element's KMW-managed properties.

MakaraSok · 2021-09-06T09:52:45Z

SUITE_IN_APP: Host app tests.

GROUP_IOS_APP: iOS / Keyman app
- TEST_NORMAL_LOAD: PASSED The keyboard loads and works as expected.
- TEST_ROTATE_P-TO-L: PASSED The keyboard rotates seamlessly. Lovin' it.
- TEST_ROTATE_L-TO-P: PASSED The keyboard rotates seamlessly. Lovin' it.
GROUP_ANDROID_APP: Android / System keyboard
- TEST_NORMAL_LOAD: FAILED A long standing error appears -- Fatal Error.
  
  Note that this error occurs only 5.0.2 right after setting Keyman as system keyboard and default input method.
  
  On Android 5.0.2, 6.0, 8.1, 10 and 11, there is a fatal error when typing a longpress key on any layer. After that nothing is output from any longpresses, however the normal keys on any layers are working fine after the crash.
  
  Also, there is one weird error which shows up briefly when loading Keyman app in horisontal mode in Android 8.1. It says, "Error in keyboard nul:nul for language".
- TEST_ROTATE_P-TO-L: PASSED
  The keyboard does retate, but not sure if it is properly. The experience is not as smooth as one expects.
- TEST_ROTATE_L-TO-P: PASSED
  The keyboard does retate, but not sure if it is properly. The experience is not as smooth as one expects.

SUITE_DOM: Site-based tests.

GROUP_WIN: iOS / Keyman app
- TEST_NORMAL_USE: BLOCKED
- TEST_ELEMENT_HOPPING: BLOCKED
- TEST_SPECIFIC_KEYBOARDS: BLOCKED
  The instructions provided are not applicable for this pair, as Keyman app does not have the Create Inputs button. This case is marked as BLOCKED for now. Kindly guide me through if the steps taken were not expected/intended.
GROUP_ANDROID_DOM: Android / Chrome
- TEST_NORMAL_USE: PASSED The OSK appears when touching the input area; OSK hides itself when touching elsewhere.
(I assumed that "new page element" refers to the input area which appears after clicking on the "Create Inputs". If this assumption is wrong, please kindly guide me through as it is detrimental to this test suite.)
- TEST_ELEMENT_HOPPING: PASSED The OSK does appear, stay and hide itself when touching Textareas, Inputs and away.
- TEST_SPECIFIC_KEYBOARDS: PASSED Things work as expected.
GROUP_IOS_DOM: iOS / Safari
- TEST_NORMAL_USE: BLOCKED Please check the screenshot below.
  
  It looks like the keyboard doesn't load correctly. The keyboard renders unusable. Probably because of my limited knowledge of how to use Safari emulator. This suite is now marked as BLOCKED.
- TEST_ELEMENT_HOPPING: BLOCKED
- TEST_SPECIFIC_KEYBOARDS: BLOCKED

SUITE_CJK: Tests CJK keyboard functionality

GROUP_MAC: macOS / Firefox
- TEST_JAPANESE_TYPING: PASSED The keyboard works as indicated.
- TEST_JAPANESE_FOCUS: PASSED
  
  I blindly assume that "input control" and "textarea control" are the input area on the standard "Test unminified KeymanWeb" page. With that said, the test PASSED.
  Please guide me if I went off course here.
Verify that a CJK keyboard is shown and hidden properly without interfering with a page's UX.
1. Select the page's textarea element. The OSK's title bar should appear (as with step 2 for the _TYPING test).
2. Click a blank area on the page. The OSK should automatically hide and the caret should disappear from the textarea.
  - Just in case, "caret": the blinking vertical line segment that lets you know where new characters will appear in the context.
3. Select the page's input field (the second editable control). The OSK should reappear under the newly-selected control.
4. Select the page's textarea element again. The OSK should remain visible, and the caret should move from the input control to the textarea control.

mcdurdin

I think this looks ok, pending user testing 😁

jahorton · 2021-09-13T02:30:59Z

@keymanapp/testers

The instructions provided are not applicable for this pair, as Keyman app does not have the Create Inputs button. This case is marked as BLOCKED for now. Kindly guide me through if the steps taken were not expected/intended.

They are applicable for these pairs - you're just referring to the wrong part of the instructions. The DOM tests explicitly say to use the test pages, outside of the apps. Just like you did for the Android one that's part of the same test suite.

MakaraSok · 2021-09-20T05:33:33Z

SUITE_DOM: Site-based tests.

GROUP_WIN: Windows / Firefox
- TEST_NORMAL_USE: PASSED No issue found.
- TEST_ELEMENT_HOPPING: PASSED No issue found.
- TEST_SPECIFIC_KEYBOARDS: PASSED No issue found.
GROUP_ANDROID_DOM: Android / Chrome
- TEST_NORMAL_USE: FAILED When quickly and alternately click back and forth between the input box and blank area multiple times, the OSK seems to be irresponsive and decided to not showing up.
Also, after typing a character and then click on the blank area to hide the OSK, the OSK wouldn't be back up when clicking back in the input area.
- TEST_ELEMENT_HOPPING: PASSED The OSK doesn't shown and hide as intended, but the OSK won't appear when clicking in the input area after clicking on the blank area. The culprit might be the same as that of the issue found right above. Since this has nothing to do with hopping, it's marked as PASSED.
- TEST_SPECIFIC_KEYBOARDS: PASSED No issue found.
GROUP_IOS_DOM: iOS (via Simulator) / Safari
- TEST_NORMAL_USE: PASSED No issue found.
- TEST_ELEMENT_HOPPING: PASSED No issue found.
- TEST_SPECIFIC_KEYBOARDS: PASSED No issue found.

jahorton · 2021-09-21T02:50:34Z

OK, so that last failed user test opened a minor can of worms. There was a "fun" conflict between the focus timer and Android-specific page-scroll handling that simply wasn't ever resolved properly. I think I've figured out how to make the two aspects cooperate, though this did require a few more changes than I'd like. The previous two commits (which accomplished this) may be worth their own review.

As may be noted, I did take the opportunity this provided as an excuse to polish up this area dramatically, removing the old ugly (<any>this.keyman) blocks by providing "proper" definitions where they were previously missing. All changed field and method names were always file- and class-internal, despite where they were being stored. (Things would have been much messier due to the fixes had I not done this.)

jahorton · 2021-09-21T05:26:42Z

@keymanapp-test-bot retest SUITE_DOM TEST_NORMAL_USE

@mcdurdin Looks like that path wasn't quite covered right:

Result of the command above (Seen via drill-down)

Only the first group's test was reset.

So...

@keymanapp-test-bot retest SUITE_DOM GROUP_ANDROID_DOM TEST_NORMAL_USE
@keymanapp-test-bot retest SUITE_DOM GROUP_IOS_DOM TEST_NORMAL_USE

Okay then...

SUITE_DOM
GROUP_ANDROID_DOM
TEST_NORMAL_USE OPEN retest

SUITE_DOM
GROUP_IOS_DOM
TEST_NORMAL_USE OPEN retest

jahorton · 2021-09-21T07:09:47Z

... maybe it needs an extra comment for this type?

SUITE_DOM
GROUP_ANDROID_DOM
TEST_NORMAL_USE OPEN retest

SUITE_DOM
GROUP_IOS_DOM
TEST_NORMAL_USE OPEN retest

Edit: there we go. Finally.

MakaraSok · 2021-09-21T08:46:23Z

SUITE_DOM: Site-based tests.

GROUP_ANDROID_DOM: Android / Chrome
- TEST_NORMAL_USE: PASSED Similar minor issue with Safari on iOS. See right below.
GROUP_IOS_DOM: iOS (via Simulator) / Safari
- TEST_NORMAL_USE: PASSED The OSK does show and hide with a little bit of time between touching the inputs and empty area.
  
  When testing on the emulator, the mouse click may be faster than the reality of when using the actual device. Consequently, the OSK may not behave as intended, unless waiting for a second or so before touching to show or hide it.
  
  The behavior on web in Windows and macOS is more robust when it comes to show and hide the OSK.

mcdurdin · 2021-09-21T23:38:16Z

@jahorton you are pushing that poor little test bot too hard. Currently:

only one bot command allowed per comment.
retest only matches first test, rather than all tests that could match a given string (except in case of 'all' which matches all tests in a suite, group or spec).

So, I expect you could do:

@--keymanapp-test-bot retest SUITE_DOM GROUP_ANDROID_DOM TEST_NORMAL_USE SUITE_DOM GROUP_IOS_DOM TEST_NORMAL_USE

(identifier deliberately mangled to prevent interference.)

Both of these issues should be resolved but as there is a way forward I'll just encourage you to use the recognised incantation for now -- no time this week...

mcdurdin · 2021-09-21T23:39:08Z

unless waiting for a second or so

I've also noted these performance issues. See #5729, #5731 for potential mitigations.

mcdurdin · 2021-09-21T23:39:53Z

The previous two commits (which accomplished this) may be worth their own review.

Okay, re-reviewing. I've got a few things in my queue so hopefully will get to that this morning.

mcdurdin

Changes LGTM

jahorton · 2021-09-22T01:18:54Z

When testing on the emulator, the mouse click may be faster than the reality of when using the actual device. Consequently, the OSK may not behave as intended, unless waiting for a second or so before touching to show or hide it.
The behavior on web in Windows and macOS is more robust when it comes to show and hide the OSK.

Actually, he's referring to something else here:

keyman/web/source/dom/domEventHandlers.ts

Lines 30 to 36 in 3eda9dd

    
           setFocusTimer(): void { 
        
             this.focusing=true; 
        
             this.focusTimer = window.setTimeout(function() { 
        
               this.focusing=false; 
        
             }.bind(this), 1000) 
        
           }

When testing touch-device element attachment, KMW uses this timer to prevent de-focusing selected elements too quickly. I believe that it's been there since before we went open-source.

keyman/web/source/dom/domManager.ts

Lines 1764 to 1772 in a6289f4

    
           this.touchEndActivationHandler = function() { 
        
             // Should not hide OSK if simply closing the language menu (30/4/15) 
        
             // or if the focusing timer (setFocusTimer) is still active. 
        
             if(_this.deactivateOnRelease && !osk['lgList'] && !DOMEventHandlers.states.focusing) { 
        
               _this.activeElement = null; 
        
             } 
        
             _this.deactivateOnRelease=false; 
        
             return false; 
        
           };

My best guess is that it's there to prevent fat-fingering effects from deselecting an element when the touchpoint is lifted, should the off-element part lift after the on-element part... but this is admittedly conjecture and inference on my part. The block above (and the second comment line) includes fixes to use of this timer, based on said guess.

I agree with @MakaraSok that the timer's probably a bit too long, but I didn't want to make that call in this PR.

jahorton · 2021-09-22T02:44:06Z

SUITE_IN_APP
GROUP_ANDROID_APP
TEST_ROTATE_L-TO-P OPEN retest

MakaraSok · 2021-09-22T03:56:54Z

SUITE_IN_APP: Host app tests.

GROUP_ANDROID_APP: Android / System keyboard
- TEST_ROTATE_L-TO-P: FAILED
  1. There is an error after setting the keyboard as system and default keyboard on Android 5.0 and 6.0. It also happens each time the keyboard is loaded in either landscape or portrait mode within the app. This error is not found in Android 8.0, 10.0 and 11.0
    
    5.0
    
    6.0
  2. The loading animation is not as smooth as one would expect it to be. You can see the transition in action while waiting for things to settle.
    
    6.0

SUITE_DOM: Site-based tests.

GROUP_WIN: Windows / Firefox (or Chrome, but just one)
- TEST_NORMAL_USE: PASSED No issue found. Works as intended.

…tegrations

jahorton · 2021-09-22T06:40:36Z

Looks like that bug was addressed on master by #5724. It fits the bill near-perfectly, too.

@keymanapp-test-bot retest SUITE_IN_APP GROUP_ANDROID_APP TEST_ROTATE_L-TO-P retest

MakaraSok · 2021-09-23T00:58:43Z

SUITE_IN_APP: Host app tests.

GROUP_ANDROID_APP: Android / System keyboard
- TEST_ROTATE_L-TO-P: PASSED No error after setting Keyman as the system and default keyboard on Android 5.0 and 6.0.

keyman-server · 2021-09-23T18:02:11Z

Changes in this pull request will be available for download in Keyman version 15.0.118-alpha

jahorton added this to the A15S12 milestone Aug 26, 2021

keymanapp-test-bot bot added the user-test-missing User tests have not yet been defined for the PR label Aug 26, 2021

github-actions bot added web/ web/engine/ refactor labels Aug 26, 2021

jahorton commented Aug 26, 2021

View reviewed changes

jahorton changed the title ~~refactor(web): active element management in relation to OSK display control~~ refactor(web): active element management in relation to OSK display control ✂️ Aug 26, 2021

jahorton mentioned this pull request Aug 31, 2021

refactor(web): osk activation and visibility modeling ✂️ #5661

Merged

jahorton added 4 commits September 1, 2021 09:44

refactor(web): OSK connection to active element

c0e48e6

refactor(web): activeElement, lastActiveElement as properties

6971f09

refactor(web): centralizes element-oriented OSK display logic, polish…

7fd62c5

… for prior commits

chore(web): minor touch-up

a495bf4

jahorton force-pushed the refactor/web/active-element-integrations branch from ab80b75 to a495bf4 Compare September 1, 2021 02:44

jahorton added 2 commits September 1, 2021 10:29

chore(web): Merge branch 'refactor/web/specialized-osk-views' into re…

12f3b6b

…factor/web/active-element-integrations

chore(web): Merge branch 'refactor/web/specialized-osk-views' into re…

79acb98

…factor/web/active-element-integrations

jahorton mentioned this pull request Sep 3, 2021

refactor(web): OSK modularization - common-path code -> OSKView ✂️ #5620

Merged

jahorton added 2 commits September 3, 2021 10:16

chore(web): Merge branch 'refactor/web/specialized-osk-views' into re…

5d155de

…factor/web/active-element-integrations

fix(web): fixes touch-mode focusing issue in unit tests

6842576

jahorton marked this pull request as ready for review September 3, 2021 08:02

keymanapp-test-bot bot added user-test-required User tests have not been completed and removed user-test-missing User tests have not yet been defined for the PR labels Sep 3, 2021

darcywong00 reviewed Sep 3, 2021

View reviewed changes

mcdurdin modified the milestones: A15S12, A15S13 Sep 5, 2021

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Sep 6, 2021

mcdurdin approved these changes Sep 10, 2021

View reviewed changes

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Sep 20, 2021

jahorton added 2 commits September 21, 2021 09:23

fix(web): focus-timer preserves activation on Android

a1516d1

refactor(web): base page touch-handlers

b452092

fix(web): detaches base-page touch handlers on shutdown

a6289f4

keymanapp-test-bot bot added the user-test-required User tests have not been completed label Sep 21, 2021

mcdurdin approved these changes Sep 22, 2021

View reviewed changes

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Sep 22, 2021

jahorton added 2 commits September 22, 2021 13:35

fix(web): null guard on touchMenuPos

06bae02

chore(web): Merge branch 'master' into refactor/web/active-element-in…

c4e8238

…tegrations

keymanapp-test-bot bot added the user-test-required User tests have not been completed label Sep 22, 2021

jahorton linked an issue Sep 22, 2021 that may be closed by this pull request

refactor(web): active element tracking rework #5026

Closed

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Sep 23, 2021

jahorton merged commit e8682e2 into master Sep 23, 2021

jahorton deleted the refactor/web/active-element-integrations branch September 23, 2021 01:07

darcywong00 mentioned this pull request Nov 2, 2021

bug(web): Touch on blank part of page can throw Uncaught TypeErrors #5873

Closed

mcdurdin added the has-user-test label Feb 12, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor(web): active element management in relation to OSK display control ✂️ #5644

refactor(web): active element management in relation to OSK display control ✂️ #5644

jahorton commented Aug 26, 2021 •

edited

keymanapp-test-bot bot commented Aug 26, 2021 •

edited

jahorton Aug 26, 2021

darcywong00 commented Sep 3, 2021

darcywong00 Sep 3, 2021

jahorton Sep 13, 2021

MakaraSok commented Sep 6, 2021 •

edited

mcdurdin left a comment

jahorton commented Sep 13, 2021 •

edited

MakaraSok commented Sep 20, 2021

jahorton commented Sep 21, 2021 •

edited

jahorton commented Sep 21, 2021 •

edited

jahorton commented Sep 21, 2021 •

edited

MakaraSok commented Sep 21, 2021

mcdurdin commented Sep 21, 2021

mcdurdin commented Sep 21, 2021

mcdurdin commented Sep 21, 2021

mcdurdin left a comment

jahorton commented Sep 22, 2021

jahorton commented Sep 22, 2021

MakaraSok commented Sep 22, 2021

jahorton commented Sep 22, 2021

MakaraSok commented Sep 23, 2021

keyman-server commented Sep 23, 2021

refactor(web): active element management in relation to OSK display control ✂️ #5644

refactor(web): active element management in relation to OSK display control ✂️ #5644

Conversation

jahorton commented Aug 26, 2021 • edited

User Testing

SUITE_IN_APP: Host app tests.

SUITE_DOM: Site-based tests.

SUITE_CJK: Tests CJK keyboard functionality

keymanapp-test-bot bot commented Aug 26, 2021 • edited

User Test Results

✅ SUITE_IN_APP: Host app tests.

✅ SUITE_DOM: Site-based tests.

✅ SUITE_CJK: Tests CJK keyboard functionality

jahorton Aug 26, 2021

Choose a reason for hiding this comment

darcywong00 commented Sep 3, 2021

darcywong00 Sep 3, 2021

Choose a reason for hiding this comment

jahorton Sep 13, 2021

Choose a reason for hiding this comment

MakaraSok commented Sep 6, 2021 • edited

SUITE_IN_APP: Host app tests.

SUITE_DOM: Site-based tests.

SUITE_CJK: Tests CJK keyboard functionality

mcdurdin left a comment

Choose a reason for hiding this comment

jahorton commented Sep 13, 2021 • edited

MakaraSok commented Sep 20, 2021

SUITE_DOM: Site-based tests.

jahorton commented Sep 21, 2021 • edited

jahorton commented Sep 21, 2021 • edited

jahorton commented Sep 21, 2021 • edited

MakaraSok commented Sep 21, 2021

SUITE_DOM: Site-based tests.

mcdurdin commented Sep 21, 2021

mcdurdin commented Sep 21, 2021

mcdurdin commented Sep 21, 2021

mcdurdin left a comment

Choose a reason for hiding this comment

jahorton commented Sep 22, 2021

jahorton commented Sep 22, 2021

MakaraSok commented Sep 22, 2021

SUITE_IN_APP: Host app tests.

SUITE_DOM: Site-based tests.

jahorton commented Sep 22, 2021

MakaraSok commented Sep 23, 2021

SUITE_IN_APP: Host app tests.

keyman-server commented Sep 23, 2021

jahorton commented Aug 26, 2021 •

edited

keymanapp-test-bot bot commented Aug 26, 2021 •

edited

MakaraSok commented Sep 6, 2021 •

edited

jahorton commented Sep 13, 2021 •

edited

jahorton commented Sep 21, 2021 •

edited

jahorton commented Sep 21, 2021 •

edited

jahorton commented Sep 21, 2021 •

edited