Bug Hunting Session
Bug 111627 - Cursor keys scroll document in Calc instead of moving
Summary: Cursor keys scroll document in Calc instead of moving
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2017-08-10 08:59 UTC by Karsten
Modified: 2018-02-13 13:12 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 Karsten 2017-08-10 08:59:43 UTC
Description:
I now this is a new feature and should not be a bug, but i am running crazy like many other users with this feature.

This is referenced to
* https://bugs.documentfoundation.org/show_bug.cgi?id=46200
* https://ask.libreoffice.org/en/question/76927/missing-scroll-lock-keyboard-key-feature-in-libreoffice-calc/
* https://askubuntu.com/questions/141729/custom-key-to-toggle-keyboard-layout

The problem is that i could not find a way to toggle the scroll lock on my PC.
So this feature can't be disabled!
On other PC's you have the same or other problems with scroll lock.

My suggestion is not to remove the feature but give another option to disable it.
Maybe a menu entry, button or whatever can be easy implemented.
The standard behaviour must be that this feature is deactivated!

For me i must roll back to a release before 5.3 because i can't work with calc any more with this feature.


Steps to Reproduce:
Upgrade to new version.

Actual Results:  
Cursor keys move screen

Expected Results:
Cursor keys move to neighbor cell


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Karsten 2017-08-10 09:02:02 UTC
Of course it should be "I know" and not "I now". :-)
Comment 2 m.a.riosv 2017-08-10 12:06:42 UTC
Please test with Menu/Help/Restart in Safe Mode
Comment 3 Hamid 2017-09-11 16:18:30 UTC
Same. Sometimes it woks as usual sometimes not. I even didn't notice it was scrollbar feature. That restart request seems nonsense. What to look for? What to report? For extended work it is better to change to another spreadsheet.
Comment 4 Aron Budea 2017-10-02 00:54:11 UTC
The request was see if it occurs with an empty profile (which safe mode guarantees), and to report back whether the issue occurs or not.

The question is, why this isn't working as expected (please verify with an on-screen keyboard that Scroll Lock is off according to the system). I don't see the reason why the feature would need to ability to be deactivated, it should work normally instead, and not trigger unless someone actually turns on Scroll Lock.
Comment 5 Hamid 2017-10-06 18:03:56 UTC
Found the caveat: changing keyboard layout (which is pressing both shifts) triggers scroll lock on my keyboard. Of course the keyboard is just reporting key presses but KDE or X is interpreting it such way. I'll look more into it and if relevant will notify.

To check for yourself (the options line in the output):

$ setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc101
layout:     us,ir
options:    grp_led:scroll,grp:shifts_toggle
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete+ledscroll(group_lock)
symbols:    pc+us+ir:2+inet(evdev)+group(shifts_toggle)
geometry:   pc(pc101)
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+ledscroll(group_lock)"        };
        xkb_symbols   { include "pc+us+ir:2+inet(evdev)+group(shifts_toggle)"   };
        xkb_geometry  { include "pc(pc101)"     };
};
Comment 6 Aron Budea 2017-10-06 18:24:26 UTC
There is a bug report to make this setting configurable, bug 112876.
Comment 7 Hamid 2017-11-05 17:19:43 UTC
I am not seeing this bug anymore. I recently upgraded to Kubuntu 17.10. That might be the fix.
Comment 8 Norbert X 2017-11-30 16:41:41 UTC
I'm using Ubuntu 16.04.3 MATE with LibreOffice from PPA (ppa:libreoffice/libreoffice-5-4 ) with Marco (Software compositor) window manager.

I have configured two input languages - English and Russian; I switch them with <Alt+Shift>, ScrollLock LED indicates second (Russian) layout.
So in /etc/default/keyboard I have

    # KEYBOARD CONFIGURATION FILE
    
    # Consult the keyboard(5) manual page.
    
    XKBMODEL="pc105"
    XKBLAYOUT="us,ru"
    XKBVARIANT=","
    XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"
    
    BACKSPACE="guess"    

