Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc3.3.1 OS: Linux hi George Not sure if this is a konq or a kwallet issue... But if one konq has tried to open a wallet and the wallet password dialog is open, any other instances of konq going block too, even if newly started. This is an issue when restoring a session, konq may restore on a different desktop, kwallet opens the password dialog there, and back on desktop 1 you have no idea why all your other konqs block as soon as you look at HTML.

Subject: Re: New: multiple instances of konq block if one is already waiting for a kwallet to be opened On Thursday 18 December 2003 18:48, you wrote: > Not sure if this is a konq or a kwallet issue... > > But if one konq has tried to open a wallet and the wallet password dialog > is open, any other instances of konq going block too, even if newly > started. > > This is an issue when restoring a session, konq may restore on a different > desktop, kwallet opens the password dialog there, and back on desktop 1 you > have no idea why all your other konqs block as soon as you look at HTML. Well if they all need access to the wallet, they do have to block, but they should continue in the event loop since I think I fixed this weeks ago. When did you last update?

Subject: Re: multiple instances of konq block if one is already waiting for a kwallet to be opened On Thursday 18 December 2003 23:55, George Staikos wrote: > Well if they all need access to the wallet, they do have to block, but > they should continue in the event loop since I think I fixed this weeks > ago. When did you last update? Just yesterday, sorry :/. Once the kwallet password dialog window is up, any subsequent Konqs started run fine until they request a webpage, in which case they block, no repaints, and with no indication that they're blocked on the kwallet dialog, which may be hidden.

Yes I can reproduce this now.

*** Bug 73993 has been marked as a duplicate of this bug. ***

*** Bug 79452 has been marked as a duplicate of this bug. ***

*** Bug 69888 has been marked as a duplicate of this bug. ***

*** Bug 83889 has been marked as a duplicate of this bug. ***

I have a few more observations, some of which may be more related than others. 1) In normal operation after you open the wallet you are not prompted again for a password until the timeout period has elapsed that is configured. However after KDE starts up and resumes all of these wallet protected sites, kwallet prompts you for the kwallet password for every site (most of the time! occassionally it seems not to do this... seemingly -- hard to really figure out the pattern here -- if i wait a long time before entering the first password... that is, until long after all konq windows have stopped trying to resume). 2) I have had too many times where konq windows are blocked waiting for kwallet, and there is *no* kwallet password prompt to be found anywhere on any desktop. I can't figure out what is happening here. It seems almost like there is a hidden window somewhere wanting to access kwallet, and kwallet has a hidden prompt asking for a password or permission, or something. I don't know. Related to #2, i do know that last time this happened i manually closed all konqueror windows on all desktops; yet my process list still showed a whole bunch of them, along with kio_http and kio_https processes running. Zombies? I manually killed them all off... but it didn't help. The only way to get kwallet to let me have access is to restart KDE... which also is weird, because the last time i started KDE it got stuck, but the next time it doesn't (and i have session saving on manual, so it's not auto-saving any sessions on shutdown). Something weird about some konq sessions seemingly getting stuck and never starting up fully? But this is another topic. I just wish I knew some way i could identify which process kwallet is prompting for in the case of the seemingly 'hidden' situation above. The way some of the problems above are inconsistant and apparently sometimes timing senstivive, one almost wonders if it's not some sort of race condition happening somewhere... but i really don't know.

It does not have to be two instances of Konqueror that are both waiting for kwallet - it also happens when you start e.g. kopete which will popup a kwallet password dialog. Then if I do not feel like entering it immediately but start a browsing session first, and go to a site for which kwallet has stored the password, konqueror hangs until I have closed the kopete/kwallet password dialog. It hangs in a real ugly way too, it does not handle events, no redraws, just hangs completely. In my opinion it should be possible to have several kwallet password dialogs at once (at least for different applications!). It is unacceptable for every kwallet-depending app to hang if there is already a password dialog in some other (completely unrelated) app. So this is probably a kwallet issue? I'm using KDE 3.3.0/gcc 3.3.2 on Gentoo (without any funny optimizing settings, before you ask ;)

