Created attachment 39122 [details] screenshot of the tools not accessible in red System/Architecture: Mac OS X 10.5.8 Intel LibreOffice version: 3.3.0 When dragging toolbars which have fields or submenu like Picture in Impress, some elements are no more accessible.
Can you please specify more what you mean by 'are no more accessible'? It is impossible to click on them? Or?
(In reply to comment #1) > Can you please specify more what you mean by 'are no more accessible'? It is > impossible to click on them? Or? You may click on them of course, but it has no effect. You cannot view the submenu for colors or the field and the arrows for transparency as when they are positioned horizontally. Screenshots attached.
Created attachment 39446 [details] Sub menu color when positioned horizontally Not viewed when clicking on the color menu when it is positioned vertically
Created attachment 39447 [details] Transparent field and arrows when positioned horizontally Not viewed when clicking on transparent icon when it is positioned vertically
Do you see the same still in beta 3?
(In reply to comment #5) > Do you see the same still in beta 3? Sub menu color expands now. The reminder does not expand. A screenshot showing the difference between the toolbar when placing horizontally and vertically is attached.
Created attachment 40427 [details] Comparison horizontal/vertical picture toolbar in impress
[Reproducible] with "LibreOffice 3.3.0 RC1 - WIN XP German UI [OOO330m17 (build 3.3.0.1". Because no precise version information from reporter available I set this one in picker. Also a Prolbem in CALC and WRITER, so general UI problem. It seems that pulldowns or icons with pulldowns have problems in vertically adjusted toolbars, for example format toolbar / character size. I generally do not use vertical toolbars since OOo 1.4, but users with widescreen monitors might use that, and it's very visible problem, so I will nominate this one as a blocker. @Cédric: May be we are lucky and the problem will have been solved with the fix for Bug 32172?
Also a problem with OOo 3.4-dev and OOo 3.1.1, I become a little doubtful concerning my blocker classification.
(In reply to comment #8) > I generally do not use vertical toolbars since OOo 1.4, but users with > widescreen monitors might use that, and it's very visible problem, so I will > nominate this one as a blocker. Well, I don't really agree having that one as a blocker: this may even not be a regression and people still can use the toolbars. This can be fixed in a micro release. > @Cédric: > May be we are lucky and the problem will have been solved with the fix for Bug > 32172? No it's completely unrelated code.
Blocker -> Normal, hasn't been a big problem for OOo, so here it isn't a blocker, too.
Even toolbar Format has problem in vertical position. And this bug is duplicate for bug 35000
*** Bug 35000 has been marked as a duplicate of this bug. ***
Quick test with "LibreOffice 3.4.2 - WIN7 Home Premium (64bit) Spanish UI [OOO340m1 (Build:203)]" still showed the problem. Visible icons work fine, but if Toolbar is too long "context Menu" does not work, no picker appears For WRITER character color, background, ... But that "no picker appears" is something different, also is a problem with horizontal docked toolbar I also still see reported Impress / DRAW picker problems.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
*** Bug 47714 has been marked as a duplicate of this bug. ***
*** Bug 39745 has been marked as a duplicate of this bug. ***
*** Bug 48631 has been marked as a duplicate of this bug. ***
Just for an update, on master sources updated today, I reproduce these kind of problems. I noticed no specific logs on console when the problem occured.
I am seeing the same problem with Version 3.6.1.2 (Build ID: e29a214) on Ubuntu 11.04 (x86). In Impress or Writer, clicking on the little black dropdown arrow of the "Font Color" toolbar icon has no effect. No dropdown menu appears. The same is true for some of the other toolbar icons I tried (e.g. arrow style). Others like "Font Size" or "Font Name" work just fine. Contrary to the other reports here, it doesn't matter weather the toolbar is attached horizontally or vertically. The dropdown never works. I tried a complete re-install and also deleted .config/libreoffice/3/user without success. This makes LibreOffice basically unusable for me at the moment.
@ Frank Winklmeier Thanks for additional testing. Please, do not change "Version" and "Platform"
I still see the same problem that I reported in comment #20 with Version 3.6.2.2 (Build ID: da8c1e6). It makes LibreOffice completely unusable on Ubuntu for me. Please let me know in case you need more information.
May be we have to find different solutions for each affected button / icon / selector? I reduce this bug to 1 icon from original report @Michèle Garoche Can you please submit separate bugs for each separate problem and list these bugs in "Bug 56602 - [Task]: Make toolbar icon function available for vertical toolbar arrangement"? I hope so we can get start fixing these problems a little quicker.
@Rainer Bielefeld: I observe this problem for both vertical and horizontal toolbars. Should I submit a new bug report for this or is it the same issue?
Confirmed with: LO 4.2.0.0.alfa0 Build ID: 2013-06-24 own debug build Windows 7 Professional SP1 64 bit Still an issue.
When using vertical toolbars, the "Font Name" and "Font Size" (and probably other) buttons do not work as triggers for drop-down menus, as they do in horizontal mode. Font Name at least opens the "Character" dialogue, which is not the expected behavior. Font Size does nothing at all. Feels like vertical toolbar users are second-class citizens, which is curious given the prevalence of small widescreen monitors on laptops in which vertical space is at a premium and two-up is not practical. Using 4.1.2.3 on Mac OS X 10.9.
Restricted my LibreOffice hacking area
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
(In reply to QA Administrators from comment #28) > Please read this message in its entirety before responding. > > Your bug was confirmed at least 1 year ago and has not had any activity on > it for over a year. Your bug is still set to NEW which means that it is open > and confirmed. It would be nice to have the bug confirmed on a newer version > than the version reported in the original report to know that the bug is > still present -- sometimes a bug is inadvertently fixed over time and just > never closed. > > If you have time please do the following: > 1) Test to see if the bug is still present on a currently supported version > of LibreOffice (preferably 4.2 or newer). > 2) If it is present please leave a comment telling us what version of > LibreOffice and your operating system. > 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave > a short comment telling us your version and Operating System > > Please DO NOT > 1) Update the version field > 2) Reply via email (please reply directly on the bug tracker) > 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning > that is not appropriate in this case) > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > + > LibreOffice is powered by a team of volunteers, every bug is confirmed > (triaged) by human beings who mostly give their time for free. We invite you > to join our triaging by checking out this link: > https://wiki.documentfoundation.org/QA/BugTriage > > There are also other ways to get involved including with marketing, UX, > documentation, and of course developing - > http://www.libreoffice.org/get-help/mailing-lists/. > > Lastly, good bug reports help tremendously in making the process go > smoother, please always provide reproducible steps (even if it seems easy) > and attach any and all relevant material Hi, At the time I reported the bug, I was using Win XP SP3. Now I use Ubuntu Linux 14.04. LO is now is version 4.3.1.2. The bug concerning increase or decrease font is not present in this version. (In reply to QA Administrators from comment #28) So, as far as I am concerned, this bug can is resolved. Carolus > Please read this message in its entirety before responding. > > Your bug was confirmed at least 1 year ago and has not had any activity on > it for over a year. Your bug is still set to NEW which means that it is open > and confirmed. It would be nice to have the bug confirmed on a newer version > than the version reported in the original report to know that the bug is > still present -- sometimes a bug is inadvertently fixed over time and just > never closed. > > If you have time please do the following: > 1) Test to see if the bug is still present on a currently supported version > of LibreOffice (preferably 4.2 or newer). > 2) If it is present please leave a comment telling us what version of > LibreOffice and your operating system. > 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave > a short comment telling us your version and Operating System > > Please DO NOT > 1) Update the version field > 2) Reply via email (please reply directly on the bug tracker) > 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning > that is not appropriate in this case) > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > + > LibreOffice is powered by a team of volunteers, every bug is confirmed > (triaged) by human beings who mostly give their time for free. We invite you > to join our triaging by checking out this link: > https://wiki.documentfoundation.org/QA/BugTriage > > There are also other ways to get involved including with marketing, UX, > documentation, and of course developing - > http://www.libreoffice.org/get-help/mailing-lists/. > > Lastly, good bug reports help tremendously in making the process go > smoother, please always provide reproducible steps (even if it seems easy) > and attach any and all relevant material
(In reply to Carolus from comment #29) > So, as far as I am concerned, this bug can is resolved. Great! Status -> Resolved: Works for me