Bug 134355 - When Arrange Fontwork and Shapes, cannot set Fontwork to bring to front
Summary: When Arrange Fontwork and Shapes, cannot set Fontwork to bring to front
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Regina Henschel
URL:
Whiteboard: target:7.2.0
Keywords: bibisected, bisected, regression
: 138523 (view as bug list)
Depends on:
Blocks: FontWork-WordArt
  Show dependency treegraph
 
Reported: 2020-06-28 08:09 UTC by NSO LibreOffice Team
Modified: 2021-02-14 17:44 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
When Arrange Frontwork and Shapes, cannot set Frontwork to bring to front (75.79 KB, image/png)
2020-06-28 08:09 UTC, NSO LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NSO LibreOffice Team 2020-06-28 08:09:03 UTC
Created attachment 162467 [details]
When Arrange Frontwork and Shapes, cannot set Frontwork to bring to front

Description:
I'm using LibreOffice 7.0.0.1.beta1 in the China locale and finding a very strange bug. I'll try to be as clear as possible in the description.
New spreadsheet document on LibreOffice 7.0.0.1.beta1,then insert Frontwork and Shapes in spreadsheet document,and Arrange Frontwork and Shapes, and set Frontwork to bring to front,finally Fontwork cannot be bring to front


Steps to Reproduce:
1.New spreadsheet document on LibreOffice 7.0.0.1.beta1
2.Insert Frontwork and Shapes in spreadsheet document
3.Arrange Frontwork and Shapes, and set Frontwork to bring to front
4.Fontwork is not bring to front

Actual Results:
Fontwork cannot be bring to front

Expected Results:
Fontwork can be bring to front

Reproducible: 
Always

Additional Info:
Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
Environment:CPU threads: 12; OS: Windows 10.0 Build 18363; 
User Interface: UI render:Skia/Vulkan; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Misc:   Calc: threaded
Comment 1 Julien Nabet 2020-06-28 08:47:31 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 2 Telesto 2020-06-28 18:05:46 UTC
Fine in
4.3.7.2
Comment 3 Buovjaga 2020-06-29 14:51:04 UTC
This started in 5.0
Comment 4 V Stuart Foote 2020-06-29 15:05:55 UTC
Works for me.

