Bug 98404 - UX - While objects on a slide are being edited, notably text boxes, the new slide sorter Ctrl+Shift shortcut combinations (see bug 91909) incorrectly receive focus and move the slide
Summary: UX - While objects on a slide are being edited, notably text boxes, the new...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) rc
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected, needsDevEval, regression
: 99000 99279 99522 (view as bug list)
Depends on:
Blocks: Shortcuts-Accelerators Slide-Sorter
  Show dependency treegraph
Reported: 2016-03-04 09:22 UTC by jose.velez
Modified: 2022-01-04 02:15 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description jose.velez 2016-03-04 09:22:59 UTC
The libreeoffice documentation (https://help.libreoffice.org/Impress/Shortcut_Keys_for_Impress#Shortcut_Keys_when_Editing_Text) explain that when editing a text in a slide show the combination [Ctrl+Shift+End] go and select text to end of document.

However, when editing a text on a slide, Ctrl+Shift+End doesn't select the text in the slide, but move the slide to the end of the slide stack.

[Ctrl+Shift+Home] doesn't work either.
Comment 1 Robinson Tryon (qubit) 2016-03-06 07:24:15 UTC
TESTING on Ubuntu 14.04 64bit +
LO (2016-02-24_23:58:47)

(In reply to jose.velez from comment #0)
> The libreeoffice documentation
> (https://help.libreoffice.org/Impress/
> Shortcut_Keys_for_Impress#Shortcut_Keys_when_Editing_Text) explain that when
> editing a text in a slide show the combination [Ctrl+Shift+End] go and
> select text to end of document.

Yes, docs confirmed.

> However, when editing a text on a slide, Ctrl+Shift+End doesn't select the
> text in the slide, but move the slide to the end of the slide stack.

1) Opened 47 slide presentation (ODP)
2) Clicked into text area on 2nd slide, and then pressed Ctrl+Shift+End

RESULT: Text box/text area object was selected AND the current slide was moved to the end of the presentation.

Status -> NEW

(If this is an error in the docs (and not in the program), then we shouuld change Component to 'Documentation')
Comment 2 jose.velez 2016-03-06 07:48:01 UTC
I think, that this is not an error in the documentation.

In previous versions of Impress the behavior was as explained in the documentation. This behavior has changed in 5.x.

I know it, because I usually used this combination of keys frequently.

Moreover, in writer the behavior is similar, and hasn't changed.

By other way, there aren't another way to select the text from one point to the end of the slide.
Comment 3 Cor Nouws 2016-03-31 11:30:23 UTC
*** Bug 99000 has been marked as a duplicate of this bug. ***
Comment 4 Cor Nouws 2016-03-31 11:32:32 UTC
a nasty useability problem, IMHO
Comment 5 raal 2016-03-31 13:27:03 UTC
This seems to have begun at the below commit.
Adding Cc: to Philippe Jung; Could you possibly take a look at this one? Thanks
 d3eabfe9d10f89d48c9f53c4e3bb8364d120c723 is the first bad commit
commit d3eabfe9d10f89d48c9f53c4e3bb8364d120c723
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Thu Nov 19 09:09:26 2015 -0800

    source sha:8f07a723f932ac83b48afe55518b0a1e81e36f20

    source sha:8f07a723f932ac83b48afe55518b0a1e81e36f20

:040000 040000 785ed8ff62ab2a2ec3ba9bdccba43e401d8fcdfa 0fb7b52ea30f0f0745e2f45358572ecc31d25400 Minstdir

author	Philippe Jung <phil.jung@free.fr>	2015-11-18 23:51:13 (GMT)
committer	Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>	2015-11-19 11:55:25 (GMT)
commit 8f07a723f932ac83b48afe55518b0a1e81e36f20 (patch)
tree 8e0736fa06504ca2dc09147fe84d18d0f310eaa8
parent c94cf0cf5f10edb45a74a58c95c306b0d271645b (diff)
tdf#91909 Add shortcuts for MovePage actions
Comment 6 Cor Nouws 2016-03-31 15:41:10 UTC
Quoting https://bugs.documentfoundation.org/show_bug.cgi?id=91909#c0
" It would also be useful to have uno commands for slide sorting like move slide up, move slide down, move slide to beginning, and move slide to end, so they can also appear in the menu bar with suitable shortcut keys. Are there presently shortcut keys for these operations as i couldnt find them in the customize dialog? "

That explains a lot :)
Possibly it is useful to make a distinction between text editing mode and not?
Comment 7 Cor Nouws 2016-04-14 06:30:59 UTC
*** Bug 99279 has been marked as a duplicate of this bug. ***
Comment 8 raal 2016-04-28 11:43:13 UTC
*** Bug 99522 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2016-04-29 20:32:20 UTC
Movement of slides was introduced with enhancements of bug 91909 -- where Caolán later reverted use of the <Home> and the <End> keys for slide navigation as the shortcuts broke legacy text editing.

And here this remains a simple conflict with selected shortcuts--these <Ctrl>+<Shift>+[Home|Up|Down|End] text movement and selection text edit functions are still in conflict.

