Hi @jonghoonleeee

There's one solution that might help here. Can you please try to set the option imeFastEdit: true in your configuration object?

from handsontable.

Thank you for feedback @jonghoonleeee I have reported the issue internally and will notify as soon as we fix it.

from handsontable.

Hi @youhogeon

Thank you for the additional details. Our developers will investigate it, and I'll update you once we have feedback from them.

from handsontable.

This (obviously) also happens in the official examples on the handsontable main page.

Also, I am attaching a jsfiddle link for the example used in the video above.

• 14.3.0 false : https://jsfiddle.net/rmd3pwyf/
• 14.3.0 true : https://jsfiddle.net/f30uLy27/1/
• 14.4.0 false : https://jsfiddle.net/teouyhrq/1/
• 14.4.0 true https://jsfiddle.net/aqntrc68/3/

(For reference, no problems occurred in version 13. (even if the imeFastEdit option is false))

I will also try to find the code that causes this phenomenon to occur.
Once I solve the problem, I will leave the solution here for the benefit of countless Koreans, Chinesses, and Japanesenesses.

from handsontable.

Hi @adrianszymanski89

Just to let you know a similar issue with Korean keyboard layout.
Typing "가나다" results in "ㄱㅏ나다" so the first letter does not change in Engilsh but the first letter is not composed with the latter one which is a bug.
imeFastEdit: true fixes the issue in this case.

Using MacOS + Chrome + Handsontable v14.1.0

from handsontable.

Hi @HJeong1200

Thank you for letting me know. This option was added to solve this problem, so I'm glad it works as intended.

from handsontable.

I will also try to find the code that causes this phenomenon to occur.
Once I solve the problem, I will leave the solution here for the benefit of countless Koreans, Chinesses, and Japanesenesses.

Thank you so much, @youhogeon

We will also retest that internally.

from handsontable.

@AMBudnik

I set a keydown event on the textarea in textEditor (this.TEXTAREA) and container (passed as the first argument to the Handsontable constructor)
and checked the order in which the code is executed.

When entering << ㄱ - enter - ㄱ - enter - ㄱ - enter - ... >> within the table, the code was executed in the following order.

(Cell is selected)
-> Editor's prepare method is called
-> (Press ㄱ key)
-> TEXTAREA's keydown(key code: ㄱ) event occurs
-> Container's keydown event occurs
-> Editor's focus method is called
-> (Press the enter key)
-> The keydown (key code: enter) event of the TEXTAREA occurs
-> The keydown event of the container occurs
-> The row below is selected and the editor's prepare method is called.

However, due to a bug, it was confirmed that when r is entered instead of ㄱ, the keydown event does not occur in the textarea, but only the keydown event in the container occurs.

(Cell is selected)
-> Editor's prepare method is called
-> (Press ㄱ key)
-> TEXTAREA's keydown(key code: ㄱ) event NOT occurs
-> Container's keydown event occurs
-> Editor's focus method is called
-> (Press the enter key)
-> The keydown (key code: enter) event of the TEXTAREA occurs
-> The keydown event of the container occurs
-> The row below is selected and the editor's prepare method is called.

I decided that this was because the textarea was not prepared correctly, so it did not receive the keydown event.
I solved it by adding this.TEXTAREA.select() in the prepare method of textEditor (above this.refreshDimension(true)).

...
if (!cellProperties.readOnly) {
  this.TEXTAREA.select() // <- here
  this.refreshDimensions(true); 

  ...
}

Then with imeFastEdit set to true, the bug no longer reoccurred. (It is not 100% resolved. However, there is a very, very small chance that a bug will occur.)
However, there are also limitations.

1. Even if imeFastEdit is false, the problem is solved to some extent, but alphabets are still entered intermittently.
2. When imeFastEdit is false, if you select a cell with the mouse and then try to input, the first letter is “always” entered as an alphabet.
3. I am not convinced that selecting the textarea in the prepare method is likely to cause other side effects.
4. Accessibility (reader for the visually impaired) problems may occur when selecting the textarea during preparation.

(To. users who want to use my solution)
My temporary solution is
I think it's almost a similar solution to removing debounce from refocusToEditorTextarea in focusManager.js.
It may also be necessary to check whether performance problems may occur if this debounce is completely removed.

