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

[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.

I believe we should not have easy hacks without code pointers. :-)

I believe that's the "FontSizeBox" http://opengrok.libreoffice.org/search?q=&project=core&defs=FontSizeBox

I think this function do something http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunocontroller.cxx#361

Created attachment 73365 [details]
Findbar's dropbox isn't shown neither

Same behavior when the find bar is set to the left/right side vertically. See attached image.

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 :-)

*** Bug 52518 has been marked as a duplicate of this bug. ***

*** Bug 45948 has been marked as a duplicate of this bug. ***

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.

Let's not keep bugs assigned for too long without any indication of progress.

Back to NEW as bug lost owner.

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

*** Bug 87411 has been marked as a duplicate of this bug. ***

topicDebug is a Topic.

Remove skillDebug, superceded by topicDebug.

Just a further update to the bug status.

Bodhi Moksha
LibreOffice 5.0.2.5

Confirmed.

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?

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.

*** Bug 120843 has been marked as a duplicate of this bug. ***

Still open in LO 6.3.2

😥

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.

Dear Al McAusland,

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