LibreOffice Calc works very strange.
Its version is 

version is

    Version: 5.4.2.2
    Build ID: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo1
    CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
    Locale: en-US (en_US.UTF-8); Calc: group

    $ apt-cache policy libreoffice-calc 
    libreoffice-calc:
      Installed: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo1
      Candidate: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo1
      Version table:
     *** 1:5.4.2~rc2-0ubuntu0.16.04.1~lo1 500
            500 http://ppa.launchpad.net/libreoffice/libreoffice-5-4/ubuntu xenial/main i386 Packages
            100 /var/lib/dpkg/status
         1:5.1.6~rc2-0ubuntu1~xenial2 500
            500 http://archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages
            500 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages
         1:5.1.2-0ubuntu1 500
            500 http://archive.ubuntu.com/ubuntu xenial/main i386 Packages
    


How to reproduce this:
1. Open Calc, create new document
2. Fill document cells with some data
3. Switch keyboard layout to Russian
4. Try to move focus from one cell to another with keyboard arrow keys

Expected results:
* arrow keys move cell selection


Actual results:
* arrow keys move entire sheet

Notes:
* if I disable Scroll Lock LED indication Calc moves cell selection as usual.
* versions 1:5.1.2-0ubuntu1 from official repository (xenial/main) does not have such problem.
* version 1:5.1.6~rc2-0ubuntu1~xenial2 from official repository (xenial-updates/main, xenial-security/main) does not have such problem.


    
Please fix this bug. LibreOffice Calc should not care about ScrollLock LED state.
Comment 9 m.a.riosv 2017-11-30 17:04:35 UTC
Why a LibreOffice bug?

https://en.wikipedia.org/wiki/Scroll_lock#Window_scrolling
Comment 10 Karsten 2017-11-30 17:54:37 UTC
It's a problem of LibreOffice because
1. This problem does not exist in LibreOffice before.
2. A key for a new function is used that makes problems.

So please offer a solution.
Thank you!
Comment 11 m.a.riosv 2017-11-30 18:52:51 UTC
Main spreadsheet programs use it from ever, at least in 1982 Lotus 123 used it so.
LibreOffice can't limit their usability because others use a keystroke in, for me, not the right way.

IMHO the only possible solution it's @Aron's comment#6, having an option to disable their use.
https://bugs.documentfoundation.org/show_bug.cgi?id=112876
Comment 12 Karsten 2017-12-01 09:19:03 UTC
This is a bug in the meaning of disturbing normal functionality.

First we are on the edge to 2018 and not in the year 1982 anymore!
In the beginning this keys really have a meaning - today they are not supported correct as you can see!

