I did the following with LO maximized:
1. New Text Document.
2. Insert table.
3. With cursor in table, open Styles and Formatting in Sidebar.
4. Click on Paragraph Styles icon in Sidebar.
5. Click on Style Category dropdown at bottom.
List opens upwards.
6. Click on Character Styles icon in Sidebar.
7. Click on Style Category dropdown at bottom.
List opens downwards.
This also affects Frame, Page, and List.
Happens for anything that has a toolbar docked at the bottom i.e. bullets and numbering.
If the window is not maximized then the dropdown open downwards for everything depending on how far away the window is from the bottom of the screen.
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Thank you for filing the bug, but unfortunately i wasnt able to reproduce it with 4.4.2 on Windows 7.
Is it possible for you to do a screencast showing the steps to reproduce this bug. There are free screencast software including camstudio or screencast-o-matic.com.
Thinking some more, can you send a screenshot of what Tools > Options > View looks like first.
Created attachment 115104 [details]
screenshot of Tools Options View
Created attachment 115105 [details]
screenshot of Style Category dropdown
Quite interesting screenshot. Which Windows version are you running and had you noticed this same behaviour in previous version.
I'm running Windows Vista 64.
I don't know if it was in a previous version. I had noticed it before but could never reproduce it until it happened again and that's when I realised that it was in instances with the toolbar at the bottom.
There is bug 90020 where my context menu disappears behind the taskbar and bug 89914 where one bookmark also disappears behind the taskbar. I'm guessing these are confined to Vista as well.
Well you can give older versions a try in the following links without the need to install them and see if it can be reproduced there as well.
Reproducible in 126.96.36.199, 188.8.131.52, and 184.108.40.206 portable versions.
4.1.6 had the bug with and without the Sidebar.
Well the drop down should open downwards if the window has enough space between it and the taskbar, but for some strange reason it must be thinking that there is. I've asked another QA team member to check this issue on Windows XP and couldnt confirm it there either, so this likely is a Windows Vista only issue.
Created attachment 115369 [details]
screenshots of lists opening up and down on vista
With LibreOffice 220.127.116.11 running on Vista, I see the behaviour which
However the lists seem to me to open in the correct directions: as I
extend the Writer window down to successively lower positions on the
desktop the long list (categories of paragraph styles) opens downwards
and then upwards and then the short list (categories of character
styles) opens downwards and then upwards. I have tried to capture the
screenshots so that each change from open-downwards to open-upwards is
triggered by a small change in the position of the bottom edge of the
Am I misunderstanding something?
Can you try it with the window maximized with the different styles--Paragraph, Character, Frame, Page, and List. You should see that Paragraph is the only one that opens upwards when there is a toolbar at the bottom.
With LibreOffice window maximized and tables toolbar showing at the
bottom of the screen, I see:
(*) The list of paragraph styles, which has 13 entries, opens upward.
(*) The four other list of categories, which have 5 entries, open
downwards. Bottom of the lists are just a few pixels above the
bottom of the application area of the desktop.
A less tall toolbar, like the search toolbar, brings the control for
the list of style categories closer to the bottom of the application
area, and all lists of style categories open upward.
So, the behaviour seems to be: open downward if there is enough room
above the bottom of the document area of the desktop, otherwise open
upward. LibreOffice on Linux seems to follow the same rule.
I still find this reasonable. Indeed, it seems that always opening
downward could result in something like "context menu disappears
behind the taskbar". (Just going by what I read in this report; I
cannot look at bug 90020 as I am off-line as write this.)
What better rule do you propose for choosing the direction in which a
drop-down list is drawn?
I maybe should have worded my inital description better. The issue I have is the dropdown opens downward instead of upward while the application is maximized. The screenshot in attachment 115105 [details] shows just the top of Custom Styles with the rest disappearing behind the taskbar. With the Find toolbar the list still opens downward. I do have the Status Bar on. With it off, the list opens upward with either the Table or Find toolbar.
From what you've said, it sounds like the each control determines the distance and makes a decision to open up or down, whether that be the one we are discussing, buttons on toolbars, or context menus.
I could suggest introducing a check on whether or not the application is maximized but that could be messy having to know which controls should do what, where, and when. The reality is that Vista is EOL in 2017 and its users make up only a small percentage of Windows usage--and how much of that percentage uses LO.
I haven't tried 5.0. I was told that there are some stylistic differences.
I am sorry to be slow catching on. I think, then, that I am simply
seeing behaviour different from what you see.
Is it possible for you to try a newer version of LibreOffice?
I have tried master over the past few days. It still does it. I thought perhaps there might have been slight changes to heights between things but that was wishful thinking.
As a workaround, instead of maximizing the window, the alternative is to size the window to be as big as the screen or get a bigger monitor.
I have tried two older versions of LibreOffice:
(*) 18.104.22.168, as per version field of the report:
Build ID: 40ff705089295be5be0aae9b15123f687c05b0aCOPY HELP>ABOUT HERE
(*) 22.214.171.124, as per description
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
In each, dropdown lists seems to me to work correctly.
My Windows is a 32-bit version:
Windows Vista(TM) Home Premium
Copyright (c) 2007 Microsoft Corporation. All rights reserved.
Service Pack 2
and this is one possible reason for my different results.
I do not know what else I can try. Suggestions welcome.
I was able to achieve slightly different results depending on what Icon size and style and/or scaling was used.
I changed scaling down 1%.
Icon size: Automatic
Still opens downward but now Custom Styles is fully visible.
I asked some Vista users to test the bug. Walter Moore says:
I tried this and everything works correctly. I tried it with taskbar
hidden and taskbar fixed. No error.
(In reply to Terrence Enger from comment #18)
> I asked some Vista users to test the bug. Walter Moore says:
> I tried this and everything works correctly. I tried it with taskbar
> hidden and taskbar fixed. No error.
Hi, I am one of the Vista users you contacted. Read all the comments on this bug and couldn't reproduce it. Running LibreOffice 126.96.36.199 (build id 88805f81e9fe61362df02b9941de8e38a9b5fd16, locale PT-BR) on Windows Vista SP2 64 bits.
Maybe if @Gordo could try running a portable updated version, as I tried with his reported version (188.8.131.52) at the link @Yousuf provided (http://downloadarchive.documentfoundation.org/libreoffice/old/184.108.40.206/portable/), and still couldn't reproduce it.
Well, it turns out that it is my graphics cards. I have two AMD/ATI Radeon HD 4870 cards and have it set to extended desktop. It doesn't matter which desktop LO is on, it still responds the same way. With the other desktop disabled LO doesn't have the problem.
My apologies, I should have realised it sooner.
Having two graphics cards and extended desktop makes this a rather
special configuration. I have added this bug to
(In reply to Terrence Enger from comment #21)
> Having two graphics cards and extended desktop makes this a rather
> special configuration. I have added this bug to
> "QA/BugTriage/Specific configurations"
Wow, I never saw that one! It is basically the same as my HardBugs: https://wiki.documentfoundation.org/QA/BugTriage/HardBugs
Noting that this bug is still "unconfirmed", I
Created attachment 126268 [details]
PDF file with screen shots for reproducing bug
(In reply to Lars Jødal from comment #23)
> Noting that this bug is still "unconfirmed", I
Oops, here comes the full report...
Noting that this bug is still "unconfirmed", here are my observations of reproducing the bug.
a) It only seems to apply to systems with more than one monitor. I was able to reproduce the bug on a two-monitor system, but disabling the second monitor, the bug could no longer be reproduced.
b) The bug seems to depend on the distance to the bottom of the screen. It looks like the menu system is aware of the bottom of the screen, but not always aware of the top of the Windows taskbar.
How to reproduce (quite similar to Gordo's original list):
1. Use two-monitor Windows system.
2. New Writer document. Maximize to full screen.
3. Make a toolbar active at the bottom, e.g. <ctrl>-F for "find" toolbar.
4. In sidebar, choose "Styles and Formatting".
5. Choose "Character styles" (not-too-long menu) and click on the bottom menu. The menu extends down below the Windows taskbar.
6. If you instead use "Paragraph styles", then the menu is longer, and the menu opens upwards, avoiding problems.
See attachment for screenshots.
Bug 93466 and bug 100696 seems to be variants of the same problem.
My configuration was LO version 220.127.116.11 on Windows 10, two-monitor system, both screens of equal size (1920 x 1080 pixels). But as reported in bug 100696, I have seen a very similar problem with Window 7 on a two-screen system with different screen sizes.
Yeah, let's set to NEW.
*** Bug 100696 has been marked as a duplicate of this bug. ***
I have removed "Vista" from the title of the bug, since it can be reproduced on other Windows systems also (see comment 24 and comment 24).
** Please read this message in its entirety before responding **
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Created attachment 138035 [details]
Screenshot showing pop-up menu extending behind Windows taskbar
The bug is still present in current version 18.104.22.168, as well as in development version 22.214.171.124.alpha0+ (master from 2017-11-27). However, change of the menu dialogues have invalidated some of the steps to reproduce, so here follows a new description with a more general example.
1. Use two-monitor Windows system.
2. New Writer document. (Full screen not necessary)
3. Fill the documents with enough lines (empty or with text) that some lines are near the bottom of the screen.
4. Identify a line in the document about 7 cm / about 2.7 inches from bottom of the screen, i.e. distant enough that the pop-up menu (size about 6.1 cm / 2.4 inches) can fit above screen bottom, but not above Windows taskbar (height about 1 cm / 0.4 inches).
5. Right-click on this line to open pop-up menu.
Behaviour: Pop-up menu will open downwards and extend behind Windows taskbar. Example shown in attachment.
Expected behaviour: Pop-up menu should always open in a way where it is free of the Windows taskbar.
Admittedly, the choice of the line (step 4) may take a bit of experimentation. Still, the 7 cm is just an example, the interval has a width corresponding to the height of the Windows taskbar. Once again, please note that the bug applies applies only to a configuration with two (or more?) monitors, not single-monitor configuration.
Guess: I notice that the Windows taskbar is only shown on one of the monitors. Perhaps LO is fooled by the fact that there is a little more space on one monitor than the other?
I have (once again) edited the title of this bug to better reflect the root of the problem. See my description in comment 30.
Still present in LO 126.96.36.199
Version: 188.8.131.52 (x64)
Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
CPU tråde: 4; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: GL; VCL: win;
Lokalisering: da-DK (da_DK); Sprog for brugergrænseflade: da-DK