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