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

[kavol]

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

--- Comment #4 from kavol <kavol at seznam.cz> ---
(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 ...

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