Bug 55846 - Comboboxes aren’t displayed when the toolbar is vertical
Summary: Comboboxes aren’t displayed when the toolbar is vertical
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyMedium, needsDevEval, topicDebug, topicUI
: 45948 52518 87411 120843 (view as bug list)
Depends on:
Blocks: Vertical-Toolbar Button-Controls
  Show dependency tree / graph
 
Reported: 2012-10-10 17:57 UTC by Al McAusland
Modified: 2024-07-09 14:43 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

Attachments
A view of the Formatting toolbar docked to the left of the Writer window, with the mouse pointer positioned over the Font Size icon (36.90 KB, image/png)
2012-10-10 17:57 UTC, Al McAusland 		Details
Findbar's dropbox isn't shown neither (9.56 KB, image/jpeg)
2013-01-21 09:18 UTC, Xisco Faulí 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Al McAusland 2012-10-10 17:57:51 UTC 
Created attachment 68414 [details]
A view of the Formatting toolbar docked to the left of the Writer window, with the mouse pointer positioned over the Font Size icon

Problem description: 
When the Formatting toolbar is positioned vertically, the Font Size drop-down box does not expand to show the available size options.

Steps to reproduce:
1. Drag the Formatting tool bar to the right or left side of the Writer window until it docks.
2. Click the mouse pointer on the Font Size icon.

Current behavior:
When the Formatting toolbar is positioned/docked horizontally, 

Expected behavior:

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1
Comment 1 Al McAusland 2012-10-10 21:09:38 UTC 
Apologies that some fields in the bug description are incomplete, due to user (i.e. MY) typing error!

Those fields should read:

Current behavior:
When the Formatting toolbar is positioned/docked horizontally, the Font Size drop-down list expands correctly. When docked vertically, the Font Size drop-down list does not expand at all.

Expected behavior:
The Font Size drop-down list should expand whether the Formatting toolbar is vertically or horizontally positioned/docked.

Platform (if different from the browser):
Windows XP Pro SP3
Comment 2 Rainer Bielefeld Retired 2012-10-31 05:39:34 UTC 
[Reproducible] with "LibreOffice 3.6.3.2” German UI/ German Locale [Build-ID: 58f22d5]" on German WIN7 Home Premium (64bit) 

Problem is not limited to Writer, same with Calc and DRAW.

Not a new problem, inherited from OOo (I checked OOo 3.1.1)

In horizontal toolbar position a selector for font size is visible, in vertical position a 'Font Size'  icon is visible what does nothing.

Something what works fine with "LibreOffice 3.6.3.2” German UI/ German Locale [Build-ID: 58f22d5]" on German WIN7 Home Premium (64bit): 
Font Name selector In horizontal toolbar position a selector for font name is visible, in vertical toolbar position an icon ix visible, clicking it will open the Font dialog. 

An acceptable solution for the problem here would be to open the same dialog as the 'Font Name', a perfect slution would be to make appear w size selection box as we see in the horizontal toolbar.

The acceptable solution should be an easy hack.
Comment 3 Miklos Vajna 2012-11-05 11:21:53 UTC 
I believe we should not have easy hacks without code pointers. :-)
Comment 4 Caolán McNamara 2012-11-05 13:43:25 UTC 
I believe that's the "FontSizeBox" http://opengrok.libreoffice.org/search?q=&project=core&defs=FontSizeBox
Comment 5 Faisal Menawer 2012-11-27 09:08:30 UTC 
I think this function do something http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunocontroller.cxx#361
Comment 6 Xisco Faulí 2013-01-21 09:18:03 UTC 
Created attachment 73365 [details]
Findbar's dropbox isn't shown neither
Comment 7 Xisco Faulí 2013-01-21 09:19:29 UTC 
Same behavior when the find bar is set to the left/right side vertically. See attached image.
Comment 8 Jan Holesovsky 2013-02-01 17:15:04 UTC 
Al: So what you are searching for is controlled in method ImplToolItem::GetSize(), in file vcl/source/window/toolbox2.cxx:

        if ( mpWindow && bHorz )
        {
            // get size of item window and check if it fits
            // no windows in vertical toolbars (the default is mbShowWindow=sal_False)
            Size aWinSize = mpWindow->GetSizePixel();
            if ( !bCheckMaxWidth || (aWinSize.Width() <= maxWidth) )
            {
                aSize.Width()   = aWinSize.Width();
                aSize.Height()  = aWinSize.Height();
                mbShowWindow = sal_True;
            }
            else
            {
                if ( mbEmptyBtn )
                {
                    aSize.Width()   = 0;
                    aSize.Height()  = 0;
                }
            }
        }

If you remove the bHorz above, and make sure that the code always execute 'mbShowWindow = sal_True' above (removing the width condition), you'll see the controls even in the horizontal toolbars.

The problem is though that their width will not adapt; will you be able to find out how to fix that, or do you need more pointers?

Hope that helps :-)
Comment 9 Jorendc 2013-02-17 12:15:58 UTC 
*** Bug 52518 has been marked as a duplicate of this bug. ***
Comment 10 Jorendc 2013-02-18 09:55:47 UTC 
*** Bug 45948 has been marked as a duplicate of this bug. ***
Comment 11 Michael Meeks 2013-04-05 10:15:30 UTC 
IMHO there are a few potential fixes for this bug - whereby we launch the right dialog + tab for these icons when they are in left docked mode.

