Version: (using KDE KDE 3.3.0) Installed from: Compiled From Sources Compiler: gcc version 3.4.2 OS: Linux When visiting a website that requires I log in, after typing my credentials and hitting submit, I am immediately presented with the password prompt for my kwallet and then after that I'm given the choice of saving the credentials into the wallet or not. Believe it or not, there are times where I don't want it stored. It makes more sense to ask the user 'do you want kwallet to store this info' first, and then if they say yes, open the kwallet (prompting for the password). The current behaviour is backwards
hrm .. I didn't enter 'akregator' in any of the screens when submitting this bug .. I entered 'konqueror' and then chose 'plugins' .. I don't know what's up w/ that .. sorry
aww, forgot to change the product... (btw, I can't change the component in the same time I change the product, should this be possible?)
Yes I support this, but this might be difficult as without opening the wallet how can you know what login/passwords are already saved there.
On Friday 08 October 2004 10:08, nilesh wrote: > ------- Yes I support this, but this might be difficult as without opening > the wallet how can you know what login/passwords are already saved there. You can easily know this. There are hashes stored, and if you get a hit on the hash of your key, then you know there is a good chance it's there.
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
Thank you! This fixes one of the minor annoyances that Konqueror had for me! Can't wait for it to appear in KDE 3.3.x (if it will) :) Jens
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