from handsontable.

Thank you for sharing the research, @huangshuwei
I really appreciate it. We do not often see such a great effort to describe a case.

We will keep the issue open and update as soon as possible.

from handsontable.

@retrop5 Does this really work? I just installed the Japanese IME (provided by Windows) and tested it, but the "first letter bug" still exists.

https://jsfiddle.net/4260nzwd/ (standard settings (only colHeaders and rowHeaders are on))

My testing procedure

1. Select one cell with the mouse. (Be careful not to double-click to enter editing mode. Proceed without the cursor blinking.)
2. Check if the Japanese IME is in hiragana mode
3. Enter aaaa
4. (Result) aあああ is entered.

Please let me know if my testing method is wrong.

I'm not sure why it worked normally in @retrop5 and @AMBudnik's tests. (This is most likely due to my lack of understanding of Japanese.)

Additionally, Same goes for Simplified Chinese IME.

1. Click a cell and enter nihao
2. Only ihao is visible in IME hint

or

1. Click a cell and enter nnihao (two n)
2. nihao appears in the IME hint, select 你好
3. n你好 (of the two n, the first n remains the same) is entered in handsontable.

This is the same even if you test it using Edge rather than Chrome.
So I thought my local environment might be the problem.

To test in a new, completely independent environment, an AWS EC2 (virtual server) instance was created and tested within it.

However, they all have the same problem as above. (Very sadly...)

from handsontable.

Hi guys, I am sorry It took so long to reply back, I was surprised when @youhogeon commented about the issue persisting, so I went ahead and tested it again, looks like the issue still persists, I'm sorry for the incorrect update. Please have a look at this sample video I created.

When imeFastEdit is not set

NOTE:

1. At 00:09 I have refreshed the page to show that specific case as well.

Code:

$(function(){
    const hot = new Handsontable(document.getElementById('targetItem'), {
        licenseKey: 'non-commercial-and-evaluation',
        data: [
            {KEY:1, NAME:'テスト1', VALUE:'1'},
            {KEY:2, NAME:'テスト2', VALUE:'2'},
            {KEY:3, NAME:'テスト3', VALUE:'3'},
            {KEY:4, NAME:'テスト4', VALUE:'4'},
            {KEY:5, NAME:'テスト5', VALUE:'5'},
        ],
        height: $(window).height() - 230,
        manualRowResize: true,
        rowHeaders: true,
        fillHandle: false,
        hiddenColumns: {columns: [0]},
        filters: true,
        comments: {displayDelay: 500,},
        dropdownMenu: ['filter_by_condition', 'filter_by_value', 'filter_action_bar'],
        columns: [
            {data:'KEY', title:'', width:50, readOnly:true},
            {data:'NAME', title:'名前', width:300},
            {data:'VALUE', title:'値', width:100},
        ],
    });
});

When imeFastEdit is set to true

NOTE:

1. At 00:11 I have refreshed the page to show that specific case as well.

Code:

$(function(){
    const hot = new Handsontable(document.getElementById('targetItem'), {
        licenseKey: 'non-commercial-and-evaluation',
        data: [
            {KEY:1, NAME:'テスト1', VALUE:'1'},
            {KEY:2, NAME:'テスト2', VALUE:'2'},
            {KEY:3, NAME:'テスト3', VALUE:'3'},
            {KEY:4, NAME:'テスト4', VALUE:'4'},
            {KEY:5, NAME:'テスト5', VALUE:'5'},
        ],
        height: $(window).height() - 230,
        manualRowResize: true,
        rowHeaders: true,
        fillHandle: false,
        hiddenColumns: {columns: [0]},
        filters: true,
        comments: {displayDelay: 500,},
        dropdownMenu: ['filter_by_condition', 'filter_by_value', 'filter_action_bar'],
        columns: [
            {data:'KEY', title:'', width:50, readOnly:true},
            {data:'NAME', title:'名前', width:300},
            {data:'VALUE', title:'値', width:100},
        ],
        imeFastEdit: true,
    });
});

Version:

@AMBudnik would this be of any help?

from handsontable.

Hi @jonghoonleeee