We already have a mode where we can make 'fat / wide' toolbar which can be docked on the left - simply by re-sizing it's edge. IMHO it adds nothing useful to enforce that and/or make the toolbar by default waste a ton of screen real-estate / h-space by making it as wide as the maximum width of an embedded combo / selection widget. If we want to compact the toolbar we can already do that by manual re-sizing as discussed :-)

Of course - IMHO the most ideal outcome is to popup the selection widget neatly next to the button when it is pressed so that we don't get this dialog thrash, but a neat toolbar experience when it is clicked.

AFAICS Faisal's link was good for that.
Comment 12 How can I remove my account? 2013-12-23 09:04:36 UTC 
Let's not keep bugs assigned for too long without any indication of progress.
Comment 13 bfoman (inactive) 2014-01-08 22:35:07 UTC 
Back to NEW as bug lost owner.
Comment 14 Joel Madero 2014-02-27 23:05:36 UTC 
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise
Comment 15 Adolfo Jayme Barrientos 2014-12-18 13:37:13 UTC 
*** Bug 87411 has been marked as a duplicate of this bug. ***
Comment 16 Robinson Tryon (qubit) 2015-12-14 06:12:15 UTC Comment hidden (obsolete)
Comment 17 Björn Michaelsen 2016-01-26 18:02:33 UTC 
topicDebug is a Topic.
Comment 18 Björn Michaelsen 2016-01-26 18:04:52 UTC 
Remove skillDebug, superceded by topicDebug.
Comment 19 Joel Madero 2016-02-06 21:24:35 UTC 
Just a further update to the bug status.

Bodhi Moksha
LibreOffice 5.0.2.5

Confirmed.
Comment 20 QA Administrators 2017-05-22 13:38:35 UTC Comment hidden (obsolete)
Comment 21 Al McAusland 2017-06-11 18:08:21 UTC 
I am the originator of this bug and, as requested, I have checked if the bug still exists on a later version of LibreOffice.

My current software configuration is now LibreOffice v5.3.3.2 running on Windows 7 Pro (previously XP Pro SP3).

I can confirm that when the Formatting toolbar is docked vertically to the left (or right) of the Writer window that clicking on the Font Size icon still does not do anything, and the bug as described still exists.

Although not part of the original bug, Xisco Faulí noted in his post that the same behaviour is true when the Find bar is docked left or right. I have also checked this and the behaviour he describes also still holds true.

As an aside, I have also checked the following when the Formatting toolbar is docked vertically left or right:
- the Set Paragraph Font combo box is replaced by a filler-type icon, and clicking on the icon does not appear to do anything.
- the Font Name combo box is replaced by a text icon, and clicking on the icon launches the Character-formatting dialog box (as if Format, Character was selected from the main Writer menu), rather than displaying a drop-down list of paragraph styles.

It is just my observation, but the same problem appears to affect the following combo boxes: Set Paragraph Style, Font Name, Font Size, Find Text. The common property which they share is that they all display a list of selectable items in a drop-down list, so perhaps the problem is more generic and applies to those types of combo boxes?
Comment 22 QA Administrators 2018-06-12 02:33:25 UTC Comment hidden (obsolete)
Comment 23 Al McAusland 2018-08-25 13:54:39 UTC 
I am the originator of this bug and, as requested, I have checked if the bug still exists on a later version of LibreOffice.

My current software environment is:
LibreOffice
Version: 6.1.0.3
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 1; OS: Windows 6.1; UI render: default; 
Locale: en-GB (en_GB); Calc: group threaded

Operating System is now Windows 7 Pro SP1 (32-bit) 

I can confirm that this bug still exists in version 6.1.0.3 of LibreOffice.

The comments in my update of 2017-06-11 18:08:21 UTC  are still applicable.
Comment 24 V Stuart Foote 2018-10-24 03:31:03 UTC 
*** Bug 120843 has been marked as a duplicate of this bug. ***
Comment 25 QA Administrators 2019-10-25 02:39:53 UTC Comment hidden (obsolete)
Comment 26 Phil 2019-10-26 07:47:46 UTC 
Still open in LO 6.3.2
Comment 27 QA Administrators 2022-03-15 03:55:36 UTC Comment hidden (obsolete)
Comment 28 Rainer Bielefeld Retired 2022-03-15 12:02:36 UTC 
😥
Comment 29 Al McAusland 2022-03-21 23:41:27 UTC 
I am the originator of this bug and, as requested in an email I received on 15/02/2022, I have checked if the bug still exists on a later version of LibreOffice.

I have tested for this bug in the following environment:

Operating System: Ubuntu 18.04.6 LTS 64-bit running in a VirtualBox VM
LibreOffice:
Version: 7.3.1.3 / LibreOffice Community [AppImage]
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 1; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

I can confirm that this bug still exists in version 7.3.1.3 of LibreOffice.
Comment 30 QA Administrators 2024-03-21 03:15:07 UTC Comment hidden (obsolete)
Comment 31 Al McAusland 2024-07-09 14:43:10 UTC 
Just an update to confirm that this bug still exists.

I have tested for this bug in the following environment:

Operating System: Ubuntu 20.04.6 LTS running natively on a Lenovo E15 Gen 3 laptop

LibreOffice:
Version: 24.2.4.2 (X86_64) / LibreOffice Community [AppImage]
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded