Closed mcdurdin closed 5 years ago
Full source: nul_context_ios_bug.zip
How to test the iOS beta version?
How to test the iOS beta version?
Visit http://keyman-ios-beta.herokuapp.com/ to sign up
Thanks. But it’s not working.
The email with which I had signed up before is not allowed to sign up again. The email I had received for version 10 says the code is already redeemed.
I tried two different email to sign up. I am not getting any emails from the site.
Sign up site is down!
Please check.
Once enrolled, you download the Keyman beta releases via the TestFlight app from the iTunes store.
Yes, I have done that.
In fact, I had test the Keyman version 10.
Between enrollment and downloading the Keyman beta releases via the TestFlight app from the iTunes store, we need an email with "TestFlight invitation Code" to Redeem on the TestFlight app. Without the "TestFlight invitation Code", App will not be able to install the Keyman beta app.
I had received "TestFlight invitation Code" for Keyman version 10. That link doesn't work anymore, App says its already redeemed.
I tried with two new different emails, I am not receiving the "TestFlight invitation Code" to those two emails.
Please try to resolve this in version 11.
Could we try to resolve this now?
the very word typed with keyman fails!
It's not good. I have stopped use using it.
There could be more bugs, unless we get these obvious bugs fixed, we won't be able to fully test it
This issue depends on #1652
@mcdurdin https://github.com/keymanapp/keyman/issues/1652 is merged now.
Could you please try to close this issue.
Is there anything that I can contribute? by testing or something.
@MayuraVerma I am travelling over the next month so my availability is limited. It's still on our agenda to resolve, and having #1652 done certainly makes the resolution for this more feasible.
I'm quite certain that the context
statement isn't the root cause, especially since it doesn't have any issues on other platforms. I've been doing a bit of testing and found something else - the iOS app likes assigning text fields with an initial LTR (\u200e
) or RTL (\u202e
) mark, and this is being copied into KMW space along with the context we actually want.
Of course, this has the effect of breaking what context
returns, but it's actually an in-app context copying error.
Alas, it's not quite that simple. Turns out there's another issue at play - any time the context goes empty, the UIInputViewController
method textDidChange
is automatically called, even if the change is triggered by the UIInputViewController
itself - and asynchronously at that. This is the same function that allows us to detect when the user has deliberately changed the context, which is important to handle when valid.
What's happening in the test keyboard:
'1' + [K_W] > context '2'
temporarily deletes the context ('1'
) before re-emitting it and then emitting the '2'
. That brief moment of empty context triggers textDidChange
, which itself triggers a reset of the tracked text and caret position that desynchronizes the system keyboard from its embedded KMW. Though the '2'
is emitted, that textDidChange
event clears the embedded context completely, allowing the nul + [K_E]
rule to trigger.
Why it doesn't happen in-app: our TextView
and TextField
implementations trigger after this event and correct the error instantly.
We'll probably need to internally 'swallow' the triggered event. I'm having trouble seeing a way around adding what would technically be a race condition, though it's one that would require extreme input speed from a user (or an automated test) to trigger in an adverse manner.
Let us know if any issues like this continue to occur; a fixed version of the iOS app should be out shortly to address this issue.
@jahorton @mcdurdin Thank you very much is it going to be in version 11 or 12 alpha? Can I get access to 12 alpha release, also? I want to test the predictive text model.
We backported the fix to 11.0. It will appear in build 11.0.323, which is building now and should be available in the next day or so.
Version 12 is available for download from https://keyman.com/alpha. However, the predictive text models are unfinished at present so you won't be able to see much yet.
@mcdurdin FYKI. We still don't see updates in app store.
Yes, I see the deployment to app store failed. We are waiting on migration right now of some infrastructure so this will be delayed a bit further. Once the migration is complete, I can re-run the build.
Does iOS 13 let custom keyboard use swipe option?
Does iOS 13 let custom keyboard use swipe option?
I doubt it. We have plans for swipe in future versions of Keyman, if we can find the resources to implement it. That's not really part of this topic though!
Working on the deployment; it will be addressable without needing to wait for the migration to complete, so that's good news.
Okay, the app has been submitted for review. Now we just have to wait on Apple.
I received the update. This is resolved.
The following keyboard goes wrong in iOS when using the system keyboard, at and only at the start of a document. It does not go wrong in the Keyman app or on Android.
Both the
context
rule and thenul
rule are relevant to the issue. Spider senses suggest that thecontext
statement is the root cause but investigation needed.This issue was reported at https://community.software.sil.org/t/ios-keyboard/1311