Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In safari browser does not support Chinese input #221

Open
wallace-yang opened this issue Mar 5, 2024 · 15 comments
Open

In safari browser does not support Chinese input #221

wallace-yang opened this issue Mar 5, 2024 · 15 comments

Comments

@wallace-yang
Copy link

A number of exception bugs occur, such as exceptions for new columns and input results

@ocavue
Copy link
Collaborator

ocavue commented Mar 5, 2024

Please provide a minimal reproduction. Thanks.

@wallace-yang
Copy link
Author

@ocavue

2024-03-05.18.20.14.mov

you can check this vide.This problem also appears in the official example.thanks a lot.

@ocavue
Copy link
Collaborator

ocavue commented Mar 5, 2024

@wallace-yang Sorry I cannot reproduce myself. What's your environment (macOS version, Safari version, Chinese input method etc.)?

CleanShot.2024-03-06.at.10.30.04.mp4

@wallace-yang
Copy link
Author

wallace-yang commented Mar 6, 2024

@wallace-yang Sorry I cannot reproduce myself. What's your environment (macOS version, Safari version, Chinese input method etc.)?

CleanShot.2024-03-06.at.10.30.04.mp4
@ocavue Thanks for your reply,All the Safari version have this problem,Google Chrome for mac doesn't have this problem,I guess the problem is caused by the safari browser kernel.
About Chinese input method,I have tried several Chinese input methods, including mac default Chinese input method and third-party input method, and they all have this problem.This question I can confirm is related to the concept of "composition".Therefore, there is a high probability that Japanese, Korean, Arabic and other languages also have this problem.If you don't know how to use the mac's default Chinese input method, you can use this third-party input method, which is the most widely used in China(click me ).
This problem has been bothering me for half a year. Thank you very much for your reply. I have some solutions to share with you, but none of them have been successful because they conflict with the default behavior of prosemiror-tables. If you can help me with these conflicts, that would be also great.
I tried to add a non-removable <span>&ZeroWidthSpace;</span> to each "td" or "th" by the "decorations "; solves this problem, but raises another issue.Here is the code。

              allCellsArr.forEach(({ pos }, index) => {
                decorations.push(
                  Decoration.widget(pos + 1, () => {
                    const grip = document.createElement("span");
                    grip.style = "display: block;line-height:0px;";
                    grip.innerHTML = "&ZeroWidthSpace;";
                    return grip;
                  })
                );
              });

But it raises new questions like this:

2024-03-06.10.40.08.mov

Feishu(click me see example), the largest rich text editor product in China, uses this solution, and they disable the entry of any characters after selecting a table cell, so this problem does not arise.I would also like to disable input after cell selection, but disabling is not 100% effective.This is my code.

new Plugin({
        props: {
          handleDOMEvents: {
            keydown (view, event) {
              console.log("🚀 ~ keydown ~ event:", event);
              if (hadSelectedCell(view) && ((event.keyCode >= 65 && event.keyCode <= 90) || event.keyCode === 229)) {
                console.log("🚀 ~ keydown ~ hadSelectedCell,disable!!!!!!", event);
                event.preventDefault();
                return true;
              }
            }
          }
       }
})

The Chinese input method is sometimes disabled and sometimes invalid, but it is effective in the English state.The result like this:

2024-03-06.10.55.01.mov

If you want my device info, the following two pictures are my device information.
截屏2024-03-06 09 53 58
截屏2024-03-06 09 52 47

Expect your reply, thank you.

@ocavue
Copy link
Collaborator

ocavue commented Mar 16, 2024

CleanShot.2024-03-16.at.22.03.20.mp4

I can reproduce this bug. This bug only occurs inside an empty table cell.


After some debugging, I found that Safari produces different mutations in this line compared to Chrome and Firefox. When you type something with Chinese IME in an empty cell, Safari will first try to delete the whole <p> element with all the Pinyin letters, then add a new <p> element including the Chinese characters. However, the first <p> removal is invalid because prosemirror-tables requires every cell to have at least one block.

It seems that there is already some code in the prosemirror-view package that patches the table behavior in Safari (code link). Maybe it's possible to add some more code in the prosemirror-view to workaround this. However, I don't understand how to do that sadlly.

I did find another workaround during debugging. It seems that once I remove the position: relative; CSS rules, this issue doesn't occur anymore. Removing position: relative; will break the column-resize-handle so I cannot simply add this patch to prosemirror-tables.

@wallace-yang
Copy link
Author

CleanShot.2024-03-16.at.22.03.20.mp4
I can reproduce this bug. This bug only occurs inside an empty table cell.

