Actually the problem happens with any arrow key. When a Keyman keyboard is active, pressing up, down, left or right in Paratext 8, then pressing backspace will delete the character to the left of the original cursor position, not the location where the cursor has moved with the arrow keys.
I assumed this was a problem with Paratext 8, since I didn’t see the problem using the keyboard(s) anywhere else (Word, LibreOffice Writer, text editors, etc.) and not even in Paratext 7, so that’s why I reported the problem on the Paratext web site. But obviously Keyman is also partially to blame, since OS and MSKLC keyboards don’t have this problem. But as Steve mentioned, I have seen the problem with keyboards created with a variety of versions of Keyman Developer (some quite old), and I’ve seen the problem with both Keyman 9 and 10. So it seemed like Paratext 8 must be MORE at fault…
Okay, so I’ve heard some more via email on this issue, and it appears that this relates to Firefox 45 that PT8 embeds and uses internally. Unfortunately, this version of Firefox has a number of serious bugs in its text input subsystem and the way it interfaces with Windows Text Services Framework (TSF).
One workaround for the issue is to turn off Keyman’s TSF integration: https://help.keyman.com/kb/94 This forces Keyman into a ‘legacy’ mode that switches off Firefox’s buggy subsystem. (If using Keyman 10, update the registry paths to ‘10.0’ instead of ‘9.0’).
Side note: fault is a difficult term here. Who is at fault? PT for using a buggy version of Firefox DLLs? Mozilla for publishing a buggy version of their DLLs? Microsoft for creating a horrendously complex TSF specification? Keyman for using the horrendously complex TSF interfaces? I’d prefer not to assign blame. Complex systems have complex problems… We just need to find the solutions
I have tried the workaround, and it does seem to take care of the problem, from my limited testing. One note… I’m using Keyman 10 Alpha, so the location of the registry key that I needed to add was:
Note that it isn’t just changing 9.0 to 10.0 in the registry paths as Marc suggested, but the base is Keyman instead of Tavultesoft as well. Maybe this should be noted in the HOWTO?
So now the questions become: Are there any bad side-effects of this change? Is Mozilla fixing these problems, and will those fixes then be integrated into Paratext? If so, when can I expect that it will be safe to remove this registry entry again?
Good catch on the 10.0 path. Yes, we should update the HOWTO; we should plan to do that as Keyman 10 goes into beta.
Per your questions.
Are there any bad side-effects of this change? The primary side-effect is that Keyman will no longer be able to read the context of content in Paratext. For many users, this is not a big issue; it becomes an issue when working with normalisation or when editing text (e.g. you may need to delete a whole consonant cluster for Indic scripts and retype instead of editing the last component, depending on the keyboard layout). One additional downside is that this is a global setting, so it impacts MS Word and FieldWorks as well (these are two significant apps that also support TSF).
Is Mozilla fixing these problems, and will those fixes then be integrated into Paratext? The problems have already been resolved in Firefox, last year. Thunderbird has not yet integrated the fixes. I do not know what the Paratext timeline is for updating the Firefox components.
If so, when can I expect that it will be safe to remove this registry entry again? That depends on the Paratext team.
Respectfully, due to the inactiveness of the conversation, this topic is now closed for any further discussion.
Please feel free to create a new topic if there is any question or the issue persists.
