[iOS] Web-based popup key issues

[jahorton]

Originally posted by @mcdurdin in #2968 (comment)

1. Khmer Angkor keyboard now shows two dotted circles on many long press options. This is mostly a display artefact that we don't necessarily need to resolve for this to go out.
2. Long press on spacebar on Khmer Angkor, selecting 2nd option (which itself is a little weird) leaves the spacebar in purple 'pressed' state.
3. The Globe icon flickers briefly on first touch but never shows a 'depressed' state which is depressing.
4. I managed to hang Keyman once by pressing the globe icon in-app but never reproduced this.
5. The look of the popups is not quite the same as the native popups.

   • preview letter is a little too high in the box:
     

   • first option in the popup is narrower than the others:
     

Apart from number 4, which I cannot reproduce, I don't think any of these are blockers. Given I can't repro, let's call it a glitch and ignore it for now.

Device: iPhone 11 Simulator, Version: 13.4

Note that these issues came about due to the workaround introduced in #2968 for an iOS 13.4 bug. Should we ever revert the workaround (once Apple fixes the underlying bug), these would go away. Said bug is FB7650067 on Apple's Feedback Assistant. I'd link it, but it seems like they keep the actual pages private between them and the submitter.

1. I cannot replicate this on the standard KMW test pages; it may be specific to iOS-embedded, or due to special handling rules for embedded popup keys that should be dropped when using 'native' (web-based) popup keys.

2. This can be reproduced in plain 'native' KMW on existing test pages. It's actually a Web bug, but this went undetected until now.

3. As best as I can tell, this is existing 'touch' OSK behavior for native-web. It's a loss of quality from what iOS had before, though.

[mcdurdin]

1. Khmer Angkor keyboard now shows two dotted circles on many long press options. This is mostly a display artefact that we don't necessarily need to resolve for this to go out.

This may be related to https://community.software.sil.org/t/keymanweb-keyboard-keycap-shows-u-0674-followed-by-dotted-circle/3247/5

[mcdurdin]

The U+25CC dotted circle issue arises because KeymanWeb tries too hard to display diacritics well. It seems that the width calculation for a text run is inconsistent across systems.

Example strings to test:

• Khmer: ត (U+17D2 U+178F). This works on Windows, Chrome, but displays wrongly in Safari (iOS). It may be that calculating text width in a canvas works differently than display the character standalone, or that Safari won't combine Khmer with U+25CC.
• Arabic: ٴ (U+0674). This adds an unwanted dotted circle on all platforms, per the community post above.

Reference code in visualKeyboard.ts:226:

      // Check the key's display width - does the key visualize well?
      var width: number = OSKKey.getTextWidth(osk, keyText, styleSpec);
      if(width == 0 && keyText != '' && keyText != '\xa0') {
        // Add the Unicode 'empty circle' as a base support for needy diacritics.
        keyText = '\u25cc' + keyText;

I'd like to see other examples of the dotted circle in use.

Given that this detail of adding U+25CC is specific to KeymanWeb, and does not happen on Windows, macOS or Linux, we should consider whether it is appropriate.

We may need to roll this change back, or nuance it further. My preference: roll the change back in 13.0.

[LornaSIL]

Are you aware that U+0674 is NOT a combining mark? It's a Lo (Letter Other).

[mcdurdin]

Are you aware that U+0674 is NOT a combining mark? It's a Lo (Letter Other).

Yes. The test in KMW does not have info on character classes. It simply measures the width of the text run and adds a dotted circle for zero width runs.

[jahorton]

Be sure to compare any changes against #1407, the original implementation for U+25CC use. (It was added for 11.0.)

[jahorton]

After the two PRs above are merged, I believe that all points (aside from point 4, the possible one-off) will have been addressed adequately.