1576620 - The last word is ignored on Twitter with Korean IME

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

0. Get a Korean IME on Windows 10
1. Access https://mobile.twitter.com
2. Tap Tweet button and type '테스트' ("xptmxm" in QWERTY)
3. Tap Control+Enter to post it (and make sure the composition is not finished yet)
4. Expected to post it successfully, instead it says "not allowed to perform this action" (See comment #13)
5. Remove everything and type '테스트 파이어' ("xptmxm vkdldj" in QWERTY. Again make sure the composition is not finished yet)
6. Tap Control+Enter to post it
7. Expected "테스트 파이어" (two words) but instead the result becomes "테스트"

This also can be seen on Chrome on Windows, but said to be non-reproducible on Safari on macOS.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Expected to post it successfully, instead it says "not allowed to perform this action"

Does twitter show the message? Or Korean IME?

This also can be seen on Chrome on Windows, but said to be non-reproducible on Safari on macOS.

Sounds like a bug of twitter... When Ctrl + Enter is pressed during composition, it causes keydown events for Control and Enter, but the latter is marked as "processed" (this is expected behavior). Then, Korean IME generates keydown event for Enter key again with Control modifier flag after compositionend. This is not expected behavior in strict speaking, but must be better hack.

If you meant that you used control + Enter on macOS, Firefox dispatches same events as Windows. If you meant, command + Enter, Firefox does not dispatch the hacky Enter keydown event. The behavior of Safari for macOS cannot be a reference behavior for us since IME behaves differently between Safari and Firefox/Chrome.

Do you reproduce this bug with Firefox on macOS too?

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Does twitter show the message? Or Korean IME?

Twitter does. I think it somehow ignores the word whose composition is still happening, so it tries posting a tweet with an empty string and then errors.

I meant I used Ctrl+Enter on Windows. I have no macOS device so I had to ask others to try reproducing this, and they said Chrome on macOS "intermittently" can reproduce this while Chrome on Windows can do with 100% probability.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

(That means I have no idea whether Firefox on macOS can see this problem or not)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I'll inform twitter folks about this.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

...did that ^

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

And Twitter is looking into this.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them)]

Is Twitter still looking into this? I can still reproduce this on the latest Nightly.

Comment 8

[Mike Taylor [:miketaylr]]

Kagami, doe this reproduce on the draftJS homepage as well? https://draftjs.org/

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

The draftjs demo has no Twitter-like submit button so I can't test there. The input itself is visually okay and it correctly appears on DOM tree, but somehow Twitter fails to catch the last word when submitting.

I guess it uses a separate API to retrieve the content (probably getText()) but not sure how I can access it on the demo page.

Comment 10

[Mike Taylor [:miketaylr]]

OK, thanks.

Tom, since you're gonna look at the other Twitter Korean issues, can you take this as well?

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

editorState does not update until the composition ends, which probably is the cause here. https://jsfiddle.net/saschanaz/nsqkmuxg/

This doesn't happen on Facebook though, which implies Twitter depends on a wrong object.

Comment 12

[Oana Arbuzov [:oanaarbuzov]]

I can't reproduce the issue on my side. I did not receive any errors when tweeting both posts and all the typed words are displayed.
https://prnt.sc/10navxm
https://prnt.sc/10naxfp

Tested with:
Browser / Version: Firefox Nightly 88.0a1 (2021-03-14), Chrome 89.0.4389.82
Operating System: Windows 10 Pro

Kagami can you still reproduce it?

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

The behavior is slightly changed from Twitter; for step 3 it now just silently completes the composition without any error, and for step 6 it still reproduces here. This is still a widely known issue among Korean users, so reopening...

Comment 14

[Karl Dubost💡 :karlcow]

Needs Triage.

Comment 15

[Raul Bucata]

We appreciate your report. I was not able to reproduce the issue:
https://prnt.sc/1epnxrf

I was also not able to reproduce the issue whilst commenting on posts

Tested with:

Browser / Version: Firefox Nightly 92.0a1 (2021-07-22) (64-bit)
Operating System: Windows 10 PRO x64

Suggestion: Try clearing cache/data/cookies, disable addons and Ad-blocker (if available), or use a clean profile, and check again? If there are any changes made to the default settings of the browser (e.g. in about: config) please revert to the default settings and try again. Also, have the required cookies been accepted for this page? Also, is the issue reproducible on your side using the latest build of Firefox Nightly?

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

I can still reproduce this on a mozilla-central 2021-07-23 build downloaded via mozregression. Please see also comment #13, and I'll edit comment #0 to reflect that.

Comment 17

[Raul Bucata]

Do you happen to have any addons/extensions installed ? Or perhaps for the IME keyboard, you have used something different than using the option presented by Windows?

Comment 18

[Kagami Rosylight [:saschanaz] (they/them)]

No, as mozregression does not bundle such thing but just provides a newly created profile by default. The IME is the default one provided by Windows 10 when you add Korean language. I can provide a video screenshot if that helps.

Comment 19

[Raul Bucata]

That would help. Also, a screen recording including steps to reproduce might also be very helpful, if that is possible

Comment 20

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: test.mp4

Okay, here it is. The steps are same:

1. Get a Korean IME on Windows 10
2. Access https://twitter.com
3. Remove everything and type '테스트 테스트' ("xptmxm xptmxm" in QWERTY. Make sure the composition is not finished yet)
4. Tap Control+Enter to post it
5. Expected "테스트 테스트" (two words) but instead the result becomes "테스트"

This also happens on Windows 11, FWIW. I think we probably need to toy with draftjs api to debug this.

Comment 21

[Raul Bucata]

I am still unable to reproduce the issue.

