Created attachment 103811 [details] Screenshot of Pivot Table Layout with the bug Problem description: the color of fields becomes black when you try to put a alement and turn back. Steps to reproduce: 1. open a new file and put some data to create a pivot table. 2. select the cells with datas and go to Data, Pivot Table, Crate... then OK. 3. take one element from Availabela Fields and go on the other Fields and torn back. Current behavior: The ather Fields change color in black (attachet image). Expected behavior: the color should not change. Operating System: Mac OS X Version: 4.3.0.4 release Last worked in: 4.2.6.2 rc
Not reproduced in LO 4.3.0.4 - Ubuntu 12.04 x86. Please try reset user profile: https://wiki.documentfoundation.org/UserProfile
The bug is only in MacOSX, not in Windows or GNU/Linux. I did not tried to reset my user profile because is a little difficult for me but I tried it on another Mac and is the same.
I have the same problem with the latest 4.3.0.4 and the 4.3.1.1. developer version. MacOS OS X 10.9.4 MacBook Air. I have tested two display resolutions, both with the same failure.
I'm having the same issue on OS 10.9.4 with LibreOffice 4.3.0.4 on an early 2008 MacBook Pro.
Set NEW since there are many confirmations. If someone, other than reporter, could confirm such behavior not exist before 4.3.0.4 then please remove "PossibleRegression" from whiteboard and add "regression" in keywords. And importance should be "High" if regression confirmed.
Confirming defect on 4.3.1.1 on OSX 10.9.4
Also persists on 4.3.1.2 on OS 10.9.4. (I can't confirm that this is a regression as I haven't needed to use pivot tables in some time, but boy is the timing of this bug bad wrt my current needs.)
Issue also persists in 4.3.2 RC2 on OS 10.9.5.
Same problem in Version: 4.3.1.2 release Late 2012 iMac OS 10.9.5 Clicking the mouse "at random" on the blackened window turns the background back to white field by field individually but still this makes pilot table very difficult to use. This bug was NOT present on V. 4.2.6.3 that I was using before updating to the last recommended release.
This WORKSFORME with OS X 10.10.1 and LO Version: 4.5.0.0.alpha0+ Build ID: a26222f5af55e8ffe9784dd411485d3c5c72e983 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-12-07_00:14:47 Locale: de_
Created attachment 110546 [details] Worksforme
Is it possible to fix the bug olso for 4.4 or 4.3? 4.5 version will be published on July 2015.
(In reply to foss from comment #11) > Created attachment 110546 [details] > Worksforme Did you drag and drop fields, as described in comment 0? I did, and I still see the bug with current master. Mac OS X 10.9.5
"take one element from Availabela Fields and go on the other Fields and torn back." so maybe this needs to be translated into clear repro instructions. Or a small screencapture of repro steps might help. OSX allows this with quicktime without any additional software.
Adding Whiteboard:bibisectRequest It's right on the edge, but this might be bibisectable using the existing OSX repository
I don't think that bibisecting would help much. The bug became visible after the rewrite of this dialog, but the root cause may be totally different.
See http://youtu.be/nr3tBQh7Vjs
Can confirm defect on LO Version: 4.4.3.2 on Mac OS X 10.9.5 Exactly as video by Andras Timar - comment 17, gets more difficult to manage when there are many columns to select.
I can confirm this behaviour for LO 4.4.2.2 (and also 5.0.1.2) running 10.9.5. To be honest, this bug is annoying somehow, but there is an easy way to get rid of those black boxes: just press [CMD]+[TAB] two times This will refresh your screen (probably the source of evil?) and washes the black holes away.
I guess Tomaz re-wrote that dialog, and is also an expert on rendering issues - so should at least have this issue on his longer-term queue of bugs to poke at =)
Migrating Whiteboard tags to Keywords: (notBibisectable)
I'm having the same issue on OS 10.11.2 with LibreOffice 5.0.4.2 on MacBook Pro Retina 13 early 2015
Reproduced in 5.1.2 RCs 1 & 2. OS X 10.11.4 Macbook pro retina 13"
On MacOs 10.11.5, with master sources updated yesterday, I could reproduce this. I noticed this on console: warn:vcl:1035:1:vcl/source/window/mouse.cxx:470: Window::ReleaseMouse(): window doesn't have the mouse capture
On pc Debian x86-64 with master sources updated yesterday, I don't reproduce black panels but also have warn:vcl:2829:1:vcl/source/window/mouse.cxx:470: Window::ReleaseMouse(): window doesn't have the mouse capture I tested with rendering: gtk3, gtk, gen, kde4
Created attachment 127086 [details] Bug is still present in Version: 5.1.4.2 on OS-X 10.11.6
*** Bug 107312 has been marked as a duplicate of this bug. ***
Bug still present in Version: 5.3.4.2 Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3 Threads CPU : 4; Version de l'OS :Mac OS X 10.12.6; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR.UTF-8); Calc: group
This is still present Makes using the pivot table functionality a bit cumbersome, and this is a regression, so I'm revising the importance according to the bug prioritizing chart Version: 6.1.0.0.alpha0+ Build ID: 8e8dd8f320a3ff59ff8a16c1a7a867888ce80700 CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-03-13_23:59:29 Locale: en-US (en_US.UTF-8); Calc: group
*** Bug 116291 has been marked as a duplicate of this bug. ***
Still present on fresh 6.0.3
Still present on 6.0.3.2 I made a screencast to show what happens https://www.screencast.com/t/eQlNzhmcpcI It's very frustrating, because clicking on the fields only sometimes partially removes the blackout, so sometimes you can't continue. Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 2; OS: Mac OS X 10.13.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Still present in LO 6.1 MacOsx 10.13.6 Macbook Pro Retina 13" early 2015
*** Bug 120700 has been marked as a duplicate of this bug. ***
Still a bug in Version: 6.1.4.2 Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 12; OS: Mac OS X 10.14.2; UI render: default; Locale: nb-NO (en_NO.UTF-8); Calc: group threaded
Created attachment 148569 [details] Pivot table bug example file Attached file (Ampleon parametric Table.ods) Select All Data > Pivot Table > Create... Current Selection > OK available Fields: click and drag any item, once outside of the drop-down selection box the boxes turn black note: Cmd-Tab to switch applications redraws until the next operation.
Comment on attachment 148569 [details] Pivot table bug example file Attached file (Ampleon parametric Table.ods) Select All Data > Pivot Table > Create... Current Selection > OK available Fields: click and drag any item, once outside of the drop-down selection box the boxes turn black note: Cmd-Tab to switch applications redraws until the next operation.
Interesting is - this is not PivotTable dialog related at all... It happens with any TreeList when you drag a entry around, pivot table dialog just uses dragging and dropping the most (as a primary function).
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/14abbc6e86ba234996dfed477a54030adeac2a52%5E%21 tdf#82009 TreeList move painting of drag target into Paint func. It will be available in 6.3.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.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/c96949f171b98c3dc4bf954dbf10b1720725ab8f%5E%21 tdf#82009 TreeList move painting of drag target into Paint func. It will be available in 6.2.4. 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.
bug corrected. Installed the latest dev version for MacOSX and the drag and drop of elements was fine. No more dark blocks ;)
(In reply to Daniele from comment #41) > bug corrected. Installed the latest dev version for MacOSX and the drag and > drop of elements was fine. No more dark blocks ;) Hi Daniele, Thanks for verifying this issue. Setting to VERIFIED then. @Tomaž, thanks for fixing this old issue!