Thank you for reporting this. Can you please tell me which Japanese dialect you use? I was able to reproduce the issue with Hiragana-Romaji on macOS.

from handsontable.

Hi @adrianszymanski89
Thank you for reproducing it. I am using the same one.

from handsontable.

@HJeong1200 @adrianszymanski89
Thank you for informing me.

When I added the imeFastEdit: true option in the Handsontable documentation, it worked correctly. However, after adding the contextMenu option, it did not work.

It seems that using both contextMenu and imeFastEdit options simultaneously does not work.

from handsontable.

Hi @jonghoonleeee

Thank you for the update. I tried with a custom context menu, but it still works correctly in my case. I tested it with this example: https://jsfiddle.net/handsoncode/nt68ejhq/. Can you please check if it doesn't work for you also here?

from handsontable.

Hi @adrianszymanski89

Thank you for trying.

I tried adding a context menu on the following page, but it seems not to be working. What could be the difference?
example: https://jsfiddle.net/1fvd2seu/6/

from handsontable.

Hi @jonghoonleeee I also tried to replicate the issue with Japanese-romanji keyboard and did not get this issue.

I was testing Chrome 121 and Firefox 121 on macOS Ventura, before and after using the context menu it still works the same. In my case, I was adding konnichiwa and got this (as I am not 100% sure if that is correct as I do not know Japanese we can see that the first letter is not from another alphabet).

So it seems that we should focus on the differences between our environments, or maybe the speed of typing.

from handsontable.

Hi @AMBudnik
Thank you for trying.

