Download it now!
Bug 125508 - Frames around dialog widgets
Summary: Frames around dialog widgets
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Hardware: All All
: medium trivial
Assignee: Caolán McNamara
Whiteboard: target:6.4.0
Depends on:
Reported: 2019-05-26 20:26 UTC by Thorsten Wagner
Modified: 2021-05-28 09:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screenshot (59.72 KB, image/png)
2019-05-26 20:26 UTC, Thorsten Wagner
Screenshot from LO 5.4.7 (25.88 KB, image/png)
2019-10-11 18:57 UTC, Thorsten Wagner

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Wagner 2019-05-26 20:26:14 UTC
Black frame lines are drawn around several dialog widgets (see screenshot for an example). This does not seem to be intended.

Steps to Reproduce:
(1) Open Writer

(2) Insert a table

(3) Select Table Properties / Borders

Actual Results:
Black frames are drawn around several widgets (see screenshot).

Expected Results:
No frames are drawn around any widgets.

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:
Comment 1 Thorsten Wagner 2019-05-26 20:26:56 UTC
Created attachment 151685 [details]
Comment 2 Xisco Faulí 2019-06-10 15:47:55 UTC
Thank you for reporting the bug.
Could you please try to reproduce it with a master build from ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 3 Thorsten Wagner 2019-06-11 19:47:52 UTC
Issue is still present with build from current master:

Build ID: 79d58ee14da8fbf636fb087453834abb7173d3fc
CPU threads: 8; OS: Mac OS X 10.14.5; UI render: GL; VCL: osx; 
Locale: de-DE (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 Thomas Lendo 2019-10-11 10:35:51 UTC
I don't see any difference in 6.2, 6.3 and 6.4 on Windows.
It looks like the screenshot of Thorsten.

Heiko, do you know that something was changed in the UI in the last main releases?
Comment 5 Thorsten Wagner 2019-10-11 18:57:35 UTC
Created attachment 154944 [details]
Screenshot from LO 5.4.7
Comment 6 Thorsten Wagner 2019-10-11 19:00:27 UTC
Please find a screenshot from LO 5.4.7 attached to compare
Comment 7 Heiko Tietze 2019-10-14 09:28:11 UTC
If you talk about tables, the border is around cells. Without border you don't see any table structure, which is likely not the general case. The recommended workflow is using a table style without borders.

Where else would you remove the borders?
Comment 8 Thorsten Wagner 2019-10-15 22:41:18 UTC
I am not talking about tables but dialog widgets. The Table Properties / Borders dialog is only an example for a dialog box to show the issue.

Looking at the first screenshot, there are thin gray lines around the widgets below "Presets", "User-defined", and "Position" labels. These thin lines were introduced sometimes during the LO 6 releases and are not present in LO 5 (see second screenshot).
Comment 9 QA Administrators 2019-10-16 02:31:07 UTC Comment hidden (obsolete)
Comment 10 Heiko Tietze 2019-10-16 08:27:01 UTC
(In reply to Thorsten Wagner from comment #8)
> Looking at the first screenshot, there are thin gray lines...

Got it, sorry for being slow. But I wonder if this border is part of your theme as we haven't changed anything here. And my Breeze theme on KDE doesn't show a border. Caolan, what do you think?
Comment 11 Caolán McNamara 2019-10-16 11:02:51 UTC
In the .uis those rectangular borders are GtkScrolledWindow parents for those widgets. (In this case cui/uiconfig/ui/borderpage.ui). The GtkScrolledWindows have two purposes, the obvious one of enabling scrolling of widgets, and to provide a border around widgets.

Under Mac/Windows that will be implemented with VclScrolledWindow which will Paint the border with DecorationView::DrawFrame which will attempt to use the system theming to draw it (I think) in that complicated ImplDrawFrame.

I think the middle "User Defined" element actually always had a border, through probably drawn with some different border-drawing system (classic WB_BORDER) in the past, while the other two gained border frames along the way.

I have no strong feelings on whether they should have borders or not, I think they gained a border because they are SvtValueSets which are in general scrollable, though that's optional.

If we wanted to remove the border around presets and shadows valuesets then would do that
Comment 12 Heiko Tietze 2019-10-17 12:29:52 UTC
Let's submit Caolan's patch and see if it has drawbacks.
Comment 13 Commit Notification 2019-10-17 14:33:19 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

tdf#125508 remove border frame from shadows and presets

It will be available in 6.4.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 14 Thorsten Wagner 2019-10-17 21:10:15 UTC
Unfortunately issue is not fixed for all widgets. The widget below "User-defined" has the thin gray line furthermore. This widget is used in other dialogs too, for example for text orientation in Calc's Format / Cells / Alignment dialog.
Comment 15 Caolán McNamara 2019-10-18 07:57:12 UTC
You're making this into an open ended bug with probably no end in sight.
Comment 16 Heiko Tietze 2019-10-18 09:12:42 UTC
(In reply to Thorsten Wagner from comment #14)
> The widget below "User-defined" has the thin gray line furthermore. 

This frame looks good to me and it makes sense as it separates the widget content from the canvas. How the frame is drawn depends of course on the theme; it's a light gray in my case.

I would close this bug as FIXED and open individual tickets for all places where the frame is potentially obsolete.
Comment 17 Buovjaga 2019-11-12 12:11:04 UTC
(In reply to Heiko Tietze from comment #16)
> I would close this bug as FIXED and open individual tickets for all places
> where the frame is potentially obsolete.

Indeed. Better to debate each case separately.