The autocompletion does not longer work in cells by pressing tab on offer. How to get the bug: - enter the text in the following cells: A1: WG1 A2: WG2 A3: WG3 - now enter 'W' into A4, you will get 'W[mark]G1[endmark]' (text between mark and endmark is inverted) - now press tab key What happens: text will be set to WG1 and cell B4 will be selected What should happen: text will changed to 'W[mark]G2[endmark]' and the cell A4 is still the active cell. You can toggle to other possiblities (like WG3) too. OOo 3.2.0 is working fine.
[Reproducible] with "LibreOffice 3.3.0 RC4 - WIN7 Home Premium (64bit) German UI [OOO330m19 (build 6 / tag 3.3.0.4)]". Now to other autofill contents can be scrolled with <ctl>+<tab>. German Help says TAB will scroll, also English Help for AutoInput does not match with actual behaviour. In OOo3.4-dev still TAB is used for scrolling to next possible autofill contents. I believe it will be the same for all OS. Bug or feature? Wrong Help or Wrong behaviour? WIKIHELP <http://help.libreoffice.org/Calc/AutoInput> also does not match with actual behaviour
This is a feature, and the help needs updating for this.
I filed Bug 34019 - WIKIHELP does not match with actual behavior for AutoInput and close this issue due to Comment 2
(In reply to comment #2) > This is a feature, and the help needs updating for this. No, its a bug.
My mother says it is a feature, so there!
(In reply to comment #6) > My mother says it is a feature, so there! My girlfried got the big hate and says this is a bug that its changed, so it should be changed. The user should be able to change the default behavior but you never should change the default behavior, that causes a lot of trouble. I got that problem often in history and its NOT surprising for the users.
We believe in Change.
(In reply to comment #8) > We believe in Change. Never change a good working thing. To change a default behavior is a bad thing. User which want to want to change it can do it. Ask the users outside... the answer is: no new default behavior.
Oracle bones might hit mother's intuition ;-) @Christoph Thieleck: May be you should improve your knowledge concerning UI design for a software that has to work under various OS with common UI without conflicts with default OS UI shortcuts. That might help you to understand the reasons for such changes. Me and my fingers also dislike those lots of additional new <cntrl> keys for various shortcuts, but as long nobody has a better solution considering a.m. basic conditions, we will have to live with them.
@ Kohei Could this be added in OpenOffice Legacy key binding ?
(In reply to comment #11) > @ Kohei > Could this be added in OpenOffice Legacy key binding ? I'm afraid not, as this one is unfortunately hard-coded.
What shell we do with this issue? I don't see any simple solution. The lots of 3-key combinations we currently have are not very user friendly, but may be the only way to get a more or less consistent UI for all OS. May be we need some "shortkey.cfg" (or .oxt) that will allow to define all shortcuts by user, and may be predefined files available via download that will allow to install a "use MSWORD4.5 shortcuts" easily?
Unfortunately the normal shortcut key scheme doesn't apply in this case, because these key inputs are handled as direct key input i.e. like typing 'a', 'b', 'c, etc into a cell, and you can't assign a shortcut key to direct key inputs. Of course it's not impossible to make this configurable, but it may create more problems and makes the code less maintainable (the code that handles direct key inputs is very fragile). And quite frankly I don't know if it's worth the risk. But I guess we can't close this bug since if we do, it will get re-opened anyway. ;-) So, let's leave this open for now, but set it to lower priority.
I'll keep this bug for the time being.
Its still not fixed in libreoffice 3.3.2.
I don't want to be the assignee.
Using LibO_3.4.1_MacOS_x86_install_en-US, neither Tab nor ctrl+Tab lets me scroll through the alternatives. (I also tried the other ctrl/option/cmd+Tab combinations I could come up with, to no avail.) I started noticing this changed behaviour in 3.4.0, I think. The help also mentioned cmd+D to get a list of all the alternatives. That was new to me, but it didn't work anyway. So is this a bug, or have I overlooked something really obvious?
Same to me on Mac OS X, German Translation. Neither Ctrl-Tab, nor any other combination works. The CMD-D as mentioned above doesn't work, too. It's frustrating that a) the default behavior was changed and b) there is no working alternative. So we still have to continue using OOo on our Macs. And even on the Linux and Win-Desktops, as we can't force our users to use different key combinations on different platforms. Very sadly that one little thing makes the biggest trouble. But being unable to rotate to the AutoInput makes the Calc nearly unusable for us.
Forgot to say: we use LibreOffice 3.4.0 on Intel Mac.
This is still present, even in 360RC2 and, Kohei, it is definitely a bug: on OSX you cannot browse through suggestions nor move to another, next suggestion. It is a broken feature, even if its keyboard shortcut was changed in beetween for other OS where it might work. AutoInput is used a lot in spreadsheet use cases, i.e. in companies and NGO which might have a negative impact on perception of LO as a truly full-featured office suite, as well as this makes a function in OSX unaccessible, which makes this feature non-existing. So, to ask clearly: what is the correct shortcut for all OS: - accessing the list of all possible autoformat suggestions - jumping to the next autoformat suggestion This is why I chenged it from enhancement to a normal priority bug. Slovenian enterprise users are crying to get this back working as before. Thanks, m.
After more than 18 months nothing changed. This bug is the reason, why we and many others still run on OOo.
Any updates?
Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64
Status should be NEW not REOPENED.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Libreoffice 5.0.4.2 OS X - The bug is still there. It is still not possible to effectively navigate through autocompletion alternatives with TAB/Ctrl-TAB.
Version: 5.0.4.2 Build-ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Mac OSX 10.11.2 I agree with comment#27: still not working.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Libreoffice 5.2.5.1 OS X - The bug is still there. It is still not possible to effectively navigate through autocompletion alternatives with TAB/Ctrl-TAB.
Can confirm comment 30 for version 5.3.0.3. Still not possible to navigate through alternative cell content.
The Alt-Tab-Down arrow combination works to open the list of previously entered strings, but neither Ctrl-Tab, nor Tab, do anything.
Tested on Version: 5.2.7.2 Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 Threads CPU : 2; Version de l'OS :Mac OS X 10.12.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
CTRL+TAB, CTRL+SHIFT+TAB, ALT+DOWN + Navigation with the up and down key all work here. I'll close this bug as this seems to work as intended. Kohei already made clear that this was a deliberate change.
I can't accept this. Kohei wrote something 2011 which is long time ago and does not fix the bug.
(In reply to Kohei Yoshida from comment #14) > Unfortunately the normal shortcut key scheme doesn't apply in this case, > because these key inputs are handled as direct key input i.e. like typing > 'a', 'b', 'c, etc into a cell, and you can't assign a shortcut key to direct > key inputs. > > Of course it's not impossible to make this configurable, but it may create > more problems and makes the code less maintainable (the code that handles > direct key inputs is very fragile). And quite frankly I don't know if it's > worth the risk. it seems that this bug qualifies for a WONTFIX status. as Kohei said, a fix would probably create more serious side effects and would not be worth it.
(In reply to Markus Mohrhard from comment #34) > CTRL+TAB, CTRL+SHIFT+TAB, ALT+DOWN + Navigation with the up and down key all > work here. I'll close this bug as this seems to work as intended. > > Kohei already made clear that this was a deliberate change. Tested against: Version: 5.3.4.2 Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3 Threads CPU : 4; Version de l'OS :Mac OS X 10.12.6; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR.UTF-8); Calc: group Ctrl-Tab is a reserved combo on OSX for switching between workspaces. Ctrl-Shift-Tab does nothing whatsoever. Alt-Down displays the list of available strings, with navigation in the list possible using further up/down presses. If I replace the Ctrl key with the Cmd key: Cmd-Tab is a reserved combo on OSX for calling up and switching between a list of active applications from left to right Cmd-Shift-Tab does the same thing as Cmd-Tab in revers order (right to left) So these do not work as intended, unless there is some other keyboard combo definition which does work and of which I am unaware.
*** Bug 34317 has been marked as a duplicate of this bug. ***
Putting it back to RESOLVED NOTABUG as Markus did.
Let's mark all issues as notabug and then LO will have no bugs whatsoever!