Have you tried inputting Japanese text on this page(https://jsfiddle.net/1fvd2seu/6/)?
I attempted it on Chrome 121, Edge, Safari, and Mac OS Ventura 13, but noticed that the initial characters of Japanese text were automatically converted to Roman characters.

When double-clicking on a cell, the issue does not occur. However, it happens when moving to a cell with a single click or keyboard arrow input

from handsontable.

I was able to replicate the issue, but only if I switched to Japanese after the table was loaded. Please check this video.

1st attempt is in my standard keyboard (for me it's polish)
2nd one (where the issue is replicable) is switching to Janapese-Romanji without refreshing the page
3rd one is Janapese-Romanji but with a new refresh of the page (the result is correct).

Does that work for you the same? Or does it also happen when you have Janapese-Romanji and after page refresh?

from handsontable.

@AMBudnik
Thank you for trying.

The issue occurs only in Japanese-Romanji. It inputs correctly when refreshing the page, but the problem occurs again afterward.

• Upon refreshing the page

• After refreshing the page
  

from handsontable.

@HJeong1200 @adrianszymanski89 Thank you for informing me.

When I added the imeFastEdit: true option in the Handsontable documentation, it worked correctly. However, after adding the contextMenu option, it did not work.

It seems that using both contextMenu and imeFastEdit options simultaneously does not work.

Chinese input also has the same problem：

But it works in version 13.1. I think it should be related to the update on 14.1

from handsontable.

Hi @huangshuwei

Recently, we released a new version of Handsontable, 14.2, and when I checked this issue, I couldn't replicate it anymore. Can you please tell me if that's also the case on your side with 14.2?

from handsontable.

@adrianszymanski89
Yes, this issue also exists in version 14.2 .
This is an example of version 14.2:https://jsfiddle.net/d1ur2yne/

from handsontable.

@huangshuwei

Thank you for the update. I hope we will have a fix for this soon.

from handsontable.

Hi. I have found that upgrading to the latest version(14.3.0) still has this problem. Is there a repair plan for it?

from handsontable.

@adrianszymanski89

I haven't tested other languages, but I'll tell you based on Korean input.

First of all, this problem occurs from 14.0 to 14.3. (It operates normally in 13.x.)

※ Note: In Korean, the letter “가” can be entered by entering “ㄱ” and then “ㅏ”.

If imeFastEdit is false, "rㅏ" is always entered. (However, if you double-click the cell and then type, it will be entered normally.)

If imeFastEdit is true and you type slowly, "가" is entered normally.
However, when typing quickly, “rㅏ” is entered or “ㅏ” is entered (“r” is entered first, then “r” suddenly disappears, leaving only “ㅏ”).

I sincerely hope that this issue is resolved quickly. If I find any problematic code, I will submit a Pull Request. (But I'm not confident I can find it.)

from handsontable.

Hi @huangshuwei @jonghoonleeee @youhogeon @HJeong1200 We did some improvements in v14.4.0 here #10947.

Could you please update to v14.4.0 and let us know if the issue is still replicable?

from handsontable.

@AMBudnik

First, we sincerely thank you for your interest in this issue and your efforts to resolve it.
The results of my testing are below.

When imeFastEdit is false (default)
The first letter is still “always” alphabet.
(However, if you press F2 or Enter to "open" the editor and then enter it, the input will be entered normally.)

When imeFastEdit is true
It has improved greatly compared to 14.3.0.
However, it is still often typed alphabet (especially when you finish typing and move on to the next line quickly).

(Similarly, if you press F2 or Enter to "open" the editor and then type, the input will be entered normally.)

I am attaching a video that reproduces the situation.
In the left column, <<ㄱ - enter - ㄴ - enter - ㄷ - enter ...>> is entered,
The right column is entered after pressing enter twice to open the editor, such as <<ㄱ - enter - enter(to open editor) - ㄴ - enter - enter - ㄷ - enter - enter - ...>>.

[summary]

• When you press enter twice, it operates abnormally regardless of the imeFastEdit value and version (14.3.0 and 14.4.0). (It is Korean ime, but alphabets are entered)
• Both 14.3.0 and 14.4.0 behave abnormally when imeFastEdit is false.
• 14.4.0 is slightly better than 14.3.0 when imeFastEdit is true, but still occasionally behaves abnormally

from handsontable.

Hi @huangshuwei @jonghoonleeee @youhogeon @HJeong1200 We did some improvements in v14.4.0 here #10947.

Could you please update to v14.4.0 and let us know if the issue is still replicable?

@AMBudnik Thank you for your efforts. Everything has been working since I switched to version 14.4 .

Here is the demo effect of Chinese input:
https://github.com/handsontable/handsontable/assets/6047141/b83f1956-e13f-4087-81af-d03cc6ba83ff

from handsontable.

Hi, I have been waiting for an update on this issue for a while.
Since @huangshuwei mentioned his issue being resolved in 14.4 I tested it out again (Japanese Language) on my local env.
Unfortunately, for Japanese the issue still persists.

Here is a recording for it,

Here is the table configuration,

hot = new Handsontable(container, {
	licenseKey: 'non-commercial-and-evaluation',
	data: data,
          language: 'ja-JP',
	manualRowResize: true,
	rowHeaders: true,
	rowHeights: 50,
	className: 'htMiddle',
	renderer: detailRenderer,
	fillHandle: false,
	preventScrolling: false,
	hiddenColumns: {columns: [0,9,10,11,12, 13, 14, 15, 16, 17, 18, 20, 21]},
	filters: true,
	dropdownMenu: ['filter_by_condition', 'filter_by_value', 'filter_action_bar'],
	columns: [	
		//redacted data
	],
          manualColumnResize: true,
          manualRowResize: true,
          renderAllRows:true,
          stretchH: 'all',
	afterChange: getChangedRows,
	afterGetRowHeader: function(col, TH) {
		TH.className = 'htMiddle'
	},
	cells: function (row, col) {
		var cellProperties = {};
		cellProperties.renderer = detailRenderer;
		return cellProperties;
	}
});

My handsontable version,

 * Version: 14.4.0
 * Release date: 11/06/2024 (built at 06/06/2024 10:09:45)

from handsontable.

Thank you for the feedback @retrop5

We tested it in many ways and struggled to find the case of the issue. We have one Client (not in this thread) confirming that the issue is solved for Japanese. They tested it on standard settings (only colHeaders and rowHeaders are on). Are you able to replicate the same issue having only those settings as well?

from handsontable.

Hi @AMBudnik I tested it on standard settings and it works fine, but since it doesn't work for the setting I have shown above, let me see where it is causing an issue (assuming that my custom renderer is playing priority games). However, I will test it in detail and let you know my results over the weekend, hope that's fine.

from handsontable.