Bug 176280 - resizing panel vertically breaks the desktop containment (background, widgets...)
Summary: resizing panel vertically breaks the desktop containment (background, widgets...
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Unclassified
Component: containment-panel (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal with 26 votes (vote)
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 176155 177707 179243 181628 183973 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-27 22:56 UTC by Ondrej Cernos
Modified: 2009-02-19 22:27 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot of the workspace after resizing the panel. See the gray area over the folderview. (74.92 KB, image/png)
2008-12-10 20:25 UTC, Ondrej Cernos
Details
screenshot of the krunner not autocompleting systemsettings (20.73 KB, image/png)
2008-12-10 20:26 UTC, Ondrej Cernos
Details
xorg.conf of the test system (5.15 KB, application/octet-stream)
2008-12-10 20:27 UTC, Ondrej Cernos
Details
Here reproducing the bug (761.01 KB, application/octet-stream)
2008-12-23 16:51 UTC, Dario Andres
Details
Basic VESA Xorg.conf file (11.73 KB, text/plain)
2009-01-01 14:42 UTC, Dario Andres
Details
3/4 Black screen - Result from resizing panel (127.46 KB, image/png)
2009-01-16 02:00 UTC, David Hubner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ondrej Cernos 2008-11-27 22:56:34 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

KDE 4.2 beta 1 installed from OpenSUSE factory. Version 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)) "release 7.3", on OpenSUSE 11, x64.

When resizing panel, the default containment looses its background, it turns black, the cashew is lost, the plasmoids cannot be seen. Only plasma restart helps.

You can see the effect in this picture: http://dot.kde.org/1227714704/1227775830/kde42b1.jpeg

To reproduce: simply resize the panel.
Comment 1 Sebastian Sauer 2008-12-10 15:09:44 UTC
uhm. Guess it will be hard to address that since I am not aware of anyone who had such an issue before (what doesn't mean, that it doesn't exist but only that it's hard to find the reason for it).

The screenshot itself does more indicate that the setup of the user is complete broken somehow. E.g. that the "systemsett" does not expand to any single item may very likely means, that the runner-plugins are not found.

Anyway, the step to reproduce is invalid cause it doesn't work here or on any other system I did test. So, guess some more input (like what local changes to a default opensuse 11 was done? is that a mixed setup of KDE 3.5, 4.0, 4.1 and 4.2? Does that also happen with a new added user? etc.) would be needed.
Comment 2 Ondrej Cernos 2008-12-10 15:19:54 UTC
Hello, I reused the screenshot from a dot comment, but only after I reproduced the mentioned problem. I didn't suppose there would be a problem in reproducing, since the commenter complained and I had exactly the same problem.

I will try to reproduce the problem this evening on a fresh empty user setup (delete all .kde dirs) and will send a follow up. Also I will attach more info about my setup (hw and X setup).
Comment 3 Ondrej Cernos 2008-12-10 20:24:29 UTC
I am able to reproduce both the bugs, the krunner one with systemsettings not being autocompleted and the plasma one. See the attached screenshots. The panel resizing was doen using the "Height" button on the settings bar.

The behaviour is seen on OpenSUSE factory KDE4.2b1 packages: KDE 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)) "release 7.3". I use the binary NVidia drivers

test@linux-65k6:~> rpm -qa | grep nvidia
x11-video-nvidiaG01-173.14.12-0.1
nvidia-gfxG01-kmp-default-173.14.12_2.6.25.11_0.1-0.1

on

test@linux-65k6:~> uname -a
Linux linux-65k6 2.6.25.18-0.2-default #1 SMP 2008-10-21 16:30:26 +0200 x86_64 x86_64 x86_64 GNU/Linux

with disabled desktop effects. xorg.conf is attached.

Please let me know if you need any additional information.
Comment 4 Ondrej Cernos 2008-12-10 20:25:23 UTC
Created attachment 29217 [details]
screenshot of the workspace after resizing the panel. See the gray area over the folderview.
Comment 5 Ondrej Cernos 2008-12-10 20:26:24 UTC
Created attachment 29218 [details]
screenshot of the krunner not autocompleting systemsettings
Comment 6 Ondrej Cernos 2008-12-10 20:27:12 UTC
Created attachment 29219 [details]
xorg.conf of the test system
Comment 7 Ondrej Cernos 2008-12-10 20:30:07 UTC
One more thing: krunner does autocomplete on almost anything, only not on the systemsettings. The test was performed on a fresh new user with no previous KDE configuration.
Comment 8 George 2008-12-13 11:14:16 UTC
this is panel bug. read the name.
to reproduse simply resize panel to make it bigger

this is the same bug : https://bugs.kde.org/show_bug.cgi?id=176155
Comment 9 Fabian Hahn 2008-12-19 00:13:18 UTC
I can confirm this bug since KDE 4.2 Beta 1 (4.1.80) and now with KDE Beta 2 (4.1.85) on Kubuntu Intrepid 8.10

Linux winry 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux

I use the proprietary NVIDIA Linux drivers 177.80-0ubuntu2
Comment 10 Beat Wolf 2008-12-19 14:10:21 UTC
*** Bug 176155 has been marked as a duplicate of this bug. ***
Comment 11 William 2008-12-19 17:02:06 UTC
Can reproduce this.  If you resize the panel even larger (1/2 screen and more), then stripes of the blank area near the top turn white for a second, then disappear.  I can get the blank area down to ~1/5 the screen size from when it first appears.

When the blank area first appears, it never covers the cashew, always stops right at the lower edge of it.

The blank area in mine is black, as follows with my theme.

Also using nvidia drivers 177.80.
Comment 12 Dario Andres 2008-12-23 16:51:00 UTC
Created attachment 29581 [details]
Here reproducing the bug

Here using:

Qt: 4.4.3
KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
kdelibs svn rev. 900491 / kdebase svn rev. 900491

xorg-server 1.5.3
xf86-video-intel 2.4.3 (not the last version 2.5.0)
intel-dri 7.2
with an Intel GMA x3100 (965) integrated graphics.

on ArchLinux x86_64 - Kernel 2.6.27.8

I can reproduce this bug.
(This intel drivers seems to be faulty after the upgrade to Xorg-server1.5.3 + xf86-video-intel 2.4.3 (there were some problems for my distro to build the 2.5.0 intel driver.)

If compositing (OpenGL) is ON I see the black rectangle. If compositing is OFF for some seconds I see some another windows (the rect of the window that plasma shows as black when using compositing), and then I see a grey rectangle. (may be a random behaviour)
Comment 13 Dario Andres 2008-12-23 16:51:51 UTC
Also I see part of the KDM background ("Black Curl") (?)
Comment 14 Dario Andres 2009-01-01 14:11:16 UTC
*** Bug 179243 has been marked as a duplicate of this bug. ***
Comment 15 Dario Andres 2009-01-01 14:11:44 UTC
*** Bug 177707 has been marked as a duplicate of this bug. ***
Comment 16 Dario Andres 2009-01-01 14:13:47 UTC
Bug 176280 comment 2 and bug 176280 comment 3 have some additional information about the bug.
Comment 17 Dario Andres 2009-01-01 14:39:55 UTC
Well.. confirming.
Here I can reproduce it even when using the VESA driver with a default Xorg config.

Here using:

Qt: 4.4.3 + qt-copy-patches-889120
KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
kdelibs svn rev. 904138 / kdebase svn rev. 904138
xorg-server 1.5.3
xf86-video-vesa 2.1.0
on ArchLinux x86_64 - Kernel 2.6.27.10

And as stated in bug 176280 comment 3, this only happens if you have one panel (may be the bottom default). If you have another panel on top, this doesn't happen.
Comment 18 Dario Andres 2009-01-01 14:42:14 UTC
Created attachment 29800 [details]
Basic VESA Xorg.conf file
Comment 19 SlashDevDsp 2009-01-02 16:09:41 UTC
this is still an issue with latest trunk about 7hrs ago compiled (Xorg 1.3.0, nvidia 180.16, qt-copy: 904364, kdelibs:904337, kdebase:904348)

I also do get intermittent 'plasma unable to connect to dbus messages' when trying to reload plasma with kquitapp plasma & plasma &
after getting the blackscreen when making the panel size big.
-------------------
<unknown program name>(32114)/ checkComposite: Plasma can use COMPOSITE for effects on 0x8064d70 
	plasma(32114): KUniqueApplication: Registering failed! 
	 
	plasma(32114): Communication problem with  "plasma" , it probably crashed. 
	Error message was:  "org.freedesktop.DBus.Error.ServiceUnknown" : " "The name org.kde.plasma was not provided by any .service files
--------------------
full log here: http://pastey.net/105421

i dont know if this of any help
Comment 20 Vedran Furač 2009-01-03 20:35:02 UTC
@Sebastian Sauer: "The screenshot itself does more indicate that the setup of the user is complete broken somehow."

Original screenshot is mine and my setup is: $ rm -rf ~/.kde4; startkde


Comment 21 Andrew Lake 2009-01-06 04:25:19 UTC
confirmed present as of svn rev 906310.  intel drivers. clean, default ~/.kde.
Comment 22 Thorsten 2009-01-07 17:05:50 UTC
I can confirm this bug.
As I tried to make a screencast of the panel, I have also a video where this bug appears.
If you think it could be useful, I will upload it.
I think it only occur when you resize it "too" much.

My system is:
Mandriva Cooker (2009.1 Alpha)
KDE 4.1.85 
ATI x600 / free 'ati' driver (also appears with fglrx)
X.org Server 1.5.99
Used a new added user

I've restarted plasma with the --no-fork option but no messages appears, when the desktop got broken.

Regards,
TeaAge
Comment 23 Ronny Standtke 2009-01-15 14:24:59 UTC
I just run into exactly this bug using KDE-4.2rc1 on Kubuntu-8.10.
Comment 24 Casper Clemence 2009-01-15 17:47:08 UTC
Confirmed on:

Distro: openSUSE 11.1 (x86_64)
Kernel: 2.6.27.7-9-default x86_64
Qt:     4.4.3
KDE:    4.1.96 (KDE 4.2 RC1)
Card:   NVIDIA GeForce 8600M GS/PCI/SSE2
Driver: 2.1.2 NVIDIA 180.22

note this isn't just a graphical bug, ie it is not possible to "click though" the blackness to the desktop below

Comment 25 David Hubner 2009-01-16 01:59:12 UTC
I also have this bug. I resized the panel to a smaller size than default and got 3/4 a black screen. 

All background was gone and i could not click through. I removed the whole .kde config dir and restarted making a config from new but it did not help. 

Comment 26 David Hubner 2009-01-16 02:00:02 UTC
Created attachment 30302 [details]
3/4 Black screen - Result from resizing panel
Comment 27 Casper Clemence 2009-01-16 09:57:04 UTC
I also have the same bug on Kubuntu nightly (neon) builds.
Comment 28 SlashDevDsp 2009-01-16 10:42:23 UTC
this is still an issue with trunk compiled about 1hr ago with:
qt-copy:911779
kdebase:911780
kdelibs: 911779
Comment 29 Dario Andres 2009-01-23 00:18:23 UTC
*** Bug 181628 has been marked as a duplicate of this bug. ***
Comment 30 Ronny Standtke 2009-01-28 22:12:38 UTC
This is still broken in KDE-4.2 final. While I, personally, could live with this bug, this (and a number of other showstoppers) makes it impossible to hand out KDE 4 to our customers. Sorry guys, but this is still not "The Answer"...
Comment 31 Luke Plant 2009-01-30 21:16:24 UTC
Same here, but without crashing.  The bit of the desktop I can see (about an inch at the top) shows that it is still working, but it is like the rest of it is under a black window which covers most of the desktop. killall plasma followed by running plasma fixes it.


Kubuntu 8.10, KDE 4.2 Final
ATI Technologies Inc Mobility Radeon HD 3650, fglrx driver.
Comment 32 Joshua 2009-01-31 02:56:23 UTC
I checked this out on svn.  If I slowly resize the panel to be larger, there are no problems.  Doing the resize at any >= normal speeds seems induce the problem.  Also, this only occurs when resizing the panel to be larger.

Tested on KDE: 4.2.61 (KDE 4.2.61 (KDE 4.3 >= 20090127))

Comment 33 Joshua 2009-01-31 08:14:28 UTC
Well I played around with this for a bit.  I noticed the start of the problem is at void Panel::constraintsEvent(Plasma::Constraints constraints) in the true portion of the if statement on 447.

Here,  m_background->setElementPrefix(location()) is called.  I haven't had a chance to actually read over the source and understand whats going on... but doing some random checks, I noticed taking out this statement makes the panel not paint, but the panel toolbox is still there.  Resizing, at this point, doesn't cause problems.  So I'm assuming some call from within or resulting from setElementPrefix of FrameSvg when resizing the panel is the culprit. Or maybe its something after that in the constraintsEvent function.  Hopefully this gives a decent lead for further debugging. Well its late, I don't think I can think too clearly anymore. 

I hope this helps.  Not exactly pinpointed but maybe its something in the right direction.

Comment 34 Marco Martin 2009-02-16 22:45:24 UTC
SVN commit 927141 by mart:

theory: the desktop breakage could happen because the panel overlaps the
desktop for a while, making containment()->view() or
corona::containmentfordesktop() fails, leaving the desktop view without
a containment
try to reposition the panel before a vertical movement, it should
prevent the panel to go into the desktop for an instant
CCBUG:176280


 M  +16 -10    containment.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=927141
Comment 35 Marco Martin 2009-02-16 23:11:39 UTC
SVN commit 927158 by mart:

reverting the last change, the panel height is still the old one at that
point :)

CCBUG:176280


 M  +10 -16    containment.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=927158
Comment 36 Andrew Lake 2009-02-16 23:25:49 UTC
A proposed patch was posted by Josh on review board this morning:
http://reviewboard.kde.org/r/101/
Comment 37 Joshua 2009-02-16 23:55:27 UTC
SVN commit 927169 by jleves:

Prevent horizontal panels from bleeding over into positive coordinates by creating a positioning offset, much like that given to vertical panels.
CCBUG: 176280


 M  +2 -2      containment.cpp  
 M  +1 -0      private/containment_p.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=927169
Comment 38 Aaron J. Seigo 2009-02-19 20:50:20 UTC
SVN commit 928671 by aseigo:

prevent panels from encroaching into positive space and screwing things up: constraintsEvent is delayed, and that event loop is entered between. this is something that needs to be done synchronously, however. SizeConstraint is triggered by Applet::resizeEvent, so putting this code in resizeEvent is no more or less immune to applets/containments reimplementing resizeEvent and not calling the base implementation.
BUG:176280


 M  +14 -12    containment.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=928671
Comment 39 Aaron J. Seigo 2009-02-19 20:58:06 UTC
SVN commit 928672 by aseigo:

backport fix for br#176280
BUG:176280


 M  +14 -12    containment.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=928672
Comment 40 Jacopo De Simoi 2009-02-19 22:27:08 UTC
*** Bug 183973 has been marked as a duplicate of this bug. ***