Description: In Navigator view, while an entry is being dragged, all its respective bar positions are kept displayed despite current dragged positions do not match any more. Steps to Reproduce: Issue may be document specific – Document sample – 1. Show Sidebar (Ctrl F5) => Styles => All Styles; 2. Enter one-lined expressions (at least four, in order to be descriptive), apply to each of them any style that can be displayed in Navigator as entry, e.g any style from Headung 1–10; 3. In Navigator view, focus on an listed entry, left-click it and drag it alternatively up then down. Actual Results: See LibreOffice_Writer_v.6.1.4.2_Linux_Navigator_dragged_bar_positions.png. In Navigator view, positions at which entry was dragged are kept on displayed despite current position cannot be positioned at many positions at the same time. Expected Results: One position bar to be displayed at a time. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.1.4.2; Build ID: 6.1.4.2-1.fc29; CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Created attachment 148493 [details] Navigator view – Dragged bar positions
We have to have Content navigation view activated to be able to drag and drop. I could not reproduce the problem. I changed the color theme to Breeze Dark to match the screenshot (tested with kde5). I also tried changing the GTK3 theme to Breeze Dark and tested with gtk3, but no problem. In actuality, I see no bars whatsoever at any point while dragging. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9c5d33e3c9e4a680af61a9e7af8fa73d08b33834 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 28 March 2019
Reported against Last Fedora; for those ones that will notice it. no time will be wasted, just like a previous one.
I have seen this behavior before but am unable to repro with any release installs or dev builds I have at this time. I only get the drop bar when using gtk2 and win VCL backend. Version: 6.3.0.0.alpha0+ Build ID: e2f227fa6f0ae0588ac033f772fb5dda5433bda4 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Version: 6.2.0.2 (x64) Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Please test with 6.2.x If you are unable to do it otherwise, use an appimage: https://libreoffice.soluzioniopen.com/ Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
appimage – Version: 6.2.2.2; Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US; Calc: threaded Two new cases appeared: 1. Position bar is not even exhibited when keeping a unique direction axis while dragging a header through headers tree. 2. Once case 1. has been observed, keep on the header grabbed, then from now drag it in the opposite direction axis compared to the one that prevailed in case 1. and keep unchanged that new direction. Each one of the crossed headers will be then marked with a persistent position bar.
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Version: 6.3.2.2; Build ID: 6.3.2.2-1.fc31; CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US; Calc: threaded Not reproducable any more with that version.