Bug 136943 - TOOLBAR: Can't see last font name due to font name toolbar combobox having wrong height (Win, Linux kf5/kf6 with X11)
Summary: TOOLBAR: Can't see last font name due to font name toolbar combobox having wr...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Fonts-Name-Combobox
  Show dependency treegraph
 
Reported: 2020-09-21 22:23 UTC by medmedin2014
Modified: 2024-10-15 17:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Can't see last font name (133.31 KB, image/png)
2020-09-21 22:23 UTC, medmedin2014
Details
Screenshot that shows the problem (458.76 KB, image/jpeg)
2020-09-22 15:42 UTC, Dieter
Details
List of fonts in LibreOffice 6.4.2.2 (93.30 KB, image/png)
2022-04-07 19:52 UTC, medmedin2014
Details

Note You need to log in before you can comment on or make changes to this bug.
Description medmedin2014 2020-09-21 22:23:24 UTC
Created attachment 165746 [details]
Can't see last font name

Last font name in font list cannot be read. See attached image for more info.

Version: 7.0.1.2
Build ID: 00(Build:2)
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
=7.0.1-1
Calc: threaded

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.4.64-1-MANJARO
OS Type: 64-bit
Comment 1 Dieter 2020-09-22 15:41:59 UTC
I confirm it with standard toolbar and

Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

on my notebook display. Haven't tested with external screen, but I assume, that height increased in comparison with earlier versions of LO.
Comment 2 Dieter 2020-09-22 15:42:40 UTC
Created attachment 165779 [details]
Screenshot that shows the problem
Comment 3 Dieter 2022-04-06 20:23:27 UTC
Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it back to NEW with a short reasoning, if you disagree.

*** This bug has been marked as a duplicate of bug 91130 ***
Comment 4 medmedin2014 2022-04-06 21:56:08 UTC
(In reply to Dieter from comment #3)
> Let's treat it as duplicate of bug 91130. Medmedin, feel free to change it
> back to NEW with a short reasoning, if you disagree.
> 
> *** This bug has been marked as a duplicate of bug 91130 ***

The item 91130 is just an enhancement to modify the whole list view for better usability, but this bug is regression because the combobox is there and what should be fixed is just its height to fit inside screen and using the scrollbar thumb user can reach any item in the list.
Comment 5 Dieter 2022-04-07 08:10:36 UTC
(In reply to medmedin2014 from comment #4)
> but this bug is regression because the combobox is there
> and what should be fixed is just its height to fit inside screen and using
> the scrollbar thumb user can reach any item in the list.

If you think it is a regression, please add information of (probalbly) the last version without that bug.
Comment 6 medmedin2014 2022-04-07 19:51:07 UTC
(In reply to Dieter from comment #5)
> (In reply to medmedin2014 from comment #4)
> > but this bug is regression because the combobox is there
> > and what should be fixed is just its height to fit inside screen and using
> > the scrollbar thumb user can reach any item in the list.
> 
> If you think it is a regression, please add information of (probalbly) the
> last version without that bug.

It's totally a regression, I can't point from which version this bug started to appear but if you take any old version like 6.4.2.2 you can clearly see how it looked.
Comment 7 medmedin2014 2022-04-07 19:52:05 UTC
Created attachment 179387 [details]
List of fonts in LibreOffice 6.4.2.2
Comment 8 QA Administrators 2024-04-07 03:14:26 UTC Comment hidden (obsolete)
Comment 9 Haris 2024-04-12 00:53:01 UTC
On MacOS Sonoma 14.1.2, I was unable to reproduce the bug in the following two builds:

Stable Build
Version: 24.2.2.2 (AARCH64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Master/Daily Build
Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: c4023d3ec604abfff38be2053e2989c7ec2ba8c1
CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

I tried using older LibreOffice versions but they're crashing on my MacBook Pro. Can anyone else please test this bug on Windows and/or Linux and verify if it was present in version 7.0.1.2. Thank you.
Comment 10 Haris 2024-04-12 00:55:18 UTC
Since it was verified that it was present in version 7.0.1.2, I'll change the status to RESOLVED WORKSFORME.
Comment 11 medmedin2014 2024-04-13 09:45:20 UTC
It's still reproducible on X11. But not persistent on Wayland.

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.7.0
Kernel Version: 6.8.5-1-MANJARO (64-bit)
Graphics Platform: X11

LibreOffice:
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland)
Locale: en-US (en_US.UTF-8); UI: en-US
24.2.2-2
Calc: threaded
Comment 12 Buovjaga 2024-04-18 06:32:52 UTC
Bibisected with win64-7.0. The first observable change was with 16309a9516c1f173056fc103c6428e74217c7927
weld StylesPropertyPanel

which made the height larger, but placed the box higher, so we could actually see all the items.

We arrived at the current state with 822f94e260b8351dc3459d2c05180af2de96d4c7
tdf#132435 only place menu vertically if up/down requested

It is indeed fine when I test on Linux with kf6 and gtk3 on Wayland.
Comment 13 Justin L 2024-10-15 16:48:08 UTC
Interesting that no one has provided their screen resolution for this report. I tested with 1024*576 - although the screenshots appear to be at least 1024*768.

Testing 25.2+, I could not reproduce with Ubuntu/GTK. I could barely reproduce with GEN when below vertical HIG guidelines of 800*600.
Comment 14 Buovjaga 2024-10-15 17:08:09 UTC
(In reply to Justin L from comment #13)
> Interesting that no one has provided their screen resolution for this
> report. I tested with 1024*576 - although the screenshots appear to be at
> least 1024*768.
> 
> Testing 25.2+, I could not reproduce with Ubuntu/GTK. I could barely
> reproduce with GEN when below vertical HIG guidelines of 800*600.

My Win VM is 1280x800.