Bug 161455 - Unexpected Selecting when character is selected and use TAB to move to next cell
Summary: Unexpected Selecting when character is selected and use TAB to move to next cell
Status: RESOLVED DUPLICATE of bug 118698
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Writer-Tables-Select
  Show dependency tree / graph
 
Reported: 2024-06-07 10:30 UTC by Viento Wang
Modified: 2024-07-02 18:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Viento Wang 2024-06-07 10:30:07 UTC 
Description:
In a writer table
select any character/word
use TAB to jump to next cell
both cells are selected

Steps to Reproduce:
In a writer table
select any character/word
use TAB to jump to next cell
both cells are selected

Actual Results:
it selects both cells

Expected Results:
the cursor just moves to next cell ( with or without selecting ALL in the 2nd cell)


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: CL threaded
Comment 1 Dieter 2024-06-23 10:40:43 UTC 
I confirm the described behaviour with

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: d2eab48f697a1e6097778158f623f11306ac7a3d
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded

I also think, that this is a bug, but since I'm not sure for 100%, let's ask design team for a double check.
Comment 2 Heiko Tietze 2024-06-24 12:15:00 UTC 
I would rather call it a convenience feature. And since you first advance over rows and then columns, probably some code has been added intentionally.

You can advance per arrow keys, that will clear any selection.
Comment 3 Dieter 2024-06-24 16:56:01 UTC 
Heiko, so you would say NAB?
Comment 4 Viento Wang 2024-06-25 02:41:27 UTC 
Maybe, IMHO, it's better to just give up the current selection and move to next cell (ideally to the last of the contents, if any, in that cell, but not selecting all those contents)? 
Because that would be a more consistent behavior. 
On the other hand, why would someone want to select these two cells when he presses TAB? That doesnt make sense. More likely, he just wants to move to next cell, or to add a new row.
Comment 5 Cor Nouws 2024-07-02 07:53:46 UTC 
why is this unexpected? 
In any case: I cannot remind it has ever been different ;) (was similar in OOo)
Comment 6 Cor Nouws 2024-07-02 07:55:20 UTC 
(In reply to Viento Wang from comment #4)
> ...
> presses TAB? That doesnt make sense. More likely, he just wants to move to
> next cell, or to add a new row.
One could also ask: why make a selection, before hitting TAB?
Comment 7 Bdac 2024-07-02 09:56:45 UTC 
IMHO the current behavior is logical and normal, I would not assimilate it to a bug. If I just wanted to next cell, I would use the TAB after deselecting the text...
Comment 8 V Stuart Foote 2024-07-02 18:03:22 UTC 

*** This bug has been marked as a duplicate of bug 118698 ***