feat(web): Caps Layer and double-tap gesture 🕊 by mcdurdin · Pull Request #5989 · keymanapp/keyman

mcdurdin · 2021-11-30T22:27:07Z

Implements the Caps Lock layer support and the double-tap gesture on the shift key to access it.

The double-tap gesture has been implemented with a view to extension to support other multi-tap gestures in the future. However, for now, it is limited to supporting the Shift key, if and only if the keyboard includes a Caps layer.

The reason for this v15 limitation is that multi-tap on regular keys would involve either rewinding the previous keystroke (the first tap), or forcing keyboard developers to consider 'rota' style rules in their keyboards to support the multi-tap gestures, as we need to make sure that the first tap is accepted and processed for immediate feedback. This needs more design, to avoid unnecessary complexity in the keyboards and/or the rewinding of the keystroke (even though that is conceptually supported in Keyman Engine for Web already). Basically, we don't want to constrain the way that a keyboard author may use the multi-tap gesture by hard-coding the rewind, but neither do we want to make all multi-tap gestures needlessly complex to author.

The shift key (and other modifiers, potentially in future) needs special support for multi-tap as the key that is being tapped changes with the layer change. This is currently managed through recognising K_SHIFT in the key id.

I have tried to follow the PendingGesture pattern for multi-tap, and the gesture itself supports a series of taps, not just a double-tap. The maximum time to complete the tap series is 125msec * number-of-taps, so for a double-tap is 250msec.

The changes to support a Caps Lock layer itself were minimal; just adding the text.KeyboardProcessor.getStateFromLayer function and calling it during KeyEvent construction. The remaining changes relate to the multi-tap gesture.

Minor changes:

I moved constructNullKeyEvent to KeyEvent in order to make it more accessible to other classes.
The multi-tap gesture does not have a promise to complete, so that is now an optional member of the PendingGesture interface.

Note:

The testing page for KeymanWeb includes a test for just the Caps Lock layer support, caps_lock_layer_3620.js, and a full Caps Lock and Start of Sentence test, full_caps_3620_3621.js.

User Testing

SUITE_BASELINE: Test that nothing has changed in existing keyboards

Run through basic usage tests of a variety of keyboards, including sil_euro_latin and khmer_angkor.
Test longpress keys, layer switching, flick-up gesture.
For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

TEST_BASELINE_WEB: On testing/unminified, run through the above tests. Make sure no script errors are encountered. Do this both for desktop and touch modes.
TEST_BASELINE_ANDROID: In Keyman for Android, on an Android device or emulator, run through the above tests, both system and in-app keyboards.
TEST_BASELINE_IPHONE: In Keyman for iPhone, on an iPhone device or emulator, run through the above tests, both system and in-app keyboards.
TEST_BASELINE_IPAD: In Keyman for iPad, on an iPad device or emulator, run through the above tests, both system and in-app keyboards.

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Run through a basic usage test of caps_lock_layer_3620.zip.
Double-tap the shift key. Watch how it switches to a Caps layer (see the 'shiftlock' style of the Shift key).
Test that the Caps layer works correctly. Note that the Shift layer on caps_lock_layer_3620 does not shift back to the base layer automatically; this is intentional.
With the full_caps_3620_3621.zip keyboard, test that the Caps layer is accessible through double-tap shift, and that the interactions with Caps Lock and Shift are 'intuitive'.
For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

TEST_CAPS_WEB: On testing/"Test Caps Lock Layer (spec: Caps Lock layer for touch layouts #3620)", run through the above tests. Make sure no script errors are encountered.
TEST_CAPS_ANDROID: In Keyman for Android, on an Android device if possible, run through the above tests, both system and in-app keyboards.
TEST_CAPS_IPHONE: In Keyman for iPhone, on an iPhone device if possible, run through the above tests, both system and in-app keyboards.
TEST_CAPS_IPAD: In Keyman for iPad, on an iPad device if possible, run through the above tests, both system and in-app keyboards.

