[webkit-qt] API proposal for handling (some) hybrid use cases

[Dawit A]

On Tue, Oct 11, 2011 at 5:10 PM, Caio Marcelo de Oliveira Filho
<caio.oliveira at openbossa.org> wrote:
> Hello guys,
>
> As stated in http://labs.qt.nokia.com/2011/08/31/an-oldnew-approach-to-qtwebkit-hybrid/,
> because of the way WK2 works, some previous APIs we had are more
> difficult to implement than it was in WK1. This email explains an API
> proposal to handle some of the cases in the context of WK2.
>
> In our API for WK1 we had the following "hybrid" features available:
>
> 1) QWebElement -> manipulating the DOM. Example: adblocker
> functionality of a web browser can be implemented using this API.

Speaking from experience of attempting to implement ad blocking using
QWebElement, I can definitely state that it  is almost useless for ad
blocking or content filtering purposes in general. That is because the
contents of entire page has to be first retrieved before you can
properly access the elements using it. This is too late ad
blocking/content filtering since by definition you do not want to
retrieve those resources in the first place. It would be too late to
use QWebElement.

Right now, the only place where implementing this feature is somewhat
feasible in QtWebKit is in in QNAM::createRequest. Unfortunately, that
approach too is limited because there is no way to know which element
actually sent a particular network request since QNAM is too generic
and not specific to QtWebKit. :(

What QWebElement would have been good for is to fill out forms on a
web page, e.g. saved login information for a web site. It is too bad
that a bug prevents this from working correctly all the time. See bug#
63603.

> 5) QNetworkAccessManager customization -> expose custom protocols to
> the web page you are loading. It is a different way to expose content,
> both to be loaded by the browser or the JS itself.

The use of QNetworkAccessManager goes beyond that for those of us that
work on integrating QtWebKit into KDE. In QtWebKit1 we can easily
replace the QNetworkAccessManager QtWebKit uses with our own custom
implementation that use KIO and KDE's cookiejar through
QWebPage::setNetworkAccessManager. Without an equivalent capability in
QtWebKit2, it would impossible for KDE's QtWebKit integration library
(kdewebkit) to switch over to QtWebKit2. I just thought I add this
additional use case into the mix to highlight how significant this is
to some of us.

> 7) Embedding QWidgets inside a web page via QWebPluginFactory
<snipped>
> 7) QWidgets inside a page: do we have users for this?

Yes. How would QtWebKit2 handle the <embed> tag for content it does
not support ? For example,

<embed type="application/pdf"
src="http://ev.kde.org/reports/ev-quarterly-2011_Q2.pdf" width="75%"
height="400"/>

Is it going to completely ignore this as it does now ? At least now,
one can simply implement a custom plugin factory that will handle such
cases as we do in kdewebkit. If no replacement is available for
QWebPluginFactory then no one will be able to display such content.