I use the SIL IPA keyboard frequently filling out webpages in my browser. While it works well, there has been a bug for some time. Most diacritics will work but using onewill erase the glyph before.
Ex: to type a breve over a character, I would normally type “***”. The first one will erase the letter immediately before, the second and third will erase the two letters before that. Adding two spaces after the character and then typing the sequence for the diacritic will normally place it above the character.
This is a consistent issue in Firefox, Chrome, and MS Edge-Chromium.
The work around isn’t working in Chromium-based browsers. It will type stacked versions of the diacritic.
Thanks for the report. Can you provide some additional detail to help us trace this?
Which version of Keyman are you using?
Which version of Windows are you using?
What is the exact key sequence you type (i.e. the whole sequence, not just the final keys)?
What output do you expect to receive?
What output do you actually receive?
Which keyboard and version of the keyboard are you using?
Are you using a US or European base keyboard?
To show keys in your key sequences, you can surround them with <kbd> and </kbd>. e.g. to show keys like this: QWE …, you would enter: <kbd>Q</kbd><kbd>W</kbd><kbd>E</kbd>
I believe this is happening in Firefox and Chrome, but as you say, @makara, not in Word or Notepad. I don’t think this is related to the Chrome backspace issue. I need to investigate further and have documented this at https://github.com/keymanapp/keyman/issues/3704
I have now tested with an older version of Chromium (85.0.4183.0) and can verify that this issue only arises in the latest version of Chrome. It’s curious that the behaviour is the same in Firefox and Chrome – that is unexpected, especially since Firefox does not exhibit the backspace bug. I will need to open separate issues against Chromium and Firefox for investigation.
I have now opened issues against Chrome and Firefox with results of my investigation. It could be coincidence but it’s a weird coincidence if so! I am still pursuing further investigation on the Keyman end to understand what is going on and if there is anything we can do in Keyman to mitigate this.
The Chromium bugs are definitely related. Chrome team have investigated and found the change that caused the issue, and are planning to release a fix shortly. I will follow up on the root cause as there is potential for further improvements and interoperability with Chrome.
I have not yet progressed the Firefox issue (I am not technically at work this week…)
I have now confirmed that this issue is present in earlier versions of Firefox as well – it is not a regression and has not occurred recently. Apologies for any confusion. Starting to investigate in more detail today.
We are continuing to investigate the root causes of the issues with both browsers, so that the workaround will not be required in the future, but that’s a bigger job!