Created attachment 124883 [details] Step 2 Problem description: The sidebar displays incorrect width and height when units are in millimeters Steps to reproduce: 1. Open LibreOffice Draw and set the options to display mm (Tools > Options > LibreOffice Draw > General > Unit of measurement: Millimeter) 2. Create a rectangle and change the width and height to 10.00 mm. Note that the Position and Size window* agrees with the sidebar for these dimensions. *right click on the rectangle > Position and Size 3. Deselect and reselect the rectangle. The sidebar now claims the width and height are 9.91 mm, however the Position and Size window correctly shows 10.00 mm. Note that if a 10.00 mm grid is shown, the 10.00 mm rectangle aligns to the grid, whereas a 9.91 mm rectangle does not. This suggests the dimensions are actually 10.00 mm, even though the sidebar displays them as 9.91 mm. Current behavior: In the Sidebar, under Position and Size, the Width and Height display incorrect width and height. Expected behavior: In the Sidebar, under Position and Size, the Width and Height should display the correct width and height. Additional comments: -Tested on a Windows 7 (x64) machine using LibreOffice 5.0.5.2 -Able to be produced this issue in both LibreOffice Draw and Impress -Though untested, I expect similar behavior when other units are used. This may be a rounding issue before unit conversions?
Created attachment 124884 [details] Step 3
Repro. menturi: would you like to join the QA team to do this: https://wiki.documentfoundation.org/QA/Triage_For_Beginners Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 540fee2dc7553152914f7f1d8a41921e765087ef CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 30th 2016
This bug is not present in Libreoffice 4.1.0.4 (the first version with a sidebar), thus it's a regression Adding "regression" to the keywords
Thanks for the test, Nico. Adding bibisectRequest.
repro Version: 4.4.0.0.alpha0+
Created attachment 130286 [details] output from bibisect in 43max repository Working on debian-stretch in the bibisect-43max repository, I see that the bug entered LibreOffice in commit 36be3d94 ... Author: Armin Le Grand <alg@apache.org> AuthorDate: Thu Mar 20 14:36:21 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Mar 20 16:49:46 2014 +0000 Resolves: #i124409# use slot SID_ATTR_METRIC... to retrive the UI unit, not GetModuleFieldUnit (cherry picked from commit 34279ea85c33e3efd21971ab692a3de4bdd91817) Conflicts: svx/source/sidebar/possize/PosSizePropertyPanel.cxx Change-Id: Id81847bf7e989a3e49fbe8adaad23048956067df Looking at a couple of numbers, it seems that the redisplayed dimension is converted to nearest 0.01 inch and that result is converted to the nearest 0.01 millimetre. I am removing keyword bibisectRequest and adding bibisected and bisected.
Commit hash: 36be3d94c2e142d01c026a93fa88454cb5316bff Adding Cc: to Armin Le Grand
*** Bug 107118 has been marked as a duplicate of this bug. ***
*** Bug 107878 has been marked as a duplicate of this bug. ***
The size is displayed incorrect and no matter which unit do you use. I have LO 5.1.6.2 in Linux Mint and I confirmed this bug.
Created attachment 133658 [details] The evidence in LO 5.1.6.2
Created attachment 134557 [details] Problem on 5.3.4 As you can see on the screenshot the problem is also present when you select cm as unit, not only with mm. If you take the quotient between the value displayed on the menu and the one on the sidebar you get ~2.5. It seems the value displayed on the sidebar is on inches, even if it says cm.
** 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! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in 6.0.5.2
I can still confirm this bug in linux and lo 6.0.5.2. This is very anoying, because it changes the sizes of objects in the document. And objects I didn't touch change their sizes and dimension lines too. For example 60cm becomes 62,59 and I didn't touch this drawing object. This happens while I changed another objects on this page.
It'seems to work, if you DON'T TOUCH THE SIDEBAR.
It *seems* it's working in 6.1.1. Can someone confirm?
OK, it doesn't work: for some reason, it started to work when using some drawing objects, then I selected a PNG picture and it failed, now even the drawing objects show different values in the sidebar and in the "Position and size" menu. (I tested on 6.1.1.1)
*** Bug 118837 has been marked as a duplicate of this bug. ***
*** Bug 115322 has been marked as a duplicate of this bug. ***
*** Bug 124447 has been marked as a duplicate of this bug. ***
I confirm that the bug is present in the version 6.2.2.2 as well. Very annoying.
Changing priority to 'high' since the number of duplicates is 5 or higher
@Caolán, I thought you might be interested in this issue...
Bisection from comment 6 points to https://cgit.freedesktop.org/libreoffice/core/commit/?id=36be3d94c2e142d01c026a93fa88454cb5316bff
Changing priority to 'highest' since this a regression and the number of duplicates is higher than 5 or the number of people in CC higher than 20
When fixing this bug, it might be a good idea to add a unit test, to prevent it from being broken ever again. As I looked around in PosSizePropertyPanel.cxx, I noticed that the spacing in the code seems to be completely random. I found: * if(expr) * if (expr) * if( expr ) * if ( expr ) * call(arg1, arg2) * call(arg1,arg2) * call( arg1, arg2 ) * call( "Width") I would expect that a project as large as LibreOffice has a style guide for these things. In the "nChar == '-'" around line 496, the left-hand side is a modifiable expression. The other code in that file uses the "if (object == subject)" style to avoid this, although this typo is nowadays detected by any good compiler. The number 315000 looks like a typo to me since it has 1 more 0 than expected. The value 31500 makes more sense when measured in 1/100ths of degrees. By the way, nTmp is a terrible variable name. I suggest nAngle instead. All in all, it looks like there is a lot to do in this single file. I haven't looked at the other files, I guess they look similar.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/162a9d7e625315bb7d2f7353bfe160dc2217defa Resolves: tdf#99711 update metric for spinbuttons before setting their values It will be available in 6.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/704dc5814a26f56c67da4e0b947abab452c4e94d Resolves: tdf#99711 update metric for spinbuttons before setting their values It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Do you plan to add a regression test so that the order of these method calls will not be accidentally reverted?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/ad080296feb5663c0917816229eeb81683fc4c66 Resolves: tdf#99711 update metric for spinbuttons before setting their values It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.5.0.0.alpha0+ Build ID: 8f7010eb47119a2428b77f5d79fc8577d9914958 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Caolán, thanks for fixing this issue!!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3-4": https://git.libreoffice.org/core/commit/154ab3d8a265c86ba5211578757542f87478b12e Resolves: tdf#99711 update metric for spinbuttons before setting their values It will be available in 6.3.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/730c50946e088e7a93d9c0809444f74502e1b4b8 tdf#tdf99711: sw: Add UITest It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.