Can't change dictionnaries if JP text is in a textbox

[Lebon14]

Hi there.

On top of being extremely difficult to use rikaichamp in a text box (cursor moving along with selection, etc), you can't change dictionnaries with SHIFT if text is in a textbox. If you use Enter... well... you'll be doing an enter and whatever you had selected will inherently disappear.

Here's a random line of Japanese text to test on:
ジッと待ってるだけでは 悪い夢にうなされ

After I pasted that in, I hovered some kanjis in there and tried to cycle through the dictionnaries and it didn't work.

Of course, once that message is posted it'll work because it's not a text box. So, I'll encourage you to copy and paste the line above in teh reply text box to try it out.

Cheers.

[birtles]

Yeah, I made it ignore keystrokes when you're interacting with a textbox back in 65929bc since I got reports from people being unable to type:

See #4 (comment)

I'm not quite sure how to fix this without breaking the use cases in that comment.

The other issues you're seeing with textboxes should hopefully be addressed somewhat by #18 and #19. The next 2 weeks are busy for me but I should be able to get to those issues later in December at the latest.

[Lebon14]

In my case, I use rikaichamp to do some romaji-ing and sometimes, the main results don't fit what I hear. So, I want to change dictionnaries to see different readings.

Imo, the behavior could just be changed with an option:
In textboxes, allow Shift (or put shortcut here) to change dictionnaries: *Allow *Don't allow

Cheers and thanks for the hard work.

[slowmowfit]

I up this one. When I enter text in Japanese, I can't change the dictionnaries using enter or shift. I guess this is what he was talking about? Is there a possible fix for this?

Thank you.

[birtles]

I wonder if we can fix this without breaking the use cases in #4 by only ignoring keystrokes if the popup is for text that is in a different element. I'll have to try it and see.

[birtles]

This is really tricky as evidenced by the number of different issues relating to this (#2, #4, and this issue at least). As far as I can tell we have the following situations:

1. You are typing in a textbox and inadvertently the mouse hovers over some Japanese text somewhere, causing the popup to appear (even if you don't notice). In this case you want Rikaichamp to ignore the keypresses since they will interfere with typing. [Issue Ignore keyboard shortcuts while a textbox is in focus, even if the popup is for a different element #4]

2. You are typing in a textbox and deliberately focus on some text in that textbox (e.g. to check you used the word / kanji correctly). In that case you want Rikaichamp to respect any keypresses while the popup is showing (e.g. to switch dictionaries etc.) [This issue]

That would suggest we should just ignore keystrokes when a textbox is focussed and the popup is for a different element. Currently the changes introduced in 65929bc mean we do the exact opposite of this (ignore keystrokes when the popup is for the current textbox).

However, there is a third case:

3. You are typing in a textbox and deliberately hover the mouse over some other text in the page to look it up (e.g. replying to someone's message and you want to look up a word they used). In that case you do want Rikaichamp to listen to keypresses.

The tricky part is differentiating between (1) and (3), i.e. differentiating between a deliberate mouse move and an accidental one.

Perhaps something like the following would work:

• Introduce a flag typing mode.
• Whenever there is a mousemove event clear the typing mode flag.
• Whenever a textbox is focussed, set the typing mode flag.
• Whenever there is a keypress not handled by Rikaichamp AND a textbox is focussed, set the typing mode flag.
• Whenever there is a keypress that is handled by Rikaichamp, clear the typing mode flag.
• For users with the "hold to show popup" behavior configured, if the hold key is released without pressing another key clear the typing mode flag (probably not necessary?).

Then the heuristic would become:

• Is the popup showing? No → Ignore keypresses (except for in order to set typing mode)
• Is a textbox in focus? No → Listen to keypresses
• Is typing mode true? Yes → Ignore keypresses
• Otherwise → Listen to keypresses

It's not completely accurate though. It relies on the fact that if you accidentally bump the mouse and then continue typing, the next key you type is probably not going to be a Rikaichamp key. If you were unlucky enough to bump the key and then press, say, Shift then you'd find yourself interacting with Rikaichamp, but hopefully that's rare enough that it's acceptable.

[birtles]

If anyone has any comments about this, I'd love to hear them.

[emerencia]

This may or may not be related to this issue, but for me, the Rikaichamp pop-up does not work for any text that I typed in a textarea (= text input box). It does work for other text displayed on the same page that is not in textareas.

My most common use case is that I type something in a textarea on a web page, and then I want to hover over the kanji that I just typed to see the Rikaichamp popup with definitions and meanings. This used to work with Rikaikun, but I haven't been able to get Rikaichamp to show a popup for any text that is in a textarea. Am I doing something wrong?

I'm using it as a learning tool, e.g., I type some hiragana and want to see what possible kanji interpretations it has, or I write kanji to see different pronunciations or whatever, so just about 90% of my usage comes from me hovering over text that I just typed in textareas (text input boxes). Is there a way to make it work in Rikaichamp?

[birtles]

The popup should definitely show. Do you have a "Hold to show popup" key configured?

[birtles]

For my own notes, I am also coming across a situation where I have two text boxes and the mouse is hovering over one, but I am typing in the other. When I go to paste into the other text box, I press Ctrl+V but when I press Ctrl it triggers Rikaichamp's popup, which then highlights text in the other text box and focuses it, so that when I press V the content gets pasted in the wrong text box. I think the approach I suggested above might fix this too since presumably we will be in typing mode at that point.

[birtles]

I did some work on this and so far it seems to work well for me locally. However, now that it works, I notice that it would be really good if it recognized full-width input events.

e.g. You're typing in Japanese, highlight some text elsewhere in the page, and press the c button. Currently this won't be recognized since it will begin a composition where the key is "Process" (or "Undefined" in Chrome).

Instead I think we need to start listening for input events (and specifically only insertText and insertCompositionText when the inputType attribute is available -- Firefox 66+) and then read their data attributes and do full-width to half-width conversion.

[birtles]

This might need a few other tweaks too -- I notice that when using Shift+Tab to focus fields we don't clear the highlight.

[emerencia]

The popup should definitely show. Do you have a "Hold to show popup" key configured?

No, those modifiers are blank. And the popup is enabled, because it works when I hover other Japanese words on the page. I don't see any errors in the console, and I get the same behavior when I enable it to work in incognito mode and run the browser in incognito mode (which means it's the only extension running at that time), and then it still doesn't work in textareas/text inputs. This is on MacOs Mojave, Chrome v. 73.0.3683.56.

I just pulled the master branch to get the latest version of everything and ran the npm install and npm run build:chrome commands.

I made a small recording to illustrate the problem I'm having (Rikaichamp not working in textareas (nor in text inputs btw)), but it does work everywhere else as I show: https://streamable.com/n1yhc

[birtles]

Oh, you are using Chrome! Wow! I'm impressed! I have scarcely tested with Chrome at all.

Do you mind filing a separate issue for Chrome support? I haven't released Rikaichamp for Chrome yet but hope to in the future.

[emerencia]

Ok, I made #86.

[birtles]

This might need a few other tweaks too -- I notice that when using Shift+Tab to focus fields we don't clear the highlight.

This is hopefully fixed now.

I did some work on this and so far it seems to work well for me locally. However, now that it works, I notice that it would be really good if it recognized full-width input events.

I had a go at doing this in the handle-full-width-keys branch but I gave up. We don't know what key is being pressed until the input event but by then it appears to be too late to cancel the composition. There's probably a way but I haven't found it yet.

[birtles]

Hopefully this is now fixed in the just released 0.0.30.