This is a bug in each application (KHTML, Kopete, KMail, KNode, etc), and not a bug in KWallet. It has been determined that they use KWallet in a fashion that requires this behaviour. Once they are fixed, it won't block anymore. They need to use the non-blocking (asynchronous) version of KWalletClient. I will reassign this bug to KHTML for now since it's most prominent.

It is also a bug in the wallet system because it does not make it obvious what the issue is. Why can't the dialog for the password be moved to and brought to front in any of such applications?

*** Bug 88566 has been marked as a duplicate of this bug. ***

*** Bug 89790 has been marked as a duplicate of this bug. ***

CVS commit by staikos: KHTML doesn't block when trying to -read- from KWallet anymore. Writing is still synchronous due to a few issues which need to be sorted out. CCBUG: 68684, 70789, 90915 BUG: 75549 M +108 -6 khtml_part.cpp 1.1042 M +7 -1 khtml_part.h 1.267 M +55 -0 khtmlpart_p.h 1.58 M +25 -19 html/html_formimpl.cpp 1.399 M +6 -1 html/html_formimpl.h 1.158

CVS commit by staikos: So far it works well so I'm committing this rather complicated fix set. Details: 1) Save to KWallet asynchronously from KHTML whenever saving a -new- entry. 2) When possibly saving a new entry, prompt the user if he wants to save before opening the wallet. 3) Fix several bugs in transaction handling and asynchronous handling in kwalletd. 4) KWalletClient ignores handles of 0. 5) KWalletD never returns handles of 0 except in case of "please wait" during asynchronous opens. This may affect anyone using kwalletd directly via DCOP with openAsynchronous. It fixes a big bug though. 6) Fix some cases where opening failed improperly. 7) Fix some minor issues with my last KHTML fixes. CCBUG: 68684, 70789, 90915 One item left to fix in KHTML: dealing with possibly changing an existing entry when the wallet isn't open yet. All of these fixes should be backported together (basically all of kwalletd, kwalletclient, and khtml changes). M +34 -27 khtml/khtml_part.cpp 1.1043 M +3 -0 khtml/khtmlpart_p.h 1.59 M +24 -25 khtml/html/html_formimpl.cpp 1.400 M +161 -107 kio/misc/kwalletd/kwalletd.cpp 1.72 M +1 -1 kio/misc/kwalletd/kwalletd.h 1.36 M +3 -3 kwallet/client/kwallet.cc 1.45

CVS commit by staikos: Commit my patch as posted to kfm-devel, plus more: 1) KHTMLPart::wallet() is undeprecated, I just modified its behaviour slightly and since it's relatively unused, this should be fine. It now returns NULL a little more often than previously, but it's 100% async. 2) KHTML is 100% KWallet asynchronous now. 3) Fixed a bug where KHTML wouldn't save form data in some circumstances. 4) KHTML now prompts to save before prompting for the wallet password if there is an existing comparable match in the wallet but the wallet is not open. (rare case that it is not open, but in any case it needs to be done for multiple completion support) I believe this covers most of the important wallet issues now. BUG: 70789, 90915 M +1 -20 khtml_part.cpp 1.1049 M +1 -1 khtml_part.h 1.268 M +52 -40 html/html_formimpl.cpp 1.408 M +2 -1 html/html_formimpl.h 1.160

*** Bug 58418 has been marked as a duplicate of this bug. ***

This is odd. More than three years after this is marked resolved I have that blocking behavior: When I have an open kwallet password dialog (requested by one konq session) I cannot open a new konq session, the window does not even show up until I finish the kwallet dialog. No other KDE-app involved. Can't believe this patch got lost. KDE Version 3.5.9 (KDE 3.5.9 "release 51.2" , openSUSE ) Application Web Browser/File Manager Operating System Linux (i686) release 2.6.22.17-0.1-default Compiler Target: i586-suse-linux