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
Of course it should be "I know" and not "I now". :-)
Please test with Menu/Help/Restart in Safe Mode
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.
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.
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)" }; };
There is a bug report to make this setting configurable, bug 112876.
I am not seeing this bug anymore. I recently upgraded to Kubuntu 17.10. That might be the fix.
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.
Why a LibreOffice bug? https://en.wikipedia.org/wiki/Scroll_lock#Window_scrolling
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!
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
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.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Sorry - i didn't want to confirm it. I want a solution for the problem.
(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
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
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.
(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?
(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.
(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?
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?
(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.
> 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
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!