Description: In Calc, the cursor caret stops inside a cell when continuously moving between cells with the arrow keys. This only happens in Japanese input mode on macOS. This does not occur with version 7.4, nor version 7.5 on Windows. Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Mac OS X 13.3.1; UI render: default; VCL: osx Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded Steps to Reproduce: 1.Set the input mode to Japanese. 2.Hold down an arrow key. 3.The cursor caret will stop inside the next cell. Actual Results: Some "content" remains inside the cell (the cell is no longer empty). The content maybe some invisible character code. Expected Results: Reproducible: Always User Profile Reset: No Additional Info:
In order to try and replicate the behavior... Does this happen when the cells contain Japanese characters only? Or, is this also happening with Latin characters too? Does it happen when cells have numbers only? Does it happen when cells contain formulas, not text? Does it happen only when the non-empty cells are all adjacent? Or, does it happen also when there are blank empty cells in between? Are the cells in question located in one column? Or, does it happen also when the cells are arranged in different columns? Perhaps adding to the report a simple sample ods file in order for others to reproduce the same behavior would help. You would probably want to eliminate any private information before doing so.
This phenomenon occurs regardless of the contents of the cells, even on a brand new sheet. Just set the input mode to Japanese, and hold down an arrow key. However, repeatedly tapping the arrow key successfully moves the active cell one by one. The phenomenon only occurs when you keep an arrow key down intending to move the active cell continuously.
Created attachment 186842 [details] reproduction LO7.5.2 arrow Left key Hold down U+001C arrow Right key Hold down U+001D arrow Up key Hold down U+001E arrow Down key Hold down U+001F Not reproduced in LO7.5.3. may be 154708
(In reply to Saburo from comment #3) > Created attachment 186842 [details] > reproduction > > LO7.5.2 > arrow Left key Hold down U+001C > arrow Right key Hold down U+001D > arrow Up key Hold down U+001E > arrow Down key Hold down U+001F > > Not reproduced in LO7.5.3. > may be 154708 IIUC, this was repro in LO 7.5.2, but no longer repro in LO 7.5.3, which might be related to the patch for tdf#154708 ? If the test's results could be confirmed by someone else on macOS (for pre-7.5.3 and then for a current version, respectively), then this report would be (at least) WFM.
Oops, you are right, I read too hastily
dinosaurm, would be great if you could test in an updated version and let us know if you can still reproduce or if we can mark as duplicate of bug 154708. Much appreciated!
Tried reproducing in 7.5.2.2 1. open system preferences on macOS 13.6, search for input sources and add `Japanese` to input sources 2. open test file from this issue here 3. switch input source to japanese 4. select any field and try navigating by long-pressing arrow key Result: cell highlight moves a single cell, then removes cell content and goes into edit mode. While when using german input source, cell highlight keeps moving until the end of the sheet. Repeat test in main build. Result: cell highlight behaves identical for japanese and german input source. Highlight keeps moving until end of sheet. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f8e591ab9182e0a61c4ae5b8f77b166fcaeaa877 CPU threads: 8; OS: macOS 13.6; UI render: Skia/Raster; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded WORKSFORME @dinosaurm@me.com: You may want to update your macOS - you are running a very outdated version lacking many important security fixes from apple.