[WebKit-devel] [kdelibs] [Bug 322270] login info not pre-filled when using webkit

[Dawit Alemayehu]

https://bugs.kde.org/show_bug.cgi?id=322270

Dawit Alemayehu <adawit at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor

--- Comment #3 from Dawit Alemayehu <adawit at kde.org> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.