Fixes #3620. Implements the Caps Lock layer support and the double-tap gesture on the shift key to access it. The double-tap gesture has been implemented with a view to extension to support other multi-tap gestures in the future. However, for now, it is limited to supporting the Shift key, if and only if the keyboard includes a Caps layer. The reason for this v15 limitation is that multi-tap on regular keys would involve either rewinding the previous keystroke (the first tap), or forcing keyboard developers to consider 'rota' style rules in their keyboards to support the multi-tap gestures, as we need to make sure that the first tap is accepted and processed for immediate feedback. This needs more design, to avoid unnecessary complexity in the keyboards and/or the rewinding of the keystroke (even though that is conceptually supported in Keyman Engine for Web already). Basically, we don't want to constrain the way that a keyboard author may use the multi-tap gesture by hard-coding the rewind, but neither do we want to make all multi-tap gestures needlessly complex to author. The shift key (and other modifiers, potentially in future) needs special support for multi-tap as the key that is being tapped changes with the layer change. This is currently managed through recognising `K_SHIFT` in the key id. I have tried to follow the `PendingGesture` pattern for multi-tap, and the gesture itself supports a series of taps, not just a double-tap. The maximum time to complete the tap series is 125msec * number-of-taps, so for a double-tap is 250msec. The changes to support a Caps Lock layer itself were minimal; just adding the `text.KeyboardProcessor.getStateFromLayer` function and calling it during `KeyEvent` construction. The remaining changes relate to the multi-tap gesture. Minor changes: * I moved `constructNullKeyEvent` to `KeyEvent` in order to make it more accessible to other classes. * The multi-tap gesture does not have a promise to complete, so that is now an optional member of the `PendingGesture` interface.

keymanapp-test-bot · 2021-11-30T22:27:14Z

User Test Results

Test specification and instructions

🟥 SUITE_BASELINE: Test that nothing has changed in existing keyboards

✅ TEST_BASELINE_WEB (PASSED): The OSK seems to work fine, but there is a catch. I don't know what "script error" would entail, but as far as the usage of the OSK is concerned, nothing stops me from using the keyboards. (notes)
🟥 TEST_BASELINE_ANDROID (FAILED): ???** In Keyman for Android, on an Android device or emulator, run through the above tests, both system and in-app keyboards. (notes)
✅ TEST_BASELINE_IPHONE (PASSED): ?** (notes)
✅ TEST_BASELINE_IPAD (PASSED): No obvious error is found. (notes)

🟥 SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

✅ TEST_CAPS_WEB (PASSED) (notes)
🟥 TEST_CAPS_ANDROID (FAILED): ??** (notes)
🟥 TEST_CAPS_IPHONE (FAILED) (notes)
🟥 TEST_CAPS_IPAD (FAILED) (notes)

Test Artifacts

Removed the 'heuristic' test as it is probably not appropriate for testing. Removed the mobile-specific platform from the touch layout as it did not include a caps layer (and should have been identical to the tablet one anyway).

ermshiperete

Didn't see anything obvious, but my knowledge in that part of the code is pretty limited 😄

ermshiperete · 2021-12-11T11:10:58Z

common/core/web/keyboard-processor/src/text/keyboardProcessor.ts

    }

