[BUG] Plugin not working on Samsung tablets after upgrading to OneUI 5.1.1

[lukks22]

Description

Since the upgrade, me and (at least) another user can't use the shortcuts anymore, not even mk, dm or any custom ones.

Expected Behavior

Shortcuts should have effect

Additional Info

None

Platform

Samsung tablets (found on Samsung Galaxy S7 FE and Galaxy Tab S6 Lite) with One UI 5.1.1

Before the update the shortcuts would not work when using the "virtual" keyboard, but would work with a bluetooth one. After the update not even that. The same project on Windows works fine.

[albert-jermyn]

I have the same problem, Samsung Galaxy S7 FE with One UI 5.1.1. I noticed that some of the snippets still work in math mode. For example, the "/" after a character activates the "\frac{}{}" snippet.

[artisticat1]

Can you try out the build in #191 and check whether the plugin works again?

[albert-jermyn]

Now on my Galaxy S7 FE the plugin works only with the physical keyboard and text prediction disabled. I tried Samsung, Gboard and AnySoft.

[lukks22]

Can you try out the build in #191 and check whether the plugin works again?

I'm not very familiar with GitHub, if you could tell me how I'd be more than happy to

[albert-jermyn]

Can you try out the build in #191 and check whether the plugin works again?

I'm not very familiar with GitHub, if you could tell me how I'd be more than happy to

Just update the plugin in obsidian and check if it works for you.

[artisticat1]

I'm not very familiar with GitHub, if you could tell me how I'd be more than happy to

Of course. Download the main.js file from https://github.com/oldkingOK/obsidian-latex-suite/releases/tag/v0.0.4 (which corresponds to the fix in #191 by @oldkingOK).

Then replace path-to-vault/.obsidian/plugins/obsidian-latex-suite/main.js with the new main.js.

Just update the plugin in obsidian and check if it works for you.

The fix in #191 actually hasn't been released as an update yet, so if you could follow the steps above and report back that'd be great!

[lukks22]

Sorry man, still not working. Some snippets work just fine (a/b for frac, << for /ll) but not mk, dm or any other.

I've tried both on the physical keyboard and the system's one

[oldkingOK]

Hi @lukks22 . I don't have any Samsung machines around, so it would be helpful if you could describe the situation in more detail.

• What keyboard app are you using?
• Is the composition mode off? (when on, words are underlined during spelling). You can view how to turn off it for some keyboards here.

[lukks22]

Hi @lukks22 . I don't have any Samsung machines around, so it would be helpful if you could describe the situation in more detail.

• What keyboard app are you using?
• Is the composition mode off? (when on, words are underlined during spelling). You can view how to turn off it for some keyboards here.

Hi, I'm using the default keyboard.

I have tried turning it off and it works both on the physical and the native one.

[albert-jermyn]

The fix in #191 actually hasn't been released as an update yet, so if you could follow the steps above and report back that'd be great!

Oh sorry, I saw an update and I thought that was the fix. I just tested with the new main.js file and the result is pretty much the same, except that now I can leave text prediction on.

Only the physical keyboard works.

[albert-jermyn]

Oh sorry, I saw an update and I thought that was the fix. I just tested with the new main.js file and the result is pretty much the same, except that now I can leave text prediction on.

Only the physical keyboard works.

My bad, the on-screen samsung keyboard works too, I was testing the snippets with the automatic initial upper case😅

The on-screen keyboard doesn't work with text prediction on but the physical one does.

[oldkingOK]

The on-screen keyboard doesn't work with text prediction on but the physical one does.

I'm having trouble dealing with the text prediction function.

1. Pressing TAB during spelling has a high probability of causing the cursor to lose focus.
2. The spelling process is such that some keyboard apps' spells don't call Keydown Event, and other apps, even if they do, get Unidentified using event.key. (Gboard and Codeboard are able to detect keys, but there are too many other input methods that can't do it)

I haven't found a solution for the first problem yet, for the second problem the solution I use is to listen for input event, which is called for every keyboard apps, for every key pressed from A to Z or symbols.

For most keyboard apps, when event.inputType is insertCompositionText, it means that the keyboard app is doing text prediction, and when the event.inputType is insertText, it means that the app is only inputting single letters or symbols without text prediction enabled. (ref: Input Events Level 1 (rawgit.com))

All keyboard apps tested so far work fine with text prediction mode turned off. However, the problem is complicated by the fact that each app processes text differently when the mode is activated.

• Sogou keyboard and Gboard: Every time you move the cursor, the app will automatically enter the text prediction and call input event and event.inputType is insertCompositionText. This means that even if you just click on the word "mk" in the document with your hand or mouse, the app will enter text prediction mode and call a input event, making Obsidian think that the user has typed mk then this plugin converted it to $$.

• Anysoft: Moving the cursor does not put the app into text prediction mode, only typing new characters does.

• MS SwiftKey: Unlike most other input methods, the event.inputType of input event called after each key press during text prediction is not insertCompositionText, but insertText. That's why it works fine even the mode is activated.

I tried to use input event's event.data to get the characters typed by the user and give them to LatexSuite to handleKeydown, but for the reasons mentioned above, the difference in the keyboard apps caused the plugin to be able to work properly, so I gave up on processing the text prediction function for the time being.

Any help is welcome!

[artisticat1]

Hi @oldkingOK. Thank you for the detailed analysis!

I'm not as familiar with IME input as you, but as far as I'm aware, the vim CM6 plugin does not run into any of these issues with IME input. (At least, there have been no user reports of problems as far as I can tell.)

It appears to work with KeyboardEvents like Latex Suite does. Is there a difference between the vim CM6 plugin and Latex Suite that means we cannot use the same IME input handling/workarounds as them?

[SullivanNagler]

hello !

i have a similar issue on a nothing phone (1). The plugin with a bluetooth keyboard works perfect but without, only snippets with numbers init works.

I wish this info help someone :)

