Open this attachment from bug 99088 in Draw: https://bugs.documentfoundation.org/attachment.cgi?id=124072 Select the rectangle. You will see the following Horizontal/Vertical positions/Width/Height in the Sidebar: -4.4.0.3: 0.07/0.07/0.84/0.08 -5.0.0.5 & 5.1.4.2: 0.07/0.00/0.84/0.08 -5.2.0.1: 0.07/0.00/0.84/0.00 => regression There was a fix to bug 82616, which might be related (pushed for 4.5/5.0). Bug 99711 might also be a distant relative. There is an additional, related issue that existed from the introduction of the Sidebar. Sidebar's Position and Size doesn't display the exact same values as right click -> Position and Size... In 4.3.0.4: -Sidebar: 0.07/0.07/0.84/0.08 -Dialog: 0.07/0.07/0.85/0.07 (note a naming inconsistency: Position X/Position Y in dialog vs. Horizontal/Vertical in Sidebar) Setting confirmed based on Heiko's reply: https://bugs.documentfoundation.org/show_bug.cgi?id=99088#c13
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c25ee07a77a5ff278804aa3dbd8dbfcc3ac3ca46 Related: tdf#100632 naming consistency It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Positional values in the sidebar still don't get updated. Is: 0.07/0.00/0.84/0.00 Expected: 0.07/0.07/0.84/0.07 (according the position & size dialog) Version: 5.3.0.0.alpha0+ Build ID: b93cfe09c21b996cd3f1c40037e0ebf712922006 CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: de-DE (de_DE.UTF8); Calc: group
Bibisecting between 4.4 and 5.0: # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86 # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311 git bisect start 'latest' 'oldest' # bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557 # bad: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03 git bisect bad 770ff0d1a74d2450c2decb349b62c5087e12c46b # bad: [227af65db5e34efcf8dcb0b53333efecd30f37f8] source-hash-193c7ba9be48f00b46f9e789f233db577e7b3303 git bisect bad 227af65db5e34efcf8dcb0b53333efecd30f37f8 # bad: [579722ff16592be24bae52c4fea90bbef0609601] source-hash-509e54df095712a91ff9ab3c6b885998936f79a0 git bisect bad 579722ff16592be24bae52c4fea90bbef0609601 # good: [a0988ef749c18c8314dba773f1a7f1f7a70678db] source-hash-54d9755ab4a0825d35e605b47376e01b72d1a57c git bisect good a0988ef749c18c8314dba773f1a7f1f7a70678db # good: [dbbb93c56521379f12ae02baf1fe4b23c23a6a00] source-hash-8f031861f590ba914321816657a003375d93ef5d git bisect good dbbb93c56521379f12ae02baf1fe4b23c23a6a00 # bad: [521ce44d67a6c79978e96762633f582d64b2bb08] source-hash-fa15d039e3a553da8500c17190d27169a9477cf2 git bisect bad 521ce44d67a6c79978e96762633f582d64b2bb08 # good: [afb8e925b843cdbfd433a9a2b25db78d1702163c] source-hash-4368e050406ddfa09a4b42a8cecbfd9d662aaaab git bisect good afb8e925b843cdbfd433a9a2b25db78d1702163c # bad: [c97b9bf218da33e15639134ef609a8c4c3820553] source-hash-1386c348f81738a9966d1217db89d1f603466317 git bisect bad c97b9bf218da33e15639134ef609a8c4c3820553 # good: [285a5272bd378d0894d07f6b0868add226ed1efe] source-hash-426ef2847cbdc74c068531915efb852a727cd3ee git bisect good 285a5272bd378d0894d07f6b0868add226ed1efe # good: [8ddc211f530e964a0659785fe14c30bbf01b4ea0] source-hash-8bc56801af0540c0496c1f8ddd335578a8791017 git bisect good 8ddc211f530e964a0659785fe14c30bbf01b4ea0 # good: [2af005afc858c7651cf0b70bc9a9355937f740a4] source-hash-a4b6266311a95347696bc79baa84ddd09f69366e git bisect good 2af005afc858c7651cf0b70bc9a9355937f740a4 # good: [511805b45446b088481ed364f590dbfcfebe02af] source-hash-e22325ca9076de4cf11c82f21da611b8c7ba1b5a git bisect good 511805b45446b088481ed364f590dbfcfebe02af # first bad commit: [c97b9bf218da33e15639134ef609a8c4c3820553] source-hash-1386c348f81738a9966d1217db89d1f603466317
Katarina, can you please take a look? This concerns the 2nd 0.07 becoming 0.00 in the Sidebar (Unit of Measurement has to be set to Centimeters). The other 0.00 needs to be bibisected separately, but might be in the same piece of code. c97b9bf218da33e15639134ef609a8c4c3820553 is the first bad commit commit c97b9bf218da33e15639134ef609a8c4c3820553 Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 16:48:36 2015 +0800 source-hash-1386c348f81738a9966d1217db89d1f603466317 commit 1386c348f81738a9966d1217db89d1f603466317 Author: Katarina Behrens <bubli@bubli.org> AuthorDate: Fri Nov 28 11:20:04 2014 +0100 Commit: Katarina Behrens <bubli@bubli.org> CommitDate: Sat Nov 29 08:18:34 2014 +0000 fdo#82616: set limits on spinboxes according to size of workarea Do it the same way as position'n'size dialog does, for that matter move shared code into a separate header/class. This fixes regression from .ui migration that omitted spinbox limits Change-Id: I884904719b2608dd80aecc5d7ffb3923de71774d Reviewed-on: https://gerrit.libreoffice.org/13174 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Katarina Behrens <bubli@bubli.org>
Xisco, the bibisectRequest is still valid for this change, since I only bibisected the one between 4.4 and 5.0: -5.0.0.5 & 5.1.4.2: 0.07/0.00/0.84/0.08 -5.2.0.1: 0.07/0.00/0.84/0.00 I don't know if there's a protocol for that, but I added an extra whiteboard tag for clarification.
The second change is caused by this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=0acbf9404a40e5ca87642af299218846d51cf009 tdf#82396:Incorrect behavior on update of Size values in sidebar Rishabh, can you please take a look?
** 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
Still the same in 6.0.0.1 / Windows 7.
Dear Aron Budea, 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
The selection rectangle is wrong since 6.1, reported bug 131523 on that. Thus the exact numbers can't be verified, but they are filled now. 1. Height is filled since bug 111922's fix. 2. Position fields are filled since the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c85fcc6e1994eb8e079aaca85066ab4d67149c15 author Caolán McNamara <caolanm@redhat.com> 2019-12-23 16:05:02 +0000 committer Caolán McNamara <caolanm@redhat.com> 2019-12-30 10:39:48 +0100 "weld PosSizePropertyPanel" Let's assume fixed. Thanks to Gabor Kelemen and Caolán McNamara!
=== German === Draw - Seitenleiste - Felder für Position und Größe sind manchmal leer (weiß). Vorgehen Das Vorgehen ist wiederholbar. Einfügen eines gefüllten Quadrats (auch jedes andere Objekt möglich). Alle Felder Position X, Y und Breite Höhe zeigen Werte an. Abwählen des Objektes und sofort wieder Anwählen (auch mehrfach) erhält die Werte in den Feldern. Wird zwischen Abwählen und Anwählen eine Pause gemacht von 2-3 Sekunde bleiben die 4 Felder leer (Zeitfaktor!). Nach dem Ändern des Objektes Position und Größe werden jeweils die Werte wieder angezeigt, die am Objekt durch Ändern herbeigeführt werden. Beispiele: Positionsverschiebung X führt wieder zur Anzeige des Feldes X, der Rest bleibt leer. Objekt größer ziehen in die Breite führt wieder zur Anzeige der Breite, der Rest bleibt leer; etc. === EDraw - Sidebar - Fields for position and size are sometimes empty (white). Procedure The procedure can be repeated. Insert a filled square (any other object is also possible). All fields Position X, Y and Width Height show values. Deselecting the object and immediately selecting it again (even several times) retains the values in the fields. If there is a pause of 2-3 seconds between deselecting and selecting, the 4 fields remain empty (time factor!). After changing the position and size of the object, the values that were created by changing the object are displayed again. Examples: Moving position X causes field X to be displayed again, the rest remains empty. Dragging the object to a larger width will display the width again, the rest will remain empty, etc. Translated with www.DeepL.com/Translator (free version)nglish === --------------- Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded