| Summary: | alert windows can leave the system in deadlock | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Raul Fernandes <rgfernandes> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Raul Fernandes
2002-07-18 01:39:29 UTC
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. |