Created attachment 170820 [details] Style preview problems Style preview doesn't reflect how style are arranged, when user click on any style it will be moved to be viewed at first item, this should be when user select a text with a style and that style is not visible then it makes sense to show it as first item but not when a user click on an already shown style in styles preview. Scrolling (by mouse wheel) down/up doesn't show all styles, and scroll top and down buttons behave weirdly (they skip some styles). See attached video for more info. Operating System: Manjaro Linux KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.4.105-1-MANJARO OS Type: 64-bit Graphics Platform: X11 Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 4566bcbf03c1b7b0c1ce3a83fee1d195f0ff7059 CPU threads: 2; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-03-22_14:46:06 Calc: threaded
I confirm it with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 807d059d99e7b99fe45a712428befa17ffa44858 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Additional problem: You can move the list up with keyboard arrow, but not with clicking arrow up in toolbar (but of course this might be a different bug report)
*** Bug 142366 has been marked as a duplicate of this bug. ***
*** Bug 144581 has been marked as a duplicate of this bug. ***
Scrolling was fixed in bug 143391. Scrollbar arrows also work, so the problem mentioned in comment 1 is gone. I will change the summary to be about the topic of styles moving around when selecting. I will make this a UX topic and set back to unconfirmed, because I think it was a deliberate decision to make the preview behave like this.
(In reply to Buovjaga from comment #4) > I think it was a deliberate decision to make the preview behave like this. What I could imagine causing of issue is the application-driven selection, eg. after pressing enter on a H1 you get Text Body. And this item needs to be highlighted consequently. But the style also changes when you ally H1 to a text. So we need a conditional update of the list only when the actual item is out of the view. => NEW
This is fixed in: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 5b2848413883565c48d312c96daf8fbca25405d8 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-10-11_23:38:53 Calc: threaded Marking as "Works For Me".
Actually, I am reopening it because the selected style does _not_ jump to the beginning of the row when using GTK3: Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: c7500945fc5d5bd2130a2d38be0bd4b15445cd90 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ...but it _does_ jump to the beginning of the row when using the generic VCL pluging (i.e. with the option SAL_USE_VCLPLUGIN=gen): Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: c7500945fc5d5bd2130a2d38be0bd4b15445cd90 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: x11 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded So it looks like the issue is confirmed in the following VCL plugins: - gen - win - kf5
So that is the problem of our implementation of IconView widget (vcl/source/treelist/iconview.cxx). Gtk3 uses it's own native system widget.
(In reply to stragu from comment #7) > Actually, I am reopening it because the selected style does _not_ jump to > the beginning of the row when using GTK3: The correct behavior it should never put the selected item ito first position, because it's already visible and selected so why should it be moved ?
Dear medmedin2014, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug