Bug 96973 - EDITING Impress Home and End keyboard keys don’t work
Summary: EDITING Impress Home and End keyboard keys don’t work
Status: RESOLVED DUPLICATE of bug 91909
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.0.1 rc
Hardware: All All
: medium minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.2.0 target:5.1.0
Keywords: bibisected, regression
: 98569 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-01-08 21:52 UTC by Robert Gonzalez MX
Modified: 2016-10-25 19:08 UTC (History)
8 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 Robert Gonzalez MX 2016-01-08 21:52:21 UTC 
Description:
When editing text in impress the keyboard keys “Home” and “End” don’t work.

Steps to reproduce:

Create a new impress presentation
Select layout Title Slide
Click to add some text, but at the end of typing press the “home” keyboard key
The cursor doesn’t move
As a workaround press ctrl-left arrow as many times to reach the beginning of the text
Then press the “end” keyboard key
The cursor doesn’t move

Version: 5.1.0.1.0+ 
Build ID: 2c6e8e4142493dd135003aff16a1709d6e3a29d0
CPU Threads: 2; OS Version: Windows 5.1; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-1, Time: 2016-01-06_12:56:07
Locale: es-MX (es_MX)
On Windows XP SP3, and Windows 10
Comment 1 Joel Madero 2016-01-08 22:13:16 UTC 
Is this a duplicate of 34688?
Comment 2 Cor Nouws 2016-01-08 23:27:09 UTC 
Thanks for filing Robert.
I confirm the problem in Version: 5.2.0.0.alpha0+
Build ID: c1258abe50f1508ea0f628ff963bc1914ab86b67
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-01-02_01:45:44
Locale: nl-NL (nl_NL.UTF-8)

In 3.3.0 one can simply use Home/End. So it's a regression..

@joel: it looks a bit like that issue yes. I do not expect Impress and Calc use the same editing code here.

Ciao - Cor
Comment 3 Joel Madero 2016-01-09 04:47:00 UTC 
Minor: Can slow down but won't prevent high quality work;
Medium: Default is low but regression bumps it up.
 bd12431bd78dcabe3ed821ed509ae1f49758eaae is the first bad commit
commit bd12431bd78dcabe3ed821ed509ae1f49758eaae
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Tue Dec 8 05:33:56 2015 +0100

    2015-12-08: source-hash-ad0edc184792f3aa3f72e8d4ec8b76c3d1bf8479

:100644 100644 98c36b78fb74d8b55c1e8dd5309beb8ac855fc70 73a59b50b33d4b1e7d4f416347c5fabcba945221 M	build-info.txt
:040000 040000 5c7ef0fb9837f38ec6cecc34fd8f887406b99303 4c35b9bd9effdf8323a210d7aa106603558cadab M	opt

# bad: [f399ea2aa2624fa71ec5fc11c6b7a6ccc41004bc] 2016-01-08: source-hash-81e59f3b5012fe8db00adf0dbe6245090590d348
# good: [69eedb44a433e3be69137a83238a4184785c752f] 2015-11-25: source-hash-7289a140fc68dc898ba2b2357cc960968195f236
git bisect start 'master' 'oldest'
# bad: [4106e1e219154f968de1ba085fa836ee35fb1aa1] 2015-12-17: source-hash-15614c847dde4c52a4974022e5523c9c4fea856b
git bisect bad 4106e1e219154f968de1ba085fa836ee35fb1aa1
# good: [cf4c569f675fc0256806cc50293c7de8d6060770] 2015-12-06: source-hash-30d73431ee51ca2ebcca9029bf0af4a0c4dc565c
git bisect good cf4c569f675fc0256806cc50293c7de8d6060770
# bad: [fa4d4b855bf9f9a413bc90a54e34d3a82b06d6c2] 2015-12-11: source-hash-f2070db3f2ad7e0c4b7d7233b5999bcf869226b5
git bisect bad fa4d4b855bf9f9a413bc90a54e34d3a82b06d6c2
# bad: [bd12431bd78dcabe3ed821ed509ae1f49758eaae] 2015-12-08: source-hash-ad0edc184792f3aa3f72e8d4ec8b76c3d1bf8479
git bisect bad bd12431bd78dcabe3ed821ed509ae1f49758eaae
# good: [4a3d4b936a309598fd04ea8122fb15b82f1c48c1] 2015-12-07: source-hash-2cd9ecd8644d16780443cdb6b52e208af9066105
git bisect good 4a3d4b936a309598fd04ea8122fb15b82f1c48c1
# first bad commit: [bd12431bd78dcabe3ed821ed509ae1f49758eaae] 2015-12-08: source-hash-ad0edc184792f3aa3f72e8d4ec8b76c3d1bf8479
Comment 4 Katarina Behrens (Inactive) 2016-01-29 17:54:55 UTC 
Any productive work totally comes to a grinding halt b/c of this bug. I'm working on my FOSDEM slides and I'm suffering
Comment 5 Robert Gonzalez MX 2016-01-30 18:20:40 UTC 
Hello.

I just tested the 5.1 RC3

Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; 
Locale: es-MX (es_MX)

And the problem is still present

As a workaround ctrl-home and ctrl-end will help with the editing.
Comment 7 Adolfo Jayme Barrientos 2016-02-03 10:15:36 UTC 
Backported to the 5-1-0 branch, so that it will appear in RC4/Final: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-1-0&id=78d3ba011b8866416b59c2fdffa9ab0c16da9ed2
Comment 8 Pedro Neves 2016-02-19 20:35:45 UTC 
Hi:

This bug It's still present in 5.1.0.3. Tested in Linux (Kubuntu 15.10 and KaOS).
Comment 9 Robert Gonzalez MX 2016-02-19 21:25:12 UTC 
Hi.
just tested it with Version: 5.1.1.1 (RC1)
Build ID: c43cb650e9c145b181321ea547d38296db70f36e
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: es-MX (es_ES)

and it works fine.

Windows 10
Comment 10 stoet 2016-03-03 16:34:04 UTC 
Exactly the same problem here with version "LibreOffice 5.1.0.3 10m0(Build:3)" on Arch Linux.

System: x86_64.
Comment 11 V Stuart Foote 2016-03-05 02:15:10 UTC 
This was fixed for the 5.1.1 release, and backported to 5.1.0 but there was not 5.1.0.4 build done.

*** This bug has been marked as a duplicate of bug 91909 ***
Comment 12 Katarina Behrens (Inactive) 2016-03-10 09:47:02 UTC 
*** Bug 98569 has been marked as a duplicate of this bug. ***