Created attachment 93628 [details] screenshot showing mousewheel does not change object properties Problem description: Using mouse scrollwheel to change object properties (e.g. a shape's colour) does not work Steps to reproduce: 1. Create a new writer/impress/draw document 2. Create a new shape or fontwork object 3. Use the mouse scrollwheel to change the colour / gradient etc. Current behavior: The change is shown in the dropdown menu but does not change the object itself Expected behavior: The colour, gradient or other property should be changed when the mousewheel is used to change it -- Note, this has occurred for a while in the 4.x series but I cannot remember when this first appeared. It did previously used to work. Could somebody please check this on windows / mac to see if this is a linux ui issue or a libreoffice bug Operating System: Debian Version: 4.1.0.4 release
I am not sure if I understand this right. If I insert e.g. a rectangle shape in IMPRESS and then go to the toolbar at the top to change the area style / filing of this rectangle then I can scroll up and down with the mouse wheel, but it does not change the color. This is only to move up and down. To change the color you have to select the color (by clicking on the color). I think this is correct. It should not change immediately the color. It should change the color only after explicity selecting the color. For instance, if I want to preserve the selected color and only want to look for another color, then scrolling up and down should not change the color, otherwise if I find no better color then I have to search for the previous selected color. Did I understand your issue right? Another question: Why is your screenshot showing no color name for the line color? In my LO this color name is shown correctly. LO 4.2.0.4 (Win 8.1)
The scrolling worked in the 3.x branch so it can be assumed it is a bug and allows to change colours more easily. I do not mean scrolling once the dropdown list has opened, I mean literally placing the mouse pointer over the selector box next to fill settings, and scrolling, without actually opening the menu. As for not showing the colour name for line colour, this is because it has been left at the default colour. Maybe the windows UI handles this differently.
Thanks for your fast reply. Now I understood your issue. I unfortunately don't know whether this was working that way in the past and whether it was intended that way. Maybe somebody else can check and confirm this issue? What I can say is that it is reproducible that changing the color by scrolling with the mouse wheel does not change the color of the object itself (LO 4.2.0.4, Win 8.1). Steps done: 1. Open IMPRESS 2. Insert e.g. a rectangle from the toolbar at the bottom 3. Click on the color selection of the AREA STYLE / FILING in the Line and Filing toolbar at the top (click two times) -> keep in mind: on the color itself, not the arrow on the right 4. Use the mouse wheel to change the color Result: The color in the toolbar is changed, but not of the object itself. The second issue with the default color I can also confirm. I would propose to open an additional bug report for this issue.
Confirmed too - set as New - Sophie
I have reported the other issue concerning default fill / line colour labels under bugzilla bug #74950
reproducible with LO 4.3.2.2 (Win 8.1)
** 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 on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
Clicking on the color is the same as clicking on the dropdown triangle: it opens the palette dropdown. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18 Locale: fi-FI (fi_FI)
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Went back and checked LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b and then LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Any object properties held in "drop list", e.g. fill colors, were _not_ changed on canvas by mouse scroll--they required the expected "scroll - select - apply" to actually change. Just properties controlled by "spin box", e.g. line width, respond and apply with Mouse Wheel scroll when the widget has focus. Again expected UI. That remains the implementation through 5.4.1, as the issue never was the case and this is not a reasonable enhancement given evolution of the Area dialog palette based color pick closing WONTFIX.