[oldkingOK]

Hi @artisticat1. Sorry for the late reply.

the vim CM6 plugin does not run into any of these issues with IME input. (At least, there have been no user reports of problems as far as I can tell.)

This plugin does deal with the IME issue, and I used your suggestion in a previous version, but this solution causes the user to not be able to use the word prediction feature of the keyboard.

Maybe a good solution would be to give the user a floating button or hotkey shortcut to quickly switch between "Latex Suite Mode" and "Text Input Mode"?

In that case there's no way to remove the Platform.isAndroidApp check, because this feature can only be used for Android.

It appears to work with KeyboardEvents like Latex Suite does. Is there a difference between the vim CM6 plugin and Latex Suite that means we cannot use the same IME input handling/workarounds as them?

vim CM6 plugin also detects the Unidentified key. (Code Reference)

if (
    this.lastKeydown == "Unidentified"
    || this.lastKeydown == "Process"
    || this.lastKeydown == "Dead"
  ) {
    this.useNextTextInput = true;
  } else {
    this.useNextTextInput = false;
    this.handleKey(e, view);
  }

When Unidentified is detected, the inputHandler is told to handle it. (Code Reference)

EditorView.inputHandler.of((view, from, to, text) => {
...
	if (text.length == 1 && vimPlugin.useNextTextInput) {
	    vimPlugin.handleKey({
	      key: text,
	      preventDefault: ()=>{},
	      stopPropagation: ()=>{}
	    });
	    forceEndComposition(view); // Here
	    return true;
	}
...
}

The forceEndComposition(view) function refreshes the page, forcing the IME to be disabled and causing word prediction to be disabled.

Obsidian's app.js code handles IMEs similarly, with the function in the following code corresponding to forceEndComposition(view)

function (e) {
    var t = e.scrollDOM.parentElement;
    if (!t) return;
    if (UT) return e.contentDOM.textContent = "\0\0", void e.contentDOM.dispatchEvent(new CustomEvent("compositionend"));
    var n = e.scrollDOM.nextSibling,
        i = window.getSelection(),
        r = i && {
            anchorNode: i.anchorNode,
            anchorOffset: i.anchorOffset,
            focusNode: i.focusNode,
            focusOffset: i.focusOffset
        };
    e.scrollDOM.remove(), t.insertBefore(e.scrollDOM, n);
    try {
        r && i && (i.setPosition(r.anchorNode, r.anchorOffset), r.focusNode && i.extend(r.focusNode, r.focusOffset))
    } catch (e) {
        console.error(e)
    }
    e.focus(), e.contentDOM.dispatchEvent(new CustomEvent("compositionend"))
}(e)

[artisticat1]

No worries, I appreciate your help!

This plugin does deal with the IME issue, and I used https://github.com/artisticat1/obsidian-latex-suite/issues/52#issuecomment-1721897513 in a https://github.com/artisticat1/obsidian-latex-suite/issues/52#issuecomment-1722239752, but this solution causes the user to not be able to use the word prediction feature of the keyboard. Maybe a good solution would be to give the user a floating button or hotkey shortcut to quickly switch between "Latex Suite Mode" and "Text Input Mode"?

I see. That might work, but toggling between modes would make for a frustrating UX, so I'd prefer to fix the root cause of the issue. (Ideally, we find a solution where word prediction/suggestions work properly out of the box.)

Using an InputHandler indeed appears to be the best way to capture user input on Android. You mention that

The forceEndComposition(view) function refreshes the page, forcing the IME to be disabled and causing word prediction to be disabled.

However, word suggestions seem to work fine with vim mode enabled on Android. Thus, it's not obvious to me why there would be issues with word suggestions and Latex Suite?

[RyotaUshio]

Just a random thought from a non-experienced dev who doesn't have an Android device, but it might be worth trying to use transactionFilter instead of domEventHandlers.

Here's an example from my plugin:

https://github.com/RyotaUshio/obsidian-inline-math/blob/8cf5384d4ee35963eaa56a429983ca9e7a5ba0f8/src/transaction-filter.ts#L15-L25

See here for userEvent.