I can reproduce with RIME input method on Windows 11:

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5618526c14a591d4d5ba5efcb20b027c6782524b
CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: CL threaded

However:

(In reply to Takenori Yasuda from comment #0)
> Works:
> - 谷歌拼音输入法2.7.25.128
> 
> Fails:
> - GoogleJapaneseInput-2.31.5840.0+24.11.9
> - Microsoft IME
> - Microsoft Pinyin
I have both Microsoft Pinyin and RIME installed. When I first test it, MS Pinyin works fine, and I can only reproduce using RIME.

Then when I switch back to MS Pinyin, it stopped working. I think it has something to do with the "pre-composition keys" (I don't know the exact term, it's about displaying the keys you pressed before converting them to Kanji/Hanzi), but I don't have time to investigate right now.

Leaving status as UNCONFIRMED so that more people can look at it and maybe give more comprehensive steps to reproduce.

> In addition, the Rename Object dialog does not display even though it did up
> to LO 25.2.
I believe this is intentional. In-place editing seems better than a pop-up dialog with only one field to me. I've been using this feature with English UI and English object names on version 24.2/25.2/25.8, and have never encountered this problem before.

As for the IME, I might have a lead.
I noticed that the IMEs affected by that bug seemed to share the following characteristics:

- The language follows a "type -> convert -> confirm" input process.
- The IME displays the unconfirmed (composing) text directly in the document.


(In reply to Ming Hua from comment #1)
> I believe this is intentional. In-place editing seems better than a pop-up
> dialog with only one field to me.
I see — in that case, the Rename Object dialog may not be necessary.

(In reply to Takenori Yasuda from comment #2)
> As for the IME, I might have a lead.
> I noticed that the IMEs affected by that bug seemed to share the following
> characteristics:
> 
> - The language follows a "type -> convert -> confirm" input process.
> - The IME displays the unconfirmed (composing) text directly in the document.
This does not match my experience.

RIME [1] here display the pre-composition keys and the Hanzi candidates all in the pop-up window, not directly in the document, yet I can still use it to reproduce.

I originally thought it would be the other way, as MS Pinyin put pre-composition keys inside the document, but I could use it to change object names in my first try.

1. https://rime.im/ is the official website, no English or Japanese though.

(In reply to Ming Hua from comment #3)
> RIME [1] here display the pre-composition keys and the Hanzi candidates all
> in the pop-up window, not directly in the document, yet I can still use it
> to reproduce.
That makes sense — based on this, it might be better to treat the issue as IME-independent when investigating and fixing it.

Thank you very much for sharing this valuable information!

for reference
commit 492c94abe05e5ac213475cdd85f158b7a462f824
Add functionality to enable inline editing of tree node objects
in the navigator panel to rename objects.

I was able to input Japanese.
***
***
commit 8316409b68a97f0129b1fd67bcb8c61a7010ceec
Resolves tdf#166186 Showing the context menu for in-place editing

ends in-place editing (x11 only)

Fixing this revealed that ESC ends in-place editing when the popup
menu is active. Esc a second time ends the popup menu. This patch
fixes this issue as well.

I can no longer input Japanese

Thanks Saburo for the bisection. Let's mark this as NEW.

Jim, bisection points to your commit 8316409b68a97f0129b1fd67bcb8c61a7010ceec . Are you familiar with Input Method Engines for CJK, and if yes, would you please take a look?

(In reply to Ming Hua from comment #6)
> Jim, bisection points to your commit
> 8316409b68a97f0129b1fd67bcb8c61a7010ceec . Are you familiar with Input
> Method Engines for CJK, and if yes, would you please take a look?
Hi Ming,

I don't see anything in that commit that would cause CJK languages not to work. Since I am unable to test this I can't say for certain.

Possibly this comment in the Edit::ImplRepaint function (vcl/source/control/edit.cxx) would help someone familiar with CJK rendering in LO:
// if IME info exists loop over portions and output different font attributes

https://opengrok.libreoffice.org/xref/core/vcl/source/control/edit.cxx?r=1f0d2531dbeff80eeb3a4fe8485ef1baec6d5752&mo=16963&fi=553#553

I think our CJK expert is Shinji Enoki. I found this article:
https://events.documentfoundation.org/libreoffice-conference-2024/talk/VMZKGC/

(In reply to Jim Raykowski from comment #7)
> (In reply to Ming Hua from comment #6)
> > Jim, bisection points to your commit
> > 8316409b68a97f0129b1fd67bcb8c61a7010ceec . Are you familiar with Input
> > Method Engines for CJK, and if yes, would you please take a look?
> Hi Ming,
> 
> I don't see anything in that commit that would cause CJK languages not to
> work. Since I am unable to test this I can't say for certain.
Thanks for the quick reply, Jim.

> Possibly this comment in the Edit::ImplRepaint function
> (vcl/source/control/edit.cxx) would help someone familiar with CJK rendering
> in LO:
> // if IME info exists loop over portions and output different font attributes
> 
> https://opengrok.libreoffice.org/xref/core/vcl/source/control/edit.
> cxx?r=1f0d2531dbeff80eeb3a4fe8485ef1baec6d5752&mo=16963&fi=553#553
> 
> I think our CJK expert is Shinji Enoki. I found this article:
> https://events.documentfoundation.org/libreoffice-conference-2024/talk/
> VMZKGC/
I don't know if Enoki-san is still active. Let's ask Jonathan, our in-house CJK expert first.

Jonathan, both Yasuda-san and I are seeing this on Windows. Saburo-san didn't say what OS he/she reproduce on. I don't know if it's OS-specific or not. Either way, can you please have a look and see if you can reproduce?

(In reply to Ming Hua from comment #8)
> Jonathan, both Yasuda-san and I are seeing this on Windows. Saburo-san
> didn't say what OS he/she reproduce on. I don't know if it's OS-specific or
> not. Either way, can you please have a look and see if you can reproduce?

I can reproduce this bug on Linux with Fcitx5 Mozc.

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3254fbdc22200082c21f3de77e14a5b3317d2858
CPU threads: 32; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+wayland)
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

I've also double-checked the bibisect by reverting the referenced commit locally. The bug no longer reproduced after I did so.

The root cause is the MyEdit_Impl::Command() override in vcl/source/treelist/treelistbox.cxx. That new method drops all commands other than CommandEventId::ContextMenu, rather than passing them through to Edit::Command().

I haven't studied the original bug fix, so I'm not sure the right way to implement that without causing a regression.

Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4f053ee1b55faa9deec3cbf7cb88f265458b20e0

tdf#168929 fix cannot rename objects with CJK languages via Navigator

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Jonathan Clark from comment #10)
> The root cause is the MyEdit_Impl::Command() override in
> vcl/source/treelist/treelistbox.cxx. That new method drops all commands
> other than CommandEventId::ContextMenu, rather than passing them through to
> Edit::Command().

Exactly! I didn't see your comment until after I uploaded the patch. Would have saved me some cycles if I had :)

Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/55d72acdba8e55ff44da1534d7c9426fc89a6063

tdf#168929 fix cannot rename objects with CJK languages via Navigator

It will be available in 25.8.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Confirming fixed in 25.8.3 RC1 on Windows with Microsoft Pinyin IME:

Version: 25.8.3.1 (X86_64)
Build ID: 52ad9dd1c984050a9fb6932dbfb16e86a49e9758
CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: en-US
Calc: CL threaded

Thanks, Jim and Jonathan!