+    /**
+     * Get state key state from layer id


Is the double state intentional?

Yes, on 101 key keyboards, the 'state' keys are the caps lock, num lock, scroll lock keys, but we only care about Caps Lock. So this is retrieving the state of these keys 😆.

Both getStateFromLayer and getModifierState above could be better; right now a layer called "foolscapsymbols" (okay, it's a stretch) would also be considered a 'caps lock' layer.

ermshiperete · 2021-12-11T11:12:50Z

common/test/keyboards/full_caps_3620_3621/source/full_caps_3620_3621.kmn

+    c this is a heuristic: if we find two+ characters in capitals, leave
+    c us in shift layer, assuming the user hasn't just switched layer
+    c themselves. Not sure if this is a good idea!
+    c if(&layerChanged = "0") if(&layer = 'shift') any(caps) any(caps) > layer('caps') c ??? is this a good idea?


do you want to keep this comment?

Perhaps I should probably remove that heuristic altogether? I will leave it for now but think about it for a follow-up PR.

web/testing/caps-lock-layer-3620/caps_lock_layer_3620.js

MakaraSok · 2021-12-14T09:02:41Z

SUITE_BASELINE: Test that nothing has changed in existing keyboards

TEST_BASELINE_WEB: PASSED The OSK seems to work fine, but there is a catch. I don't know what "script error" would entail, but as far as the usage of the OSK is concerned, nothing stops me from using the keyboards.

The OSK doesn't show keycaps in capital letters when Caps key is active.

On Touch devices, everything works without any issue, but on iPad: the characters on keycaps are kinda a little too small.
TEST_BASELINE_ANDROID: FAILED?
- In-app: longpress keys are not working in simulator, but OK in a physical device.
  
  longpress.not.working.mov
- System: no obvious issue found, but a glitch found in the rapid touch where the preview key stops showing after some time.
  
  https://keymanapp.slack.com/files/U6Q7Y6XTM/F02QMS0KDQT/screen_recording_20211214-155720_keyman.mp4
TEST_BASELINE_IPHONE: PASSED?
- In-app: No obvious issue found, but there is always a keypress/tap noice when the keyboard finishes starting up. I've never heard this before. Two keypresses/taps are heard in-app and one as a system keyboard. Keyman sometimes crashes (see the beginning of the recording below.)
  
  crash.and.keypress.noice.-.480p.mov
Note also that the "Get Started" page doesn't show up even though it's on in the settings.
- System: no issue other than the mysterious keypress/tap noice.
TEST_BASELINE_IPAD: PASSED No obvious error is found.
- In-app: Unlike on iPhone, the "Get Started" page is always shown at start up. I've noticed that one keypress/tap noice is heard before the page is shown and another after the page is closed.
  
  Screen.Recording.2021-12-14.at.2.14.25.PM.mov
- System: no issue other than the mysterious keypress/tap noice.

mcdurdin · 2021-12-17T02:36:43Z

Make sure no script errors are encountered

To check for script errors when testing KeymanWeb, open the Developer Console (F12 on Chrome/Windows) -- script errors are shown in red and can be located by clicking the
button in the top right of the Developer Console.

mcdurdin · 2021-12-17T04:09:26Z

System: no obvious issue found, but a glitch found in the rapid touch where the preview key stops showing after some time.
https://keymanapp.slack.com/files/U6Q7Y6XTM/F02QMS0KDQT/screen_recording_20211214-155720_keyman.mp4

This video no longer appears available?

mcdurdin · 2021-12-17T04:12:21Z

[TEST_BASELINE_ANDROID] In-app: longpress keys are not working in simulator, but OK in a physical device.

This may not be related to this change; can we do a screenshare test together on this?

@keymanapp-test-bot retest SUITE_BASELINE TEST_BASELINE_ANDROID

MakaraSok · 2021-12-20T02:36:03Z

System: no obvious issue found, but a glitch found in the rapid touch where the preview key stops showing after some time.
https://keymanapp.slack.com/files/U6Q7Y6XTM/F02QMS0KDQT/screen_recording_20211214-155720_keyman.mp4

This video no longer appears available?

Screen_Recording_20211214-155720_Keyman.mp4

MakaraSok · 2021-12-20T03:39:53Z

SUITE_BASELINE: Test that nothing has changed in existing keyboards

TEST_BASELINE_ANDROID: FAILED??? In Keyman for Android, on an Android device or emulator, run through the above tests, both system and in-app keyboards.

Run through basic usage tests of a variety of keyboards, including sil_euro_latin and khmer_angkor.

OK, but longpress doesn't work on emulator. Nothing like this is seen on a physical device.

Test longpress keys, layer switching, flick-up gesture.

OK

For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

The key preview may disable during a speed tapping. See the screenshot recording in the comment right above.

MakaraSok · 2021-12-20T03:54:06Z

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

TEST_CAPS_ANDROID: FAILED??

Run through a basic usage test of caps_lock_layer_3620.zip.

One of the basic usage of the keyboard doesn't work as expected. Long press keys are not responsive; the subkeys do not pop up as expected on Android 10 simulator API 29. Note that this doesn't happen on the physical device.

Double-tap the shift key. Watch how it switches to a Caps layer (see the 'shiftlock' style of the Shift key).

Working OK.

Test that the Caps layer works correctly. Note that the Shift layer on caps_lock_layer_3620 does not shift back to the base layer automatically; this is intentional.

Each key is working OK, but those keys with longpresses on the simulator. On the physical device however, this doesn't happen.

With the full_caps_3620_3621.zip keyboard, test that the Caps layer is accessible through double-tap shift, and that the interactions with Caps Lock and Shift are 'intuitive'.

Each key is working OK, but those keys with longpresses. On the physical device however, this doesn't happen.

For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

The test is not quite practical, but it does appear that the preview went off and on amid typing.

Screen_Recording_20211220-104706_Keyman.mp4

MakaraSok · 2021-12-20T04:06:49Z

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

TEST_CAPS_IPHONE: FAILED

Run through a basic usage test of caps_lock_layer_3620.zip.

Nothing weird observed.

Double-tap the shift key. Watch how it switches to a Caps layer (see the 'shiftlock' style of the Shift key).

Working OK, but the weird thing is the double tap seem unnatural to the touch. You don't hear the two taps, just one is heard. :/

Test that the Caps layer works correctly. Note that the Shift layer on caps_lock_layer_3620 does not shift back to the base layer automatically; this is intentional.

Each key is working OK including longpresses.

With the full_caps_3620_3621.zip keyboard, test that the Caps layer is accessible through double-tap shift, and that the interactions with Caps Lock and Shift are 'intuitive'.

Not only that the double tap is unnatural to the touch, it doesn't enable caps layer at all. Double tap the Shift key and start typing SS gives you Ss instead.

For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

No physical device within reach right now.

MakaraSok · 2021-12-20T06:25:42Z

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

TEST_CAPS_IPAD: FAILED

Run through a basic usage test of caps_lock_layer_3620.zip.

Nothing weird observed.

Double-tap the shift key. Watch how it switches to a Caps layer (see the 'shiftlock' style of the Shift key).

Working OK, but the weird thing is the double tap seem unnatural to the touch. You don't hear the two taps, just one is heard. :/

Test that the Caps layer works correctly. Note that the Shift layer on caps_lock_layer_3620 does not shift back to the base layer automatically; this is intentional.

Each key is working OK including longpresses.

With the full_caps_3620_3621.zip keyboard, test that the Caps layer is accessible through double-tap shift, and that the interactions with Caps Lock and Shift are 'intuitive'.

Not only that the double tap is unnatural to the touch, it doesn't enable caps layer at all. Double tap the Shift key and start typing SS gives you Ss instead.

Screen.Recording.2021-12-20.at.1.20.41.PM.mov

For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

No physical device within reach right now.

MakaraSok · 2021-12-20T06:42:19Z

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

TEST_CAPS_WEB: PASSED

Run through a basic usage test of caps_lock_layer_3620.zip.

Nothing weird observed.

Double-tap the shift key. Watch how it switches to a Caps layer (see the 'shiftlock' style of the Shift key).

Working OK.

Test that the Caps layer works correctly. Note that the Shift layer on caps_lock_layer_3620 does not shift back to the base layer automatically; this is intentional.

Each key is working OK including longpresses.

With the full_caps_3620_3621.zip keyboard, test that the Caps layer is accessible through double-tap shift, and that the interactions with Caps Lock and Shift are 'intuitive'.

OK

For testing on a physical device: test that rapid touches across multiple keys works correctly, as does multi-touch (where you start tapping the next key before releasing the previous, e.g. rapid two-thumb typing). These are not easy to test in an emulator!

No physical device within reach right now.

mcdurdin · 2022-01-17T19:19:27Z

Failing test feedback:

Android: the longpress issue on emulator is captured at bug(android): longpress appears to be working inconsistently with start-of-sentence #6113.
iOS: the issue with in-app context loss causing the caps lock layer to cancel is probably the same as bug(ios): in-app keyboard does not work correctly with start-of-sentence #6112.
iOS: the issue with double-tap not giving a double click is now captured in bug(ios): double-tap on shift key does not give two click sounds #6121.

As I have now captured the three failure cases as separate issues, I will go ahead and merge this PR, with the caveat that these issues must be resolved before release.

keyman-server · 2022-01-18T18:00:58Z

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

MayuraVerma · 2022-02-08T20:18:57Z

How to enable CAPS LOCK with double tap in Keyboard?

MayuraVerma · 2022-02-08T20:22:45Z

I have tried in iOS 15.0.188-alpha with EUROSIL
no sign of caps lock with double tap on shift key.

MayuraVerma · 2022-02-08T23:22:15Z

I tested full_caps_3620_3621.zip with iOS 15.0.188-alpha

CAPS lock turns off, after a key stroke
CAPS lock should stay in that state until turned off
if not there is not difference between CAPS lock and shift layer.

mcdurdin · 2022-02-12T23:43:16Z

@MakaraSok or @bharanidharanj, are you able to replicate the issues that @MayuraVerma has experienced? Can you work with Mayura to build a reproducible test case so we can resolve this before release?

mcdurdin · 2022-02-12T23:43:40Z

I have tried in iOS 15.0.188-alpha with EUROSIL

The SIL Eurolatin keyboard has not yet been updated to support Caps Lock 😄

MayuraVerma · 2022-02-13T00:39:06Z

I have tried in iOS 15.0.188-alpha with EUROSIL

The SIL Eurolatin keyboard has not yet been updated to support Caps Lock 😄

Yes, I realized it later. since then I tested full_caps_3620_3621.zip with iOS 15.0.188-alpha

Capslock works. But I am thinking we are leaving it to the keyboard developer to choose the next layer after output in CAPS layer, default should be it should remain in CAPS layer. Once we enter CAPS layer, only why to get out of CAPS layer should be release the CAPS lock. This is how it works in hardware, we should mimic the same in software keyboard also.

MayuraVerma · 2022-02-13T00:40:33Z

I have tried in iOS 15.0.188-alpha with EUROSIL

The SIL Eurolatin keyboard has not yet been updated to support Caps Lock 😄

My earlier assumption was, web/ios/android picks up the NCAPS state from kmn. looks like we need to rewrite it mobile version.

mcdurdin · 2022-02-13T00:46:40Z

My earlier assumption was, web/ios/android picks up the NCAPS state from kmn.

Yeah, unfortunately given how the touch and physical keyboards diverge, we could not find a safe way to do this automatically. My preference is always to give the control to the keyboard designer, in any case -- but the trade-off is that we don't get this kind of behaviour "for free".

mcdurdin · 2022-02-13T00:48:12Z

Once we enter CAPS layer, only why to get out of CAPS layer should be release the CAPS lock.

There are two ways, in our design, that the Caps Lock layer is released on touch:

When the user touches the Caps Lock key again (or another modifier key accessible on the Caps Lock layer).
When the user switches apps or input contexts. This matches the behaviour of the system keyboards -- Caps Lock state is not maintained long-term, unlike on a hardware keyboard.

So if you are seeing behaviour that does not match those conditions, that is definitely a bug. And if you can give repro steps, that will help us squash the bug!

mcdurdin added this to the A15S19 milestone Nov 30, 2021

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

github-actions bot added common/ common/core/ common/web/ web/ web/engine/ feat labels Nov 30, 2021

chore(web): minor cleanup of pending longpress

5fbb1c1

This was referenced Nov 30, 2021

feat(web): Start of Sentence support - part 1 🕊 #5963

Merged

spec(web,developer): multitap and flick for touch keyboards 🐵 #5029

Closed

chore: tweak keyboard rules for full caps

2159df1

Removed the 'heuristic' test as it is probably not appropriate for testing. Removed the mobile-specific platform from the touch layout as it did not include a caps layer (and should have been identical to the tablet one anyway).

mcdurdin changed the title ~~feat(web): Caps Layer and double-tap gesture 🍆~~ feat(web): Caps Layer and double-tap gesture 🕊 Dec 9, 2021

mcdurdin modified the milestones: A15S19, A15S20 Dec 11, 2021

ermshiperete approved these changes Dec 11, 2021

View reviewed changes

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

mcdurdin removed this from the A15S20 milestone Jan 3, 2022

mcdurdin modified the milestones: A15S21, A15S22 Jan 3, 2022

Base automatically changed from feat/developer/3620-developer-ide-support to master January 17, 2022 01:13

Merge branch 'master' into feat/web/3620-caps-layer

44ddf1e

This was referenced Jan 17, 2022

bug(ios): double-tap on shift key does not give two click sounds #6121

Open

bug(ios): in-app keyboard does not work correctly with start-of-sentence #6112

Closed

mcdurdin merged commit 2227040 into master Jan 17, 2022

mcdurdin deleted the feat/web/3620-caps-layer branch January 17, 2022 19:19

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

Uh oh!

Conversation

mcdurdin commented Nov 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

User Testing

SUITE_BASELINE: Test that nothing has changed in existing keyboards

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Uh oh!

keymanapp-test-bot bot commented Nov 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

User Test Results

🟥 SUITE_BASELINE: Test that nothing has changed in existing keyboards

🟥 SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Test Artifacts

Uh oh!

ermshiperete left a comment

Choose a reason for hiding this comment

Uh oh!

ermshiperete Dec 11, 2021

Choose a reason for hiding this comment

Uh oh!

mcdurdin Dec 12, 2021

Choose a reason for hiding this comment

Uh oh!

ermshiperete Dec 11, 2021

Choose a reason for hiding this comment

Uh oh!

mcdurdin Dec 12, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MakaraSok commented Dec 14, 2021

SUITE_BASELINE: Test that nothing has changed in existing keyboards

Uh oh!

mcdurdin commented Dec 17, 2021

Uh oh!

mcdurdin commented Dec 17, 2021

Uh oh!

mcdurdin commented Dec 17, 2021

Uh oh!

MakaraSok commented Dec 20, 2021

Uh oh!

MakaraSok commented Dec 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

SUITE_BASELINE: Test that nothing has changed in existing keyboards

Uh oh!

MakaraSok commented Dec 20, 2021

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Uh oh!

MakaraSok commented Dec 20, 2021

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Uh oh!

MakaraSok commented Dec 20, 2021

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Uh oh!

MakaraSok commented Dec 20, 2021

SUITE_CAPS: Test that the new Caps Lock layer controls work correctly

Uh oh!

mcdurdin commented Jan 17, 2022

Uh oh!

keyman-server commented Jan 18, 2022

Uh oh!

MayuraVerma commented Feb 8, 2022

Uh oh!

MayuraVerma commented Feb 8, 2022

Uh oh!

MayuraVerma commented Feb 8, 2022

Uh oh!

mcdurdin commented Feb 12, 2022

Uh oh!

mcdurdin commented Feb 12, 2022

Uh oh!

MayuraVerma commented Feb 13, 2022

Uh oh!

MayuraVerma commented Feb 13, 2022

Uh oh!

mcdurdin commented Feb 13, 2022

Uh oh!

mcdurdin commented Feb 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

mcdurdin commented Nov 30, 2021 •

edited

Loading

keymanapp-test-bot bot commented Nov 30, 2021 •

edited

Loading

MakaraSok commented Dec 20, 2021 •

edited

Loading

mcdurdin commented Feb 13, 2022 •

edited

Loading