Pretty sure they are reserved inside edit engine -- and so got missed when reviewing Accelerators.xcu for use for slide movement shortcuts.

@Jay, Philippe -- if we can not isolate behavior of the Slide sorter pane from the active elements on the slide canvas then we have to change the chosen ShortCuts for slide movements.

Believe the newer feature should get new shortcuts. And the legacy (and arcane) assignments in edit engine (used in all modules) should be left alone.
Comment 10 Heiko Tietze 2016-09-06 09:34:04 UTC
Still an issue in 5.2 and master (and really annoying by the way, pushing importance). Furthermore to ctr+shift+home/end the text box should provide paragraph selection per ctrl+shift arrow.

The solution is simple: While in edit mode global shortcuts have to be ineffective.
Comment 11 Cor Nouws 2016-12-28 14:09:11 UTC Comment hidden (no-value)
Comment 12 Cor Nouws 2016-12-28 14:14:07 UTC Comment hidden (no-value)
Comment 13 Octavio Alvarez 2017-01-14 02:08:30 UTC Comment hidden (no-value)
Comment 14 Samuel Thibault 2017-05-02 18:10:35 UTC

We have found a workaround until the bug gets fixed: in Tools->Customize, the Keyboard tab, look for the control-shift-home and end entries, and click delete for both of them. Of course this is only a workaround :)

Samuel & Giroll people
Comment 15 Andreas 2018-03-07 13:17:46 UTC
I can confirm this bug still present in Version: Build ID: 40m0(Build:1).

Ctrl-Shift + xxx is definitely for selecting text and not for moving slides. This bug is indeed very annoying.

Please assign + fix.
Comment 16 Karsten 2019-01-16 11:13:48 UTC
A general discussion is needed: https://bugs.documentfoundation.org/show_bug.cgi?id=122730
Comment 17 Xisco Faulí 2020-03-09 13:28:17 UTC Comment hidden (obsolete)
Comment 18 Samuel Thibault 2020-09-02 20:40:52 UTC

This is still an issue with LibreOffice 7

Comment 19 sdc.blanco 2020-12-29 15:26:49 UTC
Motivated by bug 139286, the help page for Impress shortcut keys was updated (screenshot at: attachment 168556 [details]) to reflect the current (and apparently intended behavior, see bug 91909, comment 12). 

Adding UXEval with three questions to UXEval.

1. In light of resolved bug 91909, should this bug be closed as WF?

2. Or should the defaults for the shortcut keys be re-considered -- 

-- in light of the dissatisfaction expressed in this bug 98404 about these defaults (including from some people who are usually involved in UXEval).

(note also 3 duplicates to this bug, plus bug 139286, comment 5, which could also have been a duplicate, if it was not converted into a Documentation bug).

3.  As noted in comment 14, the defaults can be "undone" in Customize, but should there be additional efforts (e.g., new .unos) to provide keyboard shortcuts for selecting blocks of text in Impress?  

Bug 139286, comment 8 has some relevant comment. 

No opinions or preferences are intended in asking these questions, beyond the observation that it seems possible now to give a more definite and clear resolution to this bug (especially now that the change is documented).
Comment 20 Samuel Thibault 2020-12-29 15:33:36 UTC
> apparently intended behavior, see [9]bug 91909, comment 12

That comment says "and they look free" but that is wrong. Control-shift-home/up/down/end is a very long-term-well-known shortcut available very widely in graphical interfaces to select large portions of text in a textview.
Comment 21 Heiko Tietze 2021-01-19 08:58:20 UTC
We discussed this in the design meeting.

   + resolve WF or change default shortcut
     + move paragraph in Writer per ctrl+alt+arrow 
       in Impress per alt+shift+arrow, in Kate per ctrl+shift+arrow
     + ctrl+shift+arrow is select to beginning/end of paragraph or word
     + ctrl+alt+arrow sounds good, and is not used in edit mode
   + add UNO commands and replace hard-coded shortcuts
     + quite some effort for not much benefit and different topic

So the recommendation is to change the shortcut to ctrl+alt+arrow.
Comment 22 Eyal Rozenberg 2021-06-09 16:54:21 UTC
This is quite annoying, I agree with Samuel Thibault and I do hope it gets resolved ASAP. I was just about to file a dupe...

A few other points:

Consider the following states during Impress work:

1. Slide list is focused / was clicked last.
2. Slide is focused / was clicked last, no single slide object is selected/focused
3. A slide object is focused / was clicked last, its text content is not being edited.
4. The text content of a slide object is being edited (perhaps also: A slide note is being edited).

I believe that any shortcut for reordering the slide among other slides should not be in effect at state (4.) ; and I'm of two minds whether it's legitimate for it to work even in state (3.).  It is much more likely than not that the user will not expect slide order changes while working at a much deeper "level of focus" - so much so that one might assume that a click of Ctrl+Shift+Home, or Ctrl+Alt+Home, is not intended to have that effect.

That's why, regardless of the key combination change, I ask that it be made in-operational at state (4.).

