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
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Fine in 4.3.7.2
This started in 5.0
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
(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.
(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?
[Automated Action] NeedInfo-To-Unconfirmed
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?
(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
(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?
(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
Thanks for looking into this. This bug also appears in lo7.0.0.1.beta1.
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.
*** Bug 138523 has been marked as a duplicate of this bug. ***
Will remove the mentioned line.
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.