Bug Hunting Session
Bug 88474 - EDITING: Selection Mode is Reset to ‘Standard selection’ with Esc
Summary: EDITING: Selection Mode is Reset to ‘Standard selection’ with Esc
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Statusbar
  Show dependency treegraph
 
Reported: 2015-01-15 18:30 UTC by Harald Koester
Modified: 2019-04-23 15:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2015-01-15 18:30:09 UTC
In order to reproduce the bug:

[1] Open new text document. 
[2] In the status bar select a selection mode which is not the ‘Standard selection’.
[3] Insert some text. 
[4] Select some text with the selected selection mode. 
[5] Suppose your selection is not correct and you like to make a new selection: Delete selection with ‘Esc’. The selection is deleted and the selection mode is reset to ‘Standard selection’. Expected: Selection mode should not change.

Bug also exists in version 4.4.0.2.
Comment 1 Robinson Tryon (qubit) 2015-01-15 20:22:33 UTC
TESTING with LO 4.4.0.2 + Ubuntu 14.04

(In reply to Harald Koester from comment #0)
> In order to reproduce the bug:
> 
> [1] Open new text document. 
> [2] In the status bar select a selection mode which is not the ‘Standard
> selection’.

For those who don't use selection modes, here's some info:
https://help.libreoffice.org/Writer/Selection_Mode

> [3] Insert some text. 
> [4] Select some text with the selected selection mode. 
> [5] Suppose your selection is not correct and you like to make a new
> selection: Delete selection with ‘Esc’. The selection is deleted and the
> selection mode is reset to ‘Standard selection’. Expected: Selection mode
> should not change.

I can reproduce the behavior, but I'm not sure that it's a bug. I'll hand this to UX for their input.

Status -> NEW
Component -> ux-advise
Hardware -> (generalize)
Comment 2 Robinson Tryon (qubit) 2016-08-25 04:21:40 UTC Comment hidden (obsolete)
Comment 3 Heiko Tietze 2017-04-20 12:37:09 UTC
The design team talked about the issue on 2017/Apr/20, from the minutes:

+ currently when you cancel the selection the mode is reverted from Adding, for instance, to standard
+ pro reverting to standard (as today): cancel is not the normal operation and mostly users expect it to be reverted
+ con: other tools keep the manually set mode until the user changes it back
+ Microsoft toggles selection mode per alt (block mode) and ctrl (addition) (but not in combination)
+ there is an inconsitency between keyboard use that reverts the selection and the toolbar/menu, which keeps the mode
+ would prefer the Microsoft way to use only keyboard accelerators (that are by nature temporarily) (Heiko)
+ LibreOffice has shortcuts https://help.libreoffice.org/Common/Selection_Mode (Jay)
+ We have ctrl/shift/alt + left mouse for the different modes so could remove the static switch (Heiko)
+ feedback is needed, e.g. different icons in statusbar (Tomaz), and ideally also with the cursor (Jay)
+ decision is to keep the static selection, make it consistent over the UI, make it really static and keep it after eascape
  but the prefered method is to use the keyboard accelerators

Summary:

1. Provide feedback about the mode by changing the statusbar icon and with a modified cursor
2. Make the selection via menu static and keep it unless the user switches back (no revert on escape, ctrl+V)
2a. Make the behavior consistent over the input methods
3. Keep the temporarily modification with keyboard accelerator as the preferred method
3a. Check that this method works perfectly in all modules (CC Xisco)
4. Update the documentation accordingly (CC Olivier)

(Removing UX)
Comment 4 QA Administrators 2018-04-21 02:34:03 UTC Comment hidden (obsolete)
Comment 5 Harald Koester 2018-04-22 17:28:20 UTC
Bug still exists with version 6.0.3 (64 bit, Win7).
Comment 6 QA Administrators 2019-04-23 02:48:39 UTC Comment hidden (obsolete)
Comment 7 Harald Koester 2019-04-23 15:08:30 UTC
Bug still exists in version 6.2.3 (64 bit, Win 10).