(*** This bug was imported into bugs.kde.org ***) Package: kwin Version: KDE 3.0.6 CVS/CVSup/Snapshot Severity: normal Installed from: Compiled sources Compiler: gcc 2.95.3 OS: Linux OS/Compiler notes: linux 2.4.18 I've found this bug using the konqueror as a navigator. Steps: 1 - Choose the policy of cookies to ask before accept the cookie. 2 - Open a site that have cookies. 3 - Before appears the alert windows asking what to do with the cookie click with the right button on the page to appear the context menu. Don't click anything more. It is to mantain the context menu. 4 - Wait until appears the alert window of cookies. Now the system enters in a deadlock situation. The window manager doesn't respond anymore but the system doesn't freeze. The only way to go away from this state is go to console (ctr+alt+f2) and kill manually the kcookiejar process. Or reboot the system of course. I think that this bug is similar to #36162 bug but not the same. I think this is a critical bug and needs a fix fast. I have found this bug in kde 3.x and tested in kde 3.1 alpha too. Any questions. Ask me. rgf@ieg.com.br (Submitted via bugs.kde.org)
Hi I've heard some reports of this and has been collecting some data to try to reproduce it well enough to do something about it..(There was also a discussion on kde-core-devel a day or so ago about what's possibly the same problem and interesting pattern has emerged) Two questions: Do you have Menu fade effect on? Do you use NVIdia's binary drivers? Thanks... Maks Orlovich
Hi Maks Yes for the two questions. I use fade effect and use NVidia binaries but I= 've tested without this and the bug persists. This is what I did: 1 - remove the kernel module ( rmmod NVdriver) 2 - edit the XF86Config removed glx (to avoid the NVidia's GL) and change = the driver to opensource's driver (nvidia -> nv) 3 - delete the .kde directory 4 - in kpersonalizer choose none effect 5 - tested again. The bug persists. This is exactly I wrote. I have readed the thread "X hang= s=20 reproducably with recent KDE CVS versions" in kde-core-lists and it seems t= o=20 be another bug but I can't reproduce here (kde 3.0.2 and NVidia's binaries= ). My computer is a Athlon 1.33 GHz MB soyo k7vta-pro GeForce 2 MX 400 64 MB= =20 running slackware 8.1 with the kde 3.0.2 (and kde3.1alpha). Thanks Raul Fernandes rgf@ieg.com.br On Wednesday 17 July 2002 23:36 Maks Orlovich wrote: > Hi I've heard some reports of this and has been collecting some data to > try to reproduce it well enough to do something about it..(There was also= a > discussion on kde-core-devel a day or so ago about what's possibly the sa= me > problem and interesting pattern has emerged) > > Two questions: > Do you have Menu fade effect on? > Do you use NVIdia's binary drivers? > > Thanks... > Maks Orlovich > > > > (Complete bug history is available at http://bugs.kde.org/db/45/45403.htm= l)
Hi I've discussed this bug with Waldo Bastian who is a KDE core developer (aka a very good coder that knows a whole lot more than me); and he commited (http://lists.kde.org/?l=kde-cvs&m=102745026629495&w=2) a likely fix based on the backtraces of the problem I captured.. Here is in short what happens: 1. The menu pops up and grabs the mouse for a short period. 2. Meanwhile Konqueror messages the cookie jar over DCOP about the cookie and blocks for the response (which should come in essentially instantly). 3. The cookie jar pops up the cookie dialog and prepares to reply; except due to the mouse grab it can't continue which leaves Konqueror stuck too. Thus this is indeed a subtle deadlock between two apps. At any rate the likely fix should be in CVS right now and since you're building from sources so could you perhaps check whether it is fixed for you? It is very hard to reproduce here... Thanks Maks Orlovich
I think that the problem is exactly you describe it. The patch really fixes this bug. Now the kcookeijar closes the popup menu.= =20 Great !! But now there are other problem. Steps: 1 - Open the konqueror 2 - Go to a page that have cookies 3 - Before the alert windows asking what to do with the cookie click with = the=20 right button on the page mantain the right button pressed put the cursor= =20 over the back option mantain the right button pressed and don't move the= =20 cursor. The cursor must stay over the back option. 4 - The cookie alert windows appears and closes the menu 5 - release the button without moving the cursor. 6 - now the navigator will go back in history It happens with any option in the menu. If I put the cursor over the view= =20 document source option when I release the button after the alert windows= =20 appears and the popup menu disappears still execute the action. A small bug. Probably the smaller. Can you reproduce this there?? Thanks Raul Fernandes rgf@ieg.com.br
Ouch sorry for such a delay in answering I really need to get more organized.. First of all it's great to hear that the main bug is fixed that's a big relief... And yes I can also rperoduce the bug you described although it needs some trickery -- keeping the menu open and pressing F5 on a page with cookies. I am not really sure of what may cause it though.. KWin people: how can an apparently hidden window receive mouse clicks?
Closing, since the main bug is fixed, and the "bug" with konqy getting the mouse release even with cookie dialog is nothing serious, and I'd say it's even normal due to mouse grabbing.