From konq-bugs Tue Sep 27 15:45:52 2011 From: Dawit Alemayehu Date: Tue, 27 Sep 2011 15:45:52 +0000 To: konq-bugs Subject: [Bug 280277] defective password handling (old password can't be Message-Id: X-MARC-Message: https://marc.info/?l=konq-bugs&m=131713837810055 https://bugs.kde.org/show_bug.cgi?id=280277 --- Comment #3 from Dawit Alemayehu 2011-09-27 15:45:51 --- (In reply to comment #2) > I just tried it, and it worked (though see below): But that is very-well hidden > --- It never occurred to me that any action would be associated we any of these > tiny symbols, and I don't think there is anything about it in the Handbook > (available under Help), nor could I find anything about this in the > Internet (by a general search). And then *only* a right-click does something ... > well hidden. Those options and icons are part of the browsing rendering engine which konqueror embeds and not konqueror itself. In your case you seem to be using KHTML as the default browsing engine, "Settings->Configure Konqueror->Default web browser engine". Otherwise, a left click on the said icon should launch the Wallet management tool if it is installed on your system. > Perhaps something explicit could happen at the time when the > password is entered; best, perhaps(!), if Konqueror would detect the > password failure and would then offer a menu. There is no way for the rendering engine, which is embeded into konqueror, to know when a login at a remote site failed unless it uses something hacky and even then it won't work properly all the time ; so no this is not a possiblity. > Better, the password-related action must make it into the main menus, a > new entry "Password handling". I think it is about *explicit* action, > controlled by the user (it just doesn't work too many times, the clever > hidden actions, hiding everything under the hood). You mean hidden in plain site ? Anyhow, those icons on the bottom are not there for decoration, they must serve a purpose, right ? I do however agree that there might be lack of documentation, but that is why there are many support forums where you could easily ask this question and get an answer. > As I said originally, in my understanding the best solution (ever) is just > to make all configuration file-based, with the possibility to edit the files. > Just compare how easy it is to do all sorts of configurations with git --- > no need to search for anything, but just go to .git/config ! Hmm... you just claimed about how difficult it was to find the option and now you advocate we hide it in some obscure file which the user has to manipulate manually ? How does that make sense ? Anyhow, this cannot be done simply because the passwords are stored in an encrypted file. However, the wallet comes with its own management application tool that you can use to modify and delete passwords for any website. If this tool is installed on your system, you can simply lanuch it by typing kwalletmanager in KRunner (ALT+F2) or alternatively you can click on K->Applications->System->Wallet Management Tool. The passwords by default should be located under "Form Data->Maps" in the "kdewallet" wallet. > Another example for the superiority of an explicit configuration > management via files (which would also be always the same --- for all > KDE applications!) comes now, that I have successfully deleted the password > on the site mentioned above --- I can't store the new one now! Since the > site quickly changes to a different page, the little menu with "store" etc. > appears only for such a short time, that although I tried at least 10 times > (really) there is no chance to press on that button. The back-button doesn't > work. If there would be a file-based configuration, then I would just add > an explicit entry for that website, and that would be it. That is a bug in the rendering engine of your choice, pure and simple. Sorry, but modifying a configuration file is not a superior approach simply because of a bug in the current implementation. You should open a bug report against the rendering engine that you are currently using and have that issue addressed. I cannot reproduce this problem here, but I only tested it with the WebKit rendering engine. > Or, with a menu-entry "Password handling", likely best under "Tools", there > should be an explicit action for storing passwords. That is possible so long as someone steps up to write the necessary plugin. All the items you see under Tools in Konqueror are plugins/extensions that are outside of Konqueror. > In any case, it seems very strange to me that that these buttons for storing > passwords are affected in any way by the actions of the website --- it is a > Konqueror-internal thing, and thus should be completely unaffected by anything > which happens on the webpage. (And, by the way, these buttons etc. should > give more explicit information: At least which URL (or is it a regular > expression) is concerned, to inform the user. All that missing information, > it is so tedious (and actually depressing -- brave new world).) > > I finally just managed to press quickly enough on the store-button, to get it > all working again (as I said, more than 10 trials). I don't think that many > elderly persons for example would be able to move the mouse quickly and > precisely enough. > Quite an amount of work ... Again that is a bug and you should open a bug report against the appropriate rendering engine. In this case it seems to be KHTML, but you can find out what you are using through the steps mentioned above. > In any way, the whole issue here then should likely be moved to user-interface > issues. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Konq-bugs mailing list Konq-bugs@kde.org https://mail.kde.org/mailman/listinfo/konq-bugs