[Xposed Framework Modules] Roughy:
Exi for Swiftkey 2.3.6 release

2.3.6 [28.08.2019 ] - Compatibility ( Stable: 7.3.6.19 Beta: 7.3.7.18 )

Changes in 2.3.6

Fixed

- Cursor reverting to old position when moving vertically ( swipe-selection )

- Swipe-selection and quick-menu failing for some users ( NPE )

The Xposed Installer app does not appear to be refreshing properly and may not list the latest version.

Please download it directly from the Xposed Repository below using a browser.

Download:

Exi for Swiftkey on Xposed module repository

My own mirror of all versions

Notes:

I was going to wait around for more weird issues to pop up, but apparently we have a deal breaker so let's get to it.

Swipe selection and quick-menu failing

The log [MENTION=4896512]Alexey71[/MENTION] made this one easy to track down.

As it quite evident form the log, we attempt to read from a value from an object, but the object is null ( doesn't exist ).

I actually do check to make sure this value isn't null in many, many places, but apparently I missed one.

The greater mystery here is how this went unnoticed for so long.

Swipe-selection ( or anything relying on gesture detection ) will disable itself the moment it thinks something is wrong so we don't break Swiftkey's core functionality.

If that object can be null at that location it... should have happened before.

Should be fixed, in any case.

Cursor reverting to old position when moving vertically [MENTION=8462009]darcijr09[/MENTION]

When we move the cursor, the concept of lines doesn't really exist; it's all a single long line of text.

The cursor position is determined by a numerical value, corresponding to the number of characters in the text.

There is technically no difference between positioning the cursor and selecting text; moving only the cursor simply means the start and the end of the selection is at the same position.

They we we handle vertical movement is by sending key-presses instead.

A while back we ( I? someone else? I forget ) noticed that the cursor would jump back to the previous letter if you tried to place it at the end of a line of text next to a line break.

We also use the key-press approach to deal with some quirks in right-to-left languages. The text isn't stored right-to-left, but is flipped when android displays it.

Once we are in a block of left-to-right or right-to-left text we can keep track of the direction of move the cursor as normal, but the key-press approach is required at boundaries between them, and at manually-inserted line breaks.

The cause of the problem in that case was that once swipe-selection concludes and Swiftkey is finally informed of the updated cursor position, any changes made by inputting key-presses is ignored., which in turn causes it to jump back to the previous position. For a LTR-language this behavior would only trigger by a line break, causing this strange behavior.

Luckily the cursor position data we receive does reflect these changes, and all we have to do is read back this position and explicitly set the selection ( the cursor position ) again.

So we fixed this a long time ago, I just... didn't realize it would be a problem for vertical selection too, and never applied the fix to that.

Derp. Fixed!