As i have written - don't remove anything - just give this functions another key !?
Why it must be a key that make problems with some OS?
Why not anything else - ALT + Shift + M or any other free combination?
It would be more perfect to add another menu entry.
Comment 13 Xisco Faulí 2018-01-17 16:37:27 UTC
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
Comment 14 Karsten 2018-01-17 16:45:51 UTC
Sorry - i didn't want to confirm it.
I want a solution for the problem.
Comment 15 Buovjaga 2018-02-11 15:08:22 UTC
(In reply to m.a.riosv from comment #11)
> Main spreadsheet programs use it from ever, at least in 1982 Lotus 123 used
> it so.
> LibreOffice can't limit their usability because others use a keystroke in,
> for me, not the right way.
> 
> IMHO the only possible solution it's @Aron's comment#6, having an option to
> disable their use.
> https://bugs.documentfoundation.org/show_bug.cgi?id=112876

Summoning the gods of UX
Comment 16 Heiko Tietze 2018-02-12 16:41:34 UTC
To summarize: With Scoll Lock enabled you scroll but expect the same behavior as before (navigate to cells)? 

Sounds not like a bug since it's the defined behavior of scroll lock. It's very useful for accessibility. So a NOTABUG from my side. 

The ask.libo reference is a clear statement and bug 112876 a good compromise. The question how to toggle the scroll lock is NOTOURBUG. There are plenty of resources how to get the key back, for instance here https://superuser.com/questions/677003/scroll-lock-key-not-working-on-fedora-kde
Comment 17 Karsten 2018-02-12 17:20:58 UTC
It seems that you want to misunderstand me.
The function of the cursor keys have been altered by the use of the scroll lock key.

This is not the problem - the problem is that this key is not supported for this function any more, specially in KDE.

So you can see this not as bug, but then please see it as a bad design, because you expect a normal functionality of the scroll lock key in every OS and desktop system.

Because this functionality is not given in all cases, there should be a workaround to activate the functionality in an alternative way.
The best way is an additional menu entry.

Thank you for understanding.
Comment 18 Heiko Tietze 2018-02-12 17:40:37 UTC
(In reply to Karsten from comment #17)
> This is not the problem - the problem is that this key is not supported for
> this function any more, specially in KDE.

So why don't you ask on the KDE bugtracker? (Checked it right now: Calligrasheets doesn't respect scroll lock)

> Because this functionality is not given in all cases, there should be a
> workaround to activate the functionality in an alternative way.

Right, that's bug 112876. And what do you expect from this issue?
Comment 19 Karsten 2018-02-12 17:53:57 UTC
(In reply to Heiko Tietze from comment #18)
> (In reply to Karsten from comment #17)
> > This is not the problem - the problem is that this key is not supported for
> > this function any more, specially in KDE.
> 
> So why don't you ask on the KDE bugtracker? (Checked it right now:
> Calligrasheets doesn't respect scroll lock)

As you can see - why are you using a functionality that does not work everywhere?
Is Libreoffice only designed to work on special OS?

> 
> > Because this functionality is not given in all cases, there should be a
> > workaround to activate the functionality in an alternative way.
> 
> Right, that's bug 112876. And what do you expect from this issue?

Because the scroll lock functionality should not be disabled.
This new functionality shall keep in function, but in a compatible way for all systems.
Comment 20 Heiko Tietze 2018-02-12 18:31:56 UTC
(In reply to Karsten from comment #19)
> Because the scroll lock functionality should not be disabled.
> This new functionality shall keep in function, but in a compatible way for
> all systems.

Please elaborate. Do you mean no scrolling when locked in Calc but in Writer/Draw?
Comment 21 Karsten 2018-02-13 08:28:35 UTC
I did not have a problem in Writer or Draw.
Only in Calc i could suddenly not navigate to the cells with the cursor keys anymore.

That's the reason i opened this bug - everything was fine before for years and then this problem occurs.

This functionality was added to Libreoffice - that's a good idea.
The problem is that this functionality can only be controlled with the scroll lock key.
When this key is not working (because the desktop system does not support it correct) then the behaviour can't be controlled.
In my case the cursor keys are not working as usual in the past.

So from the point of view of the user the software is not working any more as before (-> bug).

The additional functionality is fine, but there should be a possibility to switch the scroll behaviour if the scroll lock key is not supported.
This can be done with a global configuration as suggested in bug 112876, or in a more convenient way in the menu or button like other functionalities.

Is there any more to say?
Comment 22 Heiko Tietze 2018-02-13 08:41:22 UTC
(In reply to Karsten from comment #21)
> Is there any more to say?

Thanks for the perfect summary. I closed the issue as NOB (and still think it's the only resolution here) because 
* scroll lock is standard behavior
* needed for accessibility
* availability of the key should be fixed by the distribution

An option is acceptable (bug 112876), and we could predefine it with on/off depending on whether scroll lock is available.
Comment 23 Xisco Faulí 2018-02-13 11:05:02 UTC
> The additional functionality is fine, but there should be a possibility to
> switch the scroll behaviour if the scroll lock key is not supported.

We have bug 112876 for that.
Closing as RESOLVED NOTABUG as Heiko has already done
Comment 24 Karsten 2018-02-13 13:12:44 UTC
O.K. It's your decision to solve this problem in bug 112876.

This will be a solution and the problem is not ignored.

Thanks for your work at Libreoffice!