[Windows] Compatibility issues with Firefox

[darcywong00]

A user reported to @DavidLRowe via email about compatibility issues involving the Mozhi Malayalam keyboard with Firefox.

The expected output is different from Chrome, Notepad, and other apps.

Configuration

Keyman Desktop 10.0.1200.0
Mozhi Malyalam keyboard v. 1.2
Windows 10
Firefox Quantum 61.0.2 (64-bit)

The keystrokes amlam results in the following

Chrome, Notepad (correct)

Keystroke	Output character stream
a	U+0D05
m	U+0D05 U+0D02
l	U+0D05 U+0D2E U+0D4D U+0D32 U+0D4D
a	U+0D05 U+0D2E U+0D4D U+0D32
m	U+0D05 U+0D2E U+0D4D U+0D32 U+0D02

Firefox (incorrect)

Keystroke	Output character stream
a	U+0D05
m	U+0D05 U+0D02
l	U+0D2E U+0D4D U+0D32 U+0D4D
a	U+0D2E U+0D4D U+0D32
m	U+0D2E U+0D4D U+0D32 U+0D02

[DavidLRowe]

Just to clarify: the data in the tables above was generated with version 2.0.4 of the keyboard (currently work in progress https://github.com/beniza/keyboards/tree/master/release/m/mozhi_malayalam), whereas @darcywong00 tested with version 1.2 of the keyboard.

[mcdurdin]

Can we please get a minimal repro keyboard .kmn put together and attached as a file to this report -- it's really hard to verify against changing versions of keyboards.

[beniza]

Sure, I'll work on it. However this problem is consistent across the versions.

…

On Mon, Aug 20, 2018 at 7:34 PM Marc Durdin ***@***.***> wrote: Can we please get a minimal repro keyboard .kmn put together and attached as a file to this report -- it's really hard to verify against changing versions of keyboards. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AErnq5s61JR4OgIcvTdBlJ2H0di3s6UUks5uSsHYgaJpZM4V9ezI> .

[beniza]

Here's a keyboard that can demonstrate the incompatibility on FF. A workaround is also suggested. [mozhi-ff-issue-demo.zip](https://github.com/keymanapp/keyman/files/2312690/mozhi-ff-issue-demo.zip)

[beniza]

For the ease of read, I'm pasting the code
below.

store(&VERSION) '9.0'
store(&NAME) 'mozhi-ff-issue'
store(&COPYRIGHT) '© beniza'
store(&MESSAGE) 'To test the FF compatibility issue'
store(&KEYBOARDVERSION) '0.1'
begin Unicode > use(main)

group(main) using keys

c ====================================================================
c BUG
c   We should find why this breaks only on FF
c   My observations:
c     - '്' is the virama (inherent vowel killer) in Malayalam.
c     - For whatever reason in FF the rule is matches the preceding
consonant also as part of the match.
c     - Does Chrome and FF uses the same version of HarfBuzz?
c --------------------------------------------------------------------
+ [K_K] > 'ക്'
'്' + [K_R] > '്ര്' c <<<< This rule causes the Keyman compatibility issue
in Firefox

c ==========================================
c WORKAROUND
c   Re-write the keyboard to avoid rules that trigger the issue
c ------------------------------------------
store(cKeys) 'g'
store(cValues)  'ഗ'
+ any(cKeys) > index(cValues, 1) '്'
any(cValues) '്' + 'r' > index(cValues, 1) '്ര്' c <<<< This won't break in
FF

[mcdurdin]

Thanks, that makes it much easier to be sure I'm reproducing the same issue and not chasing something unrelated!

[mcdurdin]

OK, I've reproduced the issue here. Not yet clear if it is specific to Malayalam or more general. Testing in other apps indicates a possible bug in Firefox's TSF integration; will keep investigating.

[mcdurdin]

The issue only arises when Keyman is integrating with Firefox in TSF mode. If I add the deep tsf integration=DWORD:0 registry value then Keyman uses legacy integration with Firefox and input works as expected. There are still a number of open issues in the Firefox bugzilla database on TSF integration, so worth checking these to see if this issue has been reported there in some form.

[beniza]

Marc, Thank you for suggesting a solution that doesn't require re-writing
of the keyboard. I just tried the solution suggested by you and it fix the
issue.

BTW, the path to the Keyman Engine has been changed and the kb document
need to be updated accordingly

Change from:

On a 64-bit version of Windows, in the Registry Editor find
HKEY_LOCAL_MACHINE › Software › Wow6432Node › Tavultesoft › Keyman Engine › 9.0.

Change to:

On a 64-bit version of Windows, in the Registry Editor find
HKEY_LOCAL_MACHINE › Software › Wow6432Node › Keyman › Keyman Engine › 10.0.

[LornaSIL]

@marc the other problem I mentioned with FF is demonstrated with this keyboard:
Philippines SIL

This keyboard has various deadkeys which all seem to work except for problems with the underscore deadkey:

In FireFox, if you use your keyboard and type "_c" you get _c. If you use the osk and your mouse and select _ + c you get ````ç(as intended). In Chrome, you always get the cedilla whichever way you type it. Other keystrokes to try would be_o```, ```_a```, ```_w``` and ```_1```. Also, ```&:``` is supposed to output ```÷``` and it only works if you use the osk with mouse selection of those keys in Firefox. Again they work fine in Chrome.

Help file with keystrokes is here: https://help.keyman.com/keyboard/sil_philippines

[mcdurdin]

@LornaSIL the symptoms of that issue are subtly different. I'd like to treat them as separate issues until we can determine root cause in each case. Would you be willing to file a new issue with the details and reference this issue?

[mcdurdin]

@beniza Glad to hear that helps. I do regard this as a workaround rather than a solution, because it is a big hammer to solve a problem for a single app -- it disables TSF integration with all apps that support it, in particular MS Word and FieldWorks. We will continue to pursue this issue for a full resolution.

[mcdurdin]

See also https://community.software.sil.org/t/keyman-keyboard-misbehaving-in-bloom/2121/8

[mcdurdin]

Recommendation: that we establish a set of window classnames to test against (possibly also executable name?) and maintain this for automatic disabling of advanced tsf.

[kamholz]

What is the timeframe on fixing this? We've noticed several issues with the newly released aksarabali_panlex keyboard in Firefox on Windows. We can ask people to switch browsers but obviously that isn't ideal.

[mcdurdin]

@kamholz I hope to be able to find the resources to investigate this compatibility issue in 13.0; for now the workaround at #1107 (comment) is the best option.

It may be that this is a bug in Firefox's TSF integration; certainly the issue does not arise in other TSF-aware applications. If that is the case, then we need to raise it as an issue in Bugzilla.

If it is a bug in Firefox, then we would probably aim to make the 'deep tsf integration' control more granular and easier to configure as a mitigation.

[kamholz]

@mcdurdin thanks for the update. We have 20 or so Balinese users of this keyboard. I don't think that asking all the Firefox users to change a registry value is practical. I guess we'll just tell them to use Chrome instead.

[mcdurdin]

@kamholz Yeah, I agree. I don't think the workaround this is in any way practical for the average end user. Our team is just so resource constrained that I cannot realistically hope to address this as quickly as I want to. (You never know, I might have a sleepless night and try to solve it but I can't really plan that way!)

[mcdurdin]

Tracking in #3710. Potential fix in Firefox.