Karl, anything we can do here? This issue seems very familiar, but I am still unable to reproduce the issue

Tested with:

Browser / Version: Firefox Nightly 93.0a1 (2021-09-03) (64-bit)
Operating System: Windows 10 PRO x64

Comment 22

[Karl Dubost💡 :karlcow]

raul when you type the last character before doing control+enter, is it still selected in blue (like in the video) aka the composition is not finished.

If yes, I wonder what is different in between your two systems.

Comment 23

[Kagami Rosylight [:saschanaz] (they/them)]

That must be true per the steps in comment #0 and comment #20.

Comment 24

[Karl Dubost💡 :karlcow]

Oh and I had missed that comment #0.

This also can be seen on Chrome on Windows, but said to be non-reproducible on Safari on macOS.

This is not a webcompat issue in between Chrome and Firefox
but in between Safari on one side and Chrome/Firefox on the other side.

Now we need to figure out

• if it's a bug in Safari which makes it work?
• or a different code path in the js?
• or a bug in both firefox/chrome?
• or a race issue?

Comment 25

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Karl Dubost💡 :karlcow from comment #24)

Now we need to figure out

• if it's a bug in Safari which makes it work?
• or a different code path in the js?
• or a bug in both firefox/chrome?
• or a race issue?

Probably also need to check whether it is reproducible on Firefox on macOS since this could also be something with native IME behavior.

Comment 26

[Raul Bucata]

I am still unable to reproduce it using all the stated browsers. For me, the last word is not in composition, but rather underlined. Pressing CTRL + Enter does nothing. Pressing CMD+Enter triggers a loading spinning circle that is stuck in a loading state across all browsers when an KOREAN IME input is used

Tested with:

Browser / Version: Firefox Nightly 94.0a1 (2021-09-30) (64-bit)/ Chrome Version 93.0.4577.82 (Official Build) (64-bit)/ Safari 10.15.6
Operating System: Mac OSX 10.15.6

Comment 27

[Kagami Rosylight [:saschanaz] (they/them)]

I guess it's not a problem on macOS in that case, probably because of IME behavior difference.

Pressing CMD+Enter triggers a loading spinning circle that is stuck in a loading state across all browsers when an KOREAN IME input is used

That sounds like another type of unexpected behavior 👀 (which should probably be fixed from Twitter side)

Comment 28

[Kagami Rosylight [:saschanaz] (they/them)]

Continuing from comment #9, it turns out it's DraftJS's getPlainText() API that is called by twitter's rich text module. The value returned by the API does not include the word in composition, matching the behavior I'm seeing. (Although my jsfiddle shows that it includes the word after Control+Enter.)

Looking at the stack, it seems Twitter tries to do something with the composition in their code but seemingly not very useful here. (This function appears on the stack when adding hook on getPlainText() call and doing Control+Enter thing):

      resolveComposition: function (t) {
        if (!h) {
          var e = p(g).stopAndFlushMutations();
          g = null,
          d = !0;
          var r = a.set(t._latestEditorState, {
            inCompositionMode: !1
          });
          if (t.exitCurrentMode(), e.size) {
            var n = r.getCurrentContent();
            e.forEach((function (t, e) {
              var s = o.decode(e),
              u = s.blockKey,
              c = s.decoratorKey,
              l = s.leafKey,
              p = r.getBlockTree(u).getIn([c,
              'leaves',
              l]),
              d = p.start,
              h = p.end,
              g = r.getSelection().merge({
                anchorKey: u,
                focusKey: u,
                anchorOffset: d,
                focusOffset: h,
                isBackward: !1
              }),
              y = f(n, g),
              v = n.getBlockForKey(u).getInlineStyleAt(d);
              n = i.replaceText(n, g, t, v, y),
              r = a.set(r, {
                currentContent: n
              })
            }));
            var s = l(r, c(t)).selectionState;
            t.restoreEditorDOM();
            var u = a.acceptSelection(r, s);
            t.update(a.push(u, n, 'insert-characters'))
          } else t.update(r)
        }
      }

Comment 29

[Oana Arbuzov [:oanaarbuzov]]

The issue is still reproducible on Firefox and Chrome.

Tested with:
Browser / Version: Firefox Nightly 99.0a1 (2022-02-07), Chrome 98.0.4758.82
Operating System: Windows 10 Pro

Comment 30

[Oana Arbuzov [:oanaarbuzov]]

This is still an issue.
https://prnt.sc/dysgDkDsL4c5

Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-22), Chrome 102.0.5060.53
Operating System: Windows 10 Pro

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P1'/severity 'S1'.
:denschub, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 32

[Thomas Wisniewski [:twisniewski]]

I'll investigate this as soon as possible, in case we can at least make an site intervention here like we did for bug 1739489.

Comment 33

[Thomas Wisniewski [:twisniewski]]

We have now been shipping an intervention for DraftJS on Twitter now for quite some time (via bug 1776229), but I don't have the setup to confirm if this IME issue is still happening. Could you do a quick check, :saschanaz?

Comment 34

[Kagami Rosylight [:saschanaz] (they/them)]

I can still reproduce comment #0 on Windows 11 on the default Korean IME.

Comment 35

[Calin Tanase (OOO until 22nd of Nov)]

Verified this issue and it's still reproducible on Firefox versions 122 and 124. Seems to reproduce on Chrome as well.

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 124.0a1 (2024-01-24) / Firefox Release 122 / Chrome 121.0.6167.86

Comment 36

[Kagami Rosylight [:saschanaz] (they/them)]

Thanks! I can confirm the same too on Windows 11 22631.3085. Not seen on Safari 17.3 on macOS Sonoma 14.3.