Also, note that in some desktop environments (e.g. Cinnamon on Linux, probably other X'ish DEs) - Ctrl+Alt+arrow keys are used for switching virtual desktops or other kind of DE-related work, and Ctrl+Alt+End may shutdown. See:


So - not sure that would be a good choice of new shortcut.

As for adding UNO commands - I'm not quite sure about the meaning of this, but I will say that this behavior is more annoying than you might imagine, because slides look very similar to each other on the slide list panel, so you might well fail to notice the slide replacement, and get disoriented by the location of other slides. Doubly so if you have consecutive slides which are "pseudo-animations" (e.g. very similar content but with a few changes).

   + add UNO commands and replace hard-coded shortcuts
     + quite some effort for not much benefit and different topic

So the recommendation is to change the shortcut to ctrl+alt+arrow.
Comment 23 Heiko Tietze 2021-06-11 08:30:45 UTC
Bayram, one for you?
Comment 24 Bayram Çiçek 2021-06-11 09:48:47 UTC
(In reply to Heiko Tietze from comment #23)
> Bayram, one for you?

As soon as I find the code pointers, I'll be working on it.
Comment 25 Bayram Çiçek 2021-06-20 07:34:57 UTC
What I found so far:

-> Code pointers:

- for edit mode in ./sd/source/ui/func/futext.cxx:1034: https://opengrok.libreoffice.org/xref/core/sd/source/ui/func/futext.cxx?r=9090dc1f#1034
- (found this with debugging) SID_MOVE_PAGE_UP (LAST/DOWN/FIRST) state methods calls in: https://opengrok.libreoffice.org/xref/core/sfx2/source/control/shell.cxx?r=a3d89265#492
- ExecMethod / StateMethod: https://opengrok.libreoffice.org/xref/core/sd/sdi/SlideSorterController.sdi?r=951b243f#311
- Slide functions: https://opengrok.libreoffice.org/xref/core/sd/source/ui/slidesorter/shell/SlideSorterViewShell.cxx?r=9090dc1f#761
- https://opengrok.libreoffice.org/xref/core/sd/sdi/sdraw.sdi?r=951b243f#4654

-> In FuText:SetInEditMode, We should disable the global slide sorting shortcuts by something like:

    SfxItemSet aSet(mpViewShell->GetPool());
    aSet.DisableItem(SID_MOVE_PAGE_DOWN);  // and other SIDs: (LAST/UP/FIRST)
    SfxItemSet& rSet = mpView->GetStyleSheet()->GetItemSet();
    SfxItemSet aSet(mpViewShell->GetPool(), svl::Items<EE_PARA_LRSPACE, EE_PARA_LRSPACE>{} );
    auto pSet = std::make_unique<SfxItemSet>( mpViewShell->GetPool());
    SfxItemSet aSet(mpViewShell->GetDoc()->GetPool());

... but None of them are worked, and I don't know if there is another way to make SIDs disable while in edit mode. Working on this bug for ~8 days but still found no way to disable slide sorting shortcuts. Maybe, will look at it later.


Version: / LibreOffice Community
Build ID: 4668e7e7a6322cfda854ab07eabd4322c86de980
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 26 Heiko Tietze 2021-08-18 08:49:26 UTC
Hossein might have an idea.
Comment 27 Mehmet gelisin 2021-09-11 13:03:43 UTC Comment hidden (spam)
Comment 28 Michael Spear 2022-01-04 02:15:15 UTC
I almost filed another bug report for this issue.  The defaults in Impress are maddening.

Though not explicitly listed at <https://en.wikipedia.org/wiki/IBM_Common_User_Access>, I'm pretty sure that Ctrl+Shift+Home and Ctrl+Shift+End have been consistent since the Common User Access guidelines in the 1980s.  Their behavior should be exactly as it is in Calc and Writer, and exactly as it was in earlier versions of Impress.

IMO, it is also poor UX to say "clearing the shortcut mapping in Tools/Customize/Keyboard reverts to the standard/expected behavior".  
- First of all, that means there is an standard/expected behavior.  Why default to something else?
- Second, it leaves people thinking that they can't get the expected behavior, because blank should mean "this key combination does nothing".  Emacs got this right: if a key can cause a behavior, there must be a function to express that behavior.  Ctrl-Home, Ctrl-End, Shift-Home, Shift-End, etc. should all have a function or series of functions (e.g., Ctrl-Shift-Home gets the sequence (set-mark-command) (beginning-of-buffer)).  Yes, this means the function list will be extremely long.  But with reasonable defaults, most users won't ever open that setting, and those who do will appreciate the completeness.

And for those of us who need to automate keyboard configuration for non-power users who we are trying to migrate away from non-free office products, the expression of these issues in registrymodifications.xcu is counterintuitive.  The edits for these shortcuts appear to be:

<item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="END_SHIFT_MOD1" oor:op="remove"/></item>
<item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.presentation.PresentationDocument']"><node oor:name="HOME_SHIFT_MOD1" oor:op="remove"/></item>

"remove" is hardly the right word for the behavior being achieved.  The file format is fundamentally not declarative.