Bug 322270

> 2) if it'd be used in a valid way ... a RFE would follow to let the user
> override this nonsense - or are we going forward to the past (!back to the
> future) when there were no such things like kdewallet and users had to stick
> post-it notes with login info all around their workplaces?

kdewebkit has always honored the autocomplete attribute when auto filling passwords ; so what is with the "if it'd be used in a valid way..." ???  If you're comparing the khtml engine to the webkit one, then you need to stop right there. Those are two completely different engines. For starters the webkit broswer engine is not part of the KDE project like khtml and as such there are many things one can do in khtml that are not feasible in webkit. Take the very feature severed by the autocomplete attribute. Guess what there is no support for it in the QtWebkit engine. Guess what that means ? Yes that is right, no support for it in Konqueror + webkit engine either.

Anyhow, in the future please stick to reporting the bug instead of interjecting commentary in bug reports. Such shenanigans is a sure way for volunteer developers like myself to ignore your otherwise valid report.

(In reply to comment #1)
> > 2) if it'd be used in a valid way ... a RFE would follow to let the user
> > override this nonsense - or are we going forward to the past (!back to the
> > future) when there were no such things like kdewallet and users had to stick
> > post-it notes with login info all around their workplaces?
> 
> kdewebkit has always honored the autocomplete attribute when auto filling
> passwords ; so what is with the "if it'd be used in a valid way..." ???

sorry for not being clear - I've meant the site itself

see 1), it uses doctype where "autocomplete" is not a valid attribute, so the browser should ignore this attribute in the same way it ignores any other stuff it doesn't understand

if the site would specify doctype where "autocomplete" is a valid attribute, then the browser should honour the value of this attribute, but I'd vote for having a manual override option

> If you're comparing the khtml engine to the webkit one, then you need to stop
> right there. Those are two completely different engines. For starters the
> webkit broswer engine is not part of the KDE project like khtml and as such
> there are many things one can do in khtml that are not feasible in webkit.

I know this, but what I do not know is what exact parts of the browser functionality are provided by the engine itselft (webkit or khtml) and what parts are provided by konqueror/kdelibs/whatever else

in this very case, there has to be some code which takes care of talking to kdewallet that I suppose is part of the KDE project and not Qt project ... and I really do not know how far this code reaches and how it can or can not influence the completion options

the same goes for the autocompletion blacklist - I believe this is managed by the browser, which takes care about saving the configuration etc., the engine itself probably doesn't have access to the configuration file, but I do not know where is the border between one and another project here

> Take the very feature severed by the autocomplete attribute. Guess what
> there is no support for it in the QtWebkit engine. Guess what that means ?
> Yes that is right, no support for it in Konqueror + webkit engine either.

if there is something that needs to be done somewhere else (the Qt project), I'd expect (pretty please with sugar on top :-)) the developers to report that wherever needed

as an user, I have nearly zero knowledge about the browser internals, I'm using the final product, not the individual libraries, so I'm reporting to the browser, as I cannot identify which library is responsible for what

> Anyhow, in the future please stick to reporting the bug instead of
> interjecting commentary in bug reports. Such shenanigans is a sure way for
> volunteer developers like myself to ignore your otherwise valid report.

I'm really sorry you see it as shenanigans, I was hoping that providing my POV will help to understand what the issue is and the user needs - similar as above, based on my limited knowledge, I cannot decide what is useful info for development and what is just a cruft despite being important for me

(In reply to comment #2)
> (In reply to comment #1)
> > > 2) if it'd be used in a valid way ... a RFE would follow to let the user
> > > override this nonsense - or are we going forward to the past (!back to the
> > > future) when there were no such things like kdewallet and users had to stick
> > > post-it notes with login info all around their workplaces?
> > 
> > kdewebkit has always honored the autocomplete attribute when auto filling
> > passwords ; so what is with the "if it'd be used in a valid way..." ???
> 
> sorry for not being clear - I've meant the site itself
> 
> see 1), it uses doctype where "autocomplete" is not a valid attribute, so
> the browser should ignore this attribute in the same way it ignores any
> other stuff it doesn't understand
>
> if the site would specify doctype where "autocomplete" is a valid attribute,
> then the browser should honour the value of this attribute, but I'd vote for
> having a manual override option

Well, that is what I was trying to address. kdewebkit is not a browser engine. Rather it is a thin wrapper for QtWebKit to make it work with KDE technologies (KIO, KDE Wallet etc). As such, the code it uses to find forms to fill is written in javascript which we execute once a page has been completely rendered. As such we do not care about what doctype the page is using. IOW, the form filling is not a feature or functionality found in QtWebKit. It does provide an API for traversing the DOM of a page, but that API is mostly useless for finding forms on complex web pages. Hence, the use of our own client side javascript for parsing and filling out web pages. 

Hope that clarifies, or at least shades some light on, how KDE wallet integration works in Konqueror's webkit engine part. Please note that this does not apply to the khtml engine. That is a completely different matter since its support is built right into the engine itself.
 
> > If you're comparing the khtml engine to the webkit one, then you need to stop
> > right there. Those are two completely different engines. For starters the
> > webkit broswer engine is not part of the KDE project like khtml and as such
> > there are many things one can do in khtml that are not feasible in webkit.
> 
> I know this, but what I do not know is what exact parts of the browser
> functionality are provided by the engine itselft (webkit or khtml) and what
> parts are provided by konqueror/kdelibs/whatever else

Everything except the KDE integration and missing functionality we can add through javascript, like form filling, is handled by QtWebKit itself.

> in this very case, there has to be some code which takes care of talking to
> kdewallet that I suppose is part of the KDE project and not Qt project ...
> and I really do not know how far this code reaches and how it can or can not
> influence the completion options
> 
> the same goes for the autocompletion blacklist - I believe this is managed
> by the browser, which takes care about saving the configuration etc., the
> engine itself probably doesn't have access to the configuration file, but I
> do not know where is the border between one and another project here

I hope this is already answered by my response above. We honor the autocomplete attribute because it is supported by all the other major browsers except Opera. And since Opera now uses the Chrome's new engine, it probably will end up supporting that attribute as well. See the documentation of autocomplete at https://developer.mozilla.org/en-US/docs/Mozilla/How_to_Turn_Off_Form_Autocompletion.
 
> > Take the very feature severed by the autocomplete attribute. Guess what
> > there is no support for it in the QtWebkit engine. Guess what that means ?
> > Yes that is right, no support for it in Konqueror + webkit engine either.
> 
> if there is something that needs to be done somewhere else (the Qt project),
> I'd expect (pretty please with sugar on top :-)) the developers to report
> that wherever needed

We try to for feature request that we think belong in the upstream project. However, that does not mean our requests will be implemented either. See https://bugs.webkit.org/show_bug.cgi?id=36668 for example.

> as an user, I have nearly zero knowledge about the browser internals, I'm
> using the final product, not the individual libraries, so I'm reporting to
> the browser, as I cannot identify which library is responsible for what
> 
> > Anyhow, in the future please stick to reporting the bug instead of
> > interjecting commentary in bug reports. Such shenanigans is a sure way for
> > volunteer developers like myself to ignore your otherwise valid report.
> 
> I'm really sorry you see it as shenanigans, I was hoping that providing my
> POV will help to understand what the issue is and the user needs - similar
> as above, based on my limited knowledge, I cannot decide what is useful info
> for development and what is just a cruft despite being important for me

Everything you put on this bug report was fine except you very last comment in #2. That to me was unnecessary commentary. I have no objections with anything else you said in this bug report. 

Anyhow, I tested the 'Steps to reproduce' against both Firefox and Chromium and neither one prompted to save the password for the site. That is because, just like Konqueror w/ webkit engine, both honor the autocomplete feature for form elements. As such, I do not plan to change the current behavior. However, I might consider adding yet another option to allow users to override the website's settings ; so I will leave this ticket open for future consideration.

(In reply to comment #3)
> Well, that is what I was trying to address. kdewebkit is not a browser
> engine. Rather it is a thin wrapper for QtWebKit to make it work with KDE
> technologies (KIO, KDE Wallet etc). As such, the code it uses to find forms
> to fill is written in javascript which we execute once a page has been
> completely rendered. As such we do not care about what doctype the page is
> using. IOW, the form filling is not a feature or functionality found in
> QtWebKit. It does provide an API for traversing the DOM of a page, but that
> API is mostly useless for finding forms on complex web pages. Hence, the use
> of our own client side javascript for parsing and filling out web pages. 
> 
> Hope that clarifies, or at least shades some light on, how KDE wallet
> integration works in Konqueror's webkit engine part. Please note that this
> does not apply to the khtml engine. That is a completely different matter
> since its support is built right into the engine itself.

thanks for the explanation

> I hope this is already answered by my response above. We honor the
> autocomplete attribute because it is supported by all the other major
> browsers except Opera.

I do not think that this is a good reason

I mean ... it is desirable to _support_ the feature and have the default behaviour the same across all browsers, but having the additional ability to intentionally ignore this attribute would be a competitive advantage if the others do not have this option - a difference between "lead" and "follow"

> We try to for feature request that we think belong in the upstream project.
> However, that does not mean our requests will be implemented either. See
> https://bugs.webkit.org/show_bug.cgi?id=36668 for example.

:-(

> Anyhow, I tested the 'Steps to reproduce' against both Firefox and Chromium
> and neither one prompted to save the password for the site. That is because,
> just like Konqueror w/ webkit engine, both honor the autocomplete feature
> for form elements. As such, I do not plan to change the current behavior.
> However, I might consider adding yet another option to allow users to
> override the website's settings ; so I will leave this ticket open for
> future consideration.

"for future consideration" ... let me ask ... how do you personally handle this issue? do you really type in all the info manually each time you need to log-in somewhere? are you so lucky not to have to log-in on sites with autocomplete=off? something else?

- please don't take me wrong, I'm happy that you've took the time for this report and the explanations, but it is a big annoyance for me and I'm curious how it could be avoided or what I'm missing/doing differently than others who don't seem to be bothered that much ...

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!