After some debugging, I found that Safari produces different mutations in this line compared to Chrome and Firefox. When you type something with Chinese IME in an empty cell, Safari will first try to delete the whole <p> element with all the Pinyin letters, then add a new <p> element including the Chinese characters. However, the first <p> removal is invalid because prosemirror-tables requires every cell to have at least one block.

It seems that there is already some code in the prosemirror-view package that patches the table behavior in Safari (code link). Maybe it's possible to add some more code in the prosemirror-view to workaround this. However, I don't understand how to do that sadlly.

I did find another workaround during debugging. It seems that once I remove the position: relative; CSS rules, this issue doesn't occur anymore. Removing position: relative; will break the column-resize-handle so I cannot simply add this patch to prosemirror-tables.

@ocavue Thank you very much for your valuable information. If I have other solutions in the future, I will reply here.

@dragonman225
Copy link

dragonman225 commented Jun 1, 2024

@zunsthy
Copy link
Contributor

zunsthy commented Jun 3, 2024

I'm also troubled by this problem,

CleanShot.2024-03-16.at.22.03.20.mp4

I can reproduce this bug. This bug only occurs inside an empty table cell.

After some debugging, I found that Safari produces different mutations in this line compared to Chrome and Firefox. When you type something with Chinese IME in an empty cell, Safari will first try to delete the whole <p> element with all the Pinyin letters, then add a new <p> element including the Chinese characters. However, the first <p> removal is invalid because prosemirror-tables requires every cell to have at least one block.

It seems that there is already some code in the prosemirror-view package that patches the table behavior in Safari (code link). Maybe it's possible to add some more code in the prosemirror-view to workaround this. However, I don't understand how to do that sadlly.

I did find another workaround during debugging. It seems that once I remove the position: relative; CSS rules, this issue doesn't occur anymore. Removing position: relative; will break the column-resize-handle so I cannot simply add this patch to prosemirror-tables.

Resizing cell and IME inputing will not happen at the same time. If toggling position property value on compositionstart and compositionend events, can it work?

@wallace-yang
Copy link
Author

wallace-yang commented Jun 27, 2024

@ocavue Hi! I have resolve this issue😊
Support for Chinese, Japanese, and Korean IME in Safari browser. #232

@ocavue
Copy link
Collaborator

ocavue commented Jul 2, 2024

It seems that this Safari bug not only affect prosemirror-tables, so I created a standalone package prosemirror-safari-ime-span to address this issue. Could you try https://ocavue-fix-safari--prosemirror-tables.netlify.app/ and see if everything works fine?

@wallace-yang
Copy link
Author

It seems that this Safari bug not only affect prosemirror-tables, so I created a standalone package prosemirror-safari-ime-span to address this issue. Could you try https://ocavue-fix-safari--prosemirror-tables.netlify.app/ and see if everything works fine?

When I select a cell, move the mouse to an empty cell, and then input Chinese characters, a bug will occur.Some letters that should have been displayed are missing.

2024-07-05.17.46.01.mov

@ocavue
Copy link
Collaborator

ocavue commented Jul 18, 2024

Sorry for the late reply.

When I select a cell, move the mouse to an empty cell, and then input Chinese characters, a bug will occur.Some letters that should have been displayed are missing.

I'm unable to reproduce this with my Safari Version 17.5 (19618.2.12.11.6). What's your Safari version.

Although I cannot reproduce, I pushed a patch that reduces the state update when the IME is enabled or disabled. Could you try https://ocavue-fix-safari--prosemirror-tables.netlify.app/ again and see if this issue still occurs?

@wallace-yang
Copy link
Author

this issue still occurs

This issue still occurs,However, bugs occur randomly, not necessarily every time, with a probability of about 30%.

2024-07-19.16.46.32.mov

my Safari Version 17.4 (19618.1.15.11.12)

@ocavue
Copy link
Collaborator

ocavue commented Jul 19, 2024

Could you check if you can reproduce this bug using Safari Technology Preview v18.0+?

I cannot reproduce after many tries using Safari Version 17.5 and Safari Technology Preview 18.0, so I suspect that it's a bug in 17.4 that has been fixed.

@wallace-yang
Copy link
Author

Could you check if you can reproduce this bug using Safari Technology Preview v18.0+?

I cannot reproduce after many tries using Safari Version 17.5 and Safari Technology Preview 18.0, so I suspect that it's a bug in 17.4 that has been fixed.

I have already downloaded and used Safari Technology Preview, but the issue still persists. Additionally, the problem occurs even when the target cell is not empty. Here are my Safari Technology Preview and device information.

image 截屏2024-07-23 11 12 49
2024-07-23.11.08.47.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants