On pages which require a password to be entered the password is not stored by kwallet - konqueror doesn't even ask to store it. Entering it manually into kwallet does nothing - konqueror doesn't fill it in. This has last worked with konqeuror3 and it's very irritating! Reproducible: Always Steps to Reproduce: 1. https://lists.sourceforge.net/lists/admindb/smartmontools-database 2. Enter some random stuff 3. Actual Results: konqueror fails to ask to store the password in kwallet. Expected Results: Password is stored in kwallet and retrieved from there.
Which browser engine are you using? Do you have this problem only for this site or every website where you enter your credentials?
webkit - the default. khtml stopped being functional on too many websites a long time ago. I am seeing this problem on a number of sites and will start making a list. It was much worse on KDE 4.7.2, but has not been solved completely. konqueror 3 never had this problem. There are websites now setting a "do not store these passwords" flag so browsers need a corresponding "ignore this nonsense" setting, but I didn't think sourceforge uses it. I used to use konqueror 3 for sourceforge because passwords worked.
(In reply to comment #2) > webkit - the default. khtml stopped being functional on too many websites a > long time ago. > I am seeing this problem on a number of sites and will start making a list. > It was much worse on KDE 4.7.2, but has not been solved completely. > konqueror 3 never had this problem. Right. Providing actual sites means I can see if I can reproduce the problem or not. And unfortunately some of the remaining sites will never be completely in the short term because of very difficult technical reasons. For example see https://bugs.kde.org/show_bug.cgi?id=287689. > There are websites now setting a "do not store these passwords" flag so > browsers need a corresponding "ignore this nonsense" setting, but I didn't > think sourceforge uses it. I used to use konqueror 3 for sourceforge because > passwords worked. I can tell you that the wallet integration for kdewebkit honors the autocomplete attribute for input elements and the fact that there is no way for the user to override that functionality is a known issue. See https://bugs.kde.org/show_bug.cgi?id=322270. Having said that, I cannot reproduce the problem at sourceforge. I tested it by purposefully filling in the login form with bogus login information I was prompted to save the password.
Thanks! Also for the two reportlinks, bug#322270 is also what I am seeing. My take on autocomplete="off" is that it was invented for protecting less capable users from themselves (to put it politely). That browsers, especially Linux ones, get the capability to deal with the changing times (and not just by turning the KDE wallet subsystem into a pumpkin) can be called an ehancement request, not a bug. I see that that is a technical problem because of the number of parts involved by different projects. Thanks muchly for the explanartion in bug#322270! In this particular case konqueror does not ask me to store the password; possibly because it is already stored. This comes from a KDE 3 .kwl file I copied over, and me entering URLs and passwords anually into kwallet in an attempt to get this to work with 4.7.2. Unfortunately the password does not get filled in by konqueror either. I checked and that sourceforge mailman page does not use the autocomplete attribute or javascript, and looks like straight html to me. konqueror neither asks to store the password or fills it in, so for me it's a bug. If you can suggest more things to test I will do so.
https://lists.sourceforge.net/lists/admindb/smartmontools-support Does not ask me to store a password. I had cleared all my existing entries for lists.sourceforge.net/lists/admindb from the wallet. That page is very trivial - no scripts, nothing much to it. I don't understand why the password storage doesn't work.
(In reply to comment #5) > https://lists.sourceforge.net/lists/admindb/smartmontools-support > Does not ask me to store a password. I had cleared all my existing entries > for lists.sourceforge.net/lists/admindb from the wallet. That page is very > trivial - no scripts, nothing much to it. I don't understand why the > password storage doesn't work. It does for me. See the attached screenshot. Have you clicked on never for this site by mistake before? Do you see a little wallet icon on the bottom right corner of Konqueror's status bar when you visit that page? If so, right click on it and if you see "Allow password caching for this site", then that means you have asked for the password not to be remembered at some point in the past. Click on that option to allow password to be stored going forward. Otherwise, I dunno what to tell you. Perhaps you might want to check you wallet settings to make sure you did not accidentally forbid Konqueror from using it?
Created attachment 81992 [details] screenshot
Hi Dawit, thanks muchly, you did something very valuable - you showed that it is supposed to work, so I started looking elsewhere. No such wallet symbol in the bottom right, and passwords work for some few sites in my konqueror. With a new user account it works indeed as expected, so I started changing the browser settings. I can only regard browsing all sites with java turned on as brain-dead, and I won't browse with javascript turned on everywhere either (although the white-list in konqueror is pretty cumbersome). Passwords will not be stored or filled on lists.sourceforge.net after I turned javascript off. White-listing this domain only makes passwords work again there. However, as best as I can tell, there is no javascript whatsoever on that site. As a very wild guess, is it possible that the password handling requires javascript? And with webkit, that's obeying the permissions from the preferences even though the sites does not use javascript? I.e., konqueror won't store/insert passwords unless javascript is enabled for that domain? ARRRGHHHH!!!!! I'd see that as a bug.
(In reply to comment #8) > Hi Dawit, thanks muchly, you did something very valuable - you showed that > it is supposed to work, so I started looking elsewhere. No such wallet > symbol in the bottom right, and passwords work for some few sites in my > konqueror. > With a new user account it works indeed as expected, so I started changing > the browser settings. I can only regard browsing all sites with java turned > on as brain-dead, and I won't browse with javascript turned on everywhere > either (although the white-list in konqueror is pretty cumbersome). > Passwords will not be stored or filled on lists.sourceforge.net after I > turned javascript off. White-listing this domain only makes passwords work > again there. However, as best as I can tell, there is no javascript > whatsoever on that site. > As a very wild guess, is it possible that the password handling requires > javascript? And with webkit, that's obeying the permissions from the > preferences even though the sites does not use javascript? I.e., konqueror > won't store/insert passwords unless javascript is enabled for that domain? > ARRRGHHHH!!!!! I'd see that as a bug. Yes, unfortunately password management requires the Javascript to be enabled in kdewebkit. That is because the built-in API does not work under all circumstances and my effort to have that issue resolved upstream did not pan out. See https://bugs.webkit.org/show_bug.cgi?id=63603. As a result, we use javascript to find and fill out forms on web pages.
*** Bug 297799 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!