Description: In prior versions of Libre Office, if we are editing a character's position (e.g., to superscript or subscript), then in the Character > Position dialog box, previously the keyboard up-arrow would go up to select superscript, while the down-arrow key would go down to subscript. With the current version, this seems to be reversed: up-arrow goes down to subscript, while down-arrow goes up to superscript. Very counter-intuitive. Steps to Reproduce: 1. In any component (Writer, Calc, or Impress) create and select some text. 2. Open the Character dialog (e.g., via keys Alt-O-H-Enter) and select the Position tab. 3. On the keyboard, press up-arrow. Actual Results: The active field goes down (to subscript). Expected Results: The active field should go up (to superscript). Reproducible: Always User Profile Reset: No Additional Info: Likewise: Pressing the down-arrow key sends the active field up (to superscript).
So, this is really weird... I can reproduce it in Versió: 6.1.3.1 ID de la construcció: 1:6.1.3~rc1-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded and Version: 6.1.4.0.0+ Build ID: f1e09253316d9db39b7adab6d31e759c09de3406 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded ( latest commit in bibisect-linux64-6.1 ) but not in Version: 6.1.0.0.alpha1+ Build ID: 3a801799536e6870f2fb111b1cc00b9575a35a39 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group ( oldest commit in bibisect-linux64-6.2 ) Bisecting it in bibisect-linux64-6.1, it points to https://cgit.freedesktop.org/libreoffice/core/commit/?id=23fa8a6ed05386ce6e9997747b416279f46ddd5f author Caolán McNamara <caolanm@redhat.com> 2018-06-13 14:40:15 +0100 committer Caolán McNamara <caolanm@redhat.com> 2018-06-13 21:53:15 +0200 commit 23fa8a6ed05386ce6e9997747b416279f46ddd5f (patch) tree 923f80b06e25f68ac8947a86c2ad39ca51e2928a parent d97ac904b7a6e77cc46daf08a9b5f9628ff02ee5 (diff) weld SvxCharPositionPage @Caolan, any idea why I can reproduce it in 6-1 but not in 6-2 ?
Also reproduced in Versión: 6.1.2.1 Id. de compilación: 65905a128db06ba48db947242809d14d3f9a93fe Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded
possibly https://cgit.freedesktop.org/libreoffice/core/commit/?id=fe0ad0b9b8d8897e4b7ca5bc6e0eedcd2c96e6fd fixed it in master and needs to be added to 6-1
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9e83fe5ec5550a02f8ccd9caaf0fc9b0ad35902 tdf#120651 have to sort radiogroup by tab position It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backport to 6-1 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e67ca59e293c4dd37795150cf871e36ca1affb76&h=libreoffice-6-1 tdf#120651 have to sort radiogroup by tab position It will be available in 6.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.1.4.0.0+ Build ID: f6d13aa7e1f0dd3baafc70795008722b46867b76 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Caolán, Thanks for fixing this!!
Also confirmed in 6.1.4.2 (x64). Adding my thanks!