Bug 134611 - FORMATTING Changed width value of an image shadow lost when shadow parameters are changed
Summary: FORMATTING Changed width value of an image shadow lost when shadow parameters...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-07 11:31 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2021-07-26 22:36 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2020-07-07 11:31:14 UTC
When I have tested the fix to Bug 133944 I have found another problem:
A changed width resp. distance value (other value than 0,18 cm = default) of an image shadow is lost (= reset to the default), when shadow properties "Position" and/or "Color" are changed.  

Reproduce the problem:
- File -> Writer text document
- Insert -> Image -> choose any image file from computer to insert it into the text document
- right click on the inserted image -> Properties -> Tab "Border"
- select "shadow to the right and to the bottom" (e.g.) + change distance value from 0,18 cm e.g. to 0,10 cm -> OK
- --> The shadow is created correctly.
- right click on the inserted image again -> Properties -> Tab "Border"
- the shadow distance value is displayed as it was set at creation of the shadow
- now change the shadow color and/or the shadow position, but leave unchanged the shadow distance value -> OK

Expected result: The shadow is shown on the new position and/or with the new color - and with the unchanged width/distance.
Current result: The shadow is shown on the new position and/or with the new color - but the width/distance is reset to the default value!

In LO versions until 6.2.0 the problem did not occur. The first version with the bug is 6.2.1.
Comment 1 sora34ce 2020-09-25 16:58:50 UTC
I'm suspecting the problem is that it can only take in certain changes, explaining the reset at certain points

Version: 7.1.0.0.alpha0+
Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0
CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 Buovjaga 2021-07-26 10:04:03 UTC
I don't reproduce, can you re-test with 7.1.5 or newer? I'm not setting to needinfo, because another tester seemed to confirm it.

NixOS
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 67e47070a7580a17804adce812cc2f98bfe7b51f
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: x11
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Comment 3 Stefan_Lange_KA@T-Online.de 2021-07-26 20:35:24 UTC
(In reply to Buovjaga from comment #2)
> I don't reproduce, can you re-test with 7.1.5 or newer? I'm not setting to
> needinfo, because another tester seemed to confirm it.
> 
> NixOS
> Version: 7.3.0.0.alpha0+ / LibreOffice Community
> Build ID: 67e47070a7580a17804adce812cc2f98bfe7b51f
> CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: x11
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded

You are right!
I have tested in Win10 with LO 7.1.5.2 and also with recent build of LOdev 7.2.0.1 and in Win11 with the not newest build of LOdev 7.3.0.0.alpha0: I cannot reproduced the bug with this builds.
I set the status to RESOLVED WORKSFORME. OK?
Comment 4 Stefan_Lange_KA@T-Online.de 2021-07-26 22:36:51 UTC
I have made further tests to see when the bug disappeared:
Until LO 7.0.1 I can reproduce the behavior described, but no longer in LO 7.0.2 (published in 10/2020).