Bug 135021 - UI: Right shows -0,10 when pressing increase size width with alignment from left
Summary: UI: Right shows -0,10 when pressing increase size width with alignment from left
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-21 14:36 UTC by Telesto
Modified: 2020-08-13 14:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast (1.44 MB, video/quicktime)
2020-07-21 15:00 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-21 14:36:35 UTC
Description:
UI: Right shows -0,10 when pressing increase size width with alignment from left

Steps to Reproduce:
1. Open Writer
2. Insert a table
3. Table -> Properties -> Table tab
4. Press arrow up button 

Actual Results:
-,10 shows up at right

Expected Results:
Ideally, allow the size to be increased. Similar to Alignment left/right. 
but surely not showing -0,10


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.2
Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 1 Xisco Faulí 2020-07-21 14:46:09 UTC
Not reproducible in

Version: 7.1.0.0.alpha0+
Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 Xisco Faulí 2020-07-21 14:54:58 UTC
Nor in

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 06ca0ae15f2c467cb69561c43779cc09d5666227
CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: threaded

Where is the focus when you press arrow up button ?
Comment 3 Telesto 2020-07-21 15:00:30 UTC
Created attachment 163369 [details]
Screencast
Comment 4 Xisco Faulí 2020-07-21 15:24:34 UTC
Reproduced in

Version: 7.1.0.0.alpha0+
Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

and

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.19; Render: default; 



but not reproducible with GTK3

@Caolán, I thought you might be interested in this issue
Comment 5 Telesto 2020-07-21 15:56:13 UTC
@Heiko
Is there a reason why the size from left can be increased across page margin. So Say left is set 0,00. you can't increase the width to 18.00. This is possible for  Left/Right
Comment 6 Heiko Tietze 2020-07-22 16:01:53 UTC
Confirmed with 
Version: 6.3.6.2
Build ID: 6.3.6-2
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kde5; 
Locale: de-DE (en_US.UTF-8); UI-Language: en-US
Calc: threaded

You can enter a numeric value in the field and it's deducted from the right side. For example 18 (cm) and tab to leave the control but stay in the dialog results in -1.00 and 17.00. The click is just the small step of 0.1.

(In reply to Telesto from comment #5)
> Is there a reason why the size from left can be increased across page
> margin. So Say left is set 0,00. you can't increase the width to 18.00. This
> is possible for  Left/Right

You rather mean why isn't it possible for "From left", which has a maximum set. No idea and perhaps a simple solution too when we allow this. Not to mention the "relative" option where not more than 100% (obviously of the page size) can be entered.
Comment 7 Heiko Tietze 2020-07-22 16:45:38 UTC
Not an issue with 

Version: 7.1.0.0.alpha0+
Build ID: Don't eat the yellow snow
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 8 Caolán McNamara 2020-07-28 14:24:15 UTC
It seems to have been ~always like this. The callback for the value-changed of the width widget ends up itself changing the value of the width widget during the callback, which is fairly unorthodox. In the gtk case that happens to trigger another value-changed callback on completing the first one so things end up consistent. I can manually rerun the handler when the widget changed is the width widget and the width widget value is changed by the callback to end up with the same result regardless of the platform.
Comment 9 Commit Notification 2020-07-28 18:29:05 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/04e5cc16c48b5eaf69cd275825b957a504904187

tdf#135021 if the input width is changed, rerun the callbacks

It will be available in 7.1.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.
Comment 10 Caolán McNamara 2020-07-28 18:31:02 UTC
I believe that makes it consistent