Did you bring the shapes to the Forground first? The fontwork starts off there, if shapes and fontwork are not on the same layer they can not be arranged together...

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8ed11b7289533bd609fbcb2adfb7b2982ef6fe22
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 5 Buovjaga 2020-06-29 15:48:18 UTC
(In reply to V Stuart Foote from comment #4)
> Works for me.
> 
> Did you bring the shapes to the Forground first? The fontwork starts off
> there, if shapes and fontwork are not on the same layer they can not be
> arranged together...

Hmm, good point. Indeed it works, if I right-click the shape and Arrange - to Foreground. Then this would be notabug.
Comment 6 NSO LibreOffice Team 2020-06-30 03:06:08 UTC
(In reply to Buovjaga from comment #5)
> (In reply to V Stuart Foote from comment #4)
> > Works for me.
> > 
> > Did you bring the shapes to the Forground first? The fontwork starts off
> > there, if shapes and fontwork are not on the same layer they can not be
> > arranged together...
> 
> Hmm, good point. Indeed it works, if I right-click the shape and Arrange -
> to Foreground. Then this would be notabug.


Thanks V Stuart Foote and Buovjaga, It's a good idea.
However, from the perspective of user use, it is not very easy to find out, if it can be used as in Document, it will be easier.

Is the status of the problem changed to notabug?
Comment 7 QA Administrators 2020-06-30 03:42:42 UTC Comment hidden (obsolete)
Comment 8 Attila Baraksó (NISZ) 2020-06-30 09:13:14 UTC
This was the first bad commit, HEAD^1 this worked:

commit 23edbf207f3b339c0cf00b20680320242a271f58

Bibisected using bibisect-win32-5-0. to:
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ea42ddf8f06b7551e80a906908dbad0766a68c6
author: Yousuf Philips <philipz85@hotmail.com>
committer: Caolán McNamara <caolanm@redhat.com>
summary: tdf#85594 Additional tweaking of the standard, formatting and draw toolbars

Can someone else confirm this is a bug or not?
Comment 9 Telesto 2020-06-30 09:31:11 UTC
(In reply to Attila Baraksó (NISZ) from comment #8)
> This was the first bad commit, HEAD^1 this worked:
> 
> commit 23edbf207f3b339c0cf00b20680320242a271f58
> 
> Bibisected using bibisect-win32-5-0. to:
> URL:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=6ea42ddf8f06b7551e80a906908dbad0766a68c6
> author: Yousuf Philips <philipz85@hotmail.com>
> committer: Caolán McNamara <caolanm@redhat.com>
> summary: tdf#85594 Additional tweaking of the standard, formatting and draw
> toolbars
> 
> Can someone else confirm this is a bug or not?

I would call it a bug.. the bibisect shows this didn't happen on intention :-) and not really user friendly either
Comment 10 Mike Kaganski 2020-06-30 09:52:30 UTC
(In reply to V Stuart Foote from comment #4)
> Works for me.
> 
> Did you bring the shapes to the Forground first? The fontwork starts off
> there, if shapes and fontwork are not on the same layer they can not be
> arranged together...

But if it's not on Foreground layer, then on which layer is it? Fontwork seems to end up on Foreground automatically; if shape goes to a different layer, then which layer is more foreground than Foreground?

(In reply to Attila Baraksó (NISZ) from comment #8)
> This was the first bad commit, HEAD^1 this worked:
> 
> commit 23edbf207f3b339c0cf00b20680320242a271f58

But that commit did not change anything related to layers and arrangement... some problem with bibisect repo? can bibisection be repeated on a different platform?
Comment 11 Buovjaga 2020-06-30 18:25:01 UTC
(In reply to Attila Baraksó (NISZ) from comment #8)
> Bibisected using bibisect-win32-5-0. to:
> URL:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=6ea42ddf8f06b7551e80a906908dbad0766a68c6
> author: Yousuf Philips <philipz85@hotmail.com>
> committer: Caolán McNamara <caolanm@redhat.com>
> summary: tdf#85594 Additional tweaking of the standard, formatting and draw
> toolbars
> 
> Can someone else confirm this is a bug or not?

I got the same commit with Linux 50max repo just now
Comment 12 NSO LibreOffice Team 2020-07-01 06:44:35 UTC

Thanks for looking into this.
This bug also appears in lo7.0.0.1.beta1.
Comment 13 Regina Henschel 2020-12-16 22:56:34 UTC
I see the same problem too with other shapes. Draw a custon shape in a new document. Draw a second shape. Move the shapes so that they overlap. Try to change the stacking order. The first shape will always be on top.

Are you sure it works in any version? I see the error too in AOO.

The problem is, that the first custom shape is put to layer "Controls" and objects on that special layer are forced to be on top. You can see which layer is used by expecting the shape in a Basic macro. The layername property is available in the API.

If you use "to Background" and then "to Foreground" the shape gets the correct layer. And of cause saving and reloading solves the problem too, because the file format does not know any "layer" for spreadsheet documents but only z-order. Layer are internally in Calc. 

Line 106
SdrLayer* pLayer = pView->GetModel()->GetLayerAdmin().GetLayerPerID(SC_LAYER_CONTROLS);
in FuConstCustomShape::Activate()
looks suspicious to me. Switching layer on Activate() and Deactivate() makes only sense for form controls.
Comment 14 Regina Henschel 2021-02-08 18:42:58 UTC
*** Bug 138523 has been marked as a duplicate of this bug. ***
Comment 15 Regina Henschel 2021-02-10 21:49:43 UTC
Will remove the mentioned line.
Comment 16 Commit Notification 2021-02-13 17:12:44 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/02e4f6c44295004f5c7201a7aa2744fd0518ba9d

tdf#134355 custom shapes are never on layer 'controls' in Calc

It will be available in 7.2.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.