[webkit-qt] Adding a "view source" API for WebView [feedback needed!]

Jesus Sanchez-Palencia jesus at webkit.org
Wed May 9 13:24:59 PDT 2012


Hi!

On Wed, May 9, 2012 at 8:57 AM, Tor Arne Vestbø
<tor.arne.vestbo at nokia.com>wrote:

>
> I think this is the easiest option, as it does not need new API on the QML
> side. But, the logic of picking up view-source should happen on the web
> process side -- the UI side should know nothing about this special behavior
> (hence no complexity added to the url property).
>

Ok, I agree, but are we talking about moving the entire view-source scheme
handling to the WebProcess? If you are not following me, please check the
latest patch (https://bugs.webkit.org/attachment.cgi?id=140193&action=review),
the MiniBrowser part (at Utils::urlFromUserInput).

We would need to move that into WebPage::loadURL, which would make us use
QUrl::fromUserInput there. This has been crucified already on the
discussions at the bug report. In other words, we would need to:

1- remove the view-source scheme;
2- sanitize the url by calling QUrl::fromUserInput;
3- call WebPage::loadURLRequest using this sanitized and view-source free
url;


On the way, back, on the UI Process, we would end up with a url property
that wouldn't contain the view-source scheme, so some logic would be needed
there as well in order to re-add it.



>
> It also makes it easy to add action to the default context menus to view
> page source and view frame source (we have to handle both cases).
>

Not sure how it covers the view frame source case...



> (Chrome actually uses "view-source:http://foo.com", it's just that it
> hides the http scheme in the url bar (try copying the url into a text
> file).)


I didn't follow you here, sorry. I copied the url into a text file
(Chromium Linux) and I got exactly what I was seeing on the url bar
("view-source:http://www.foo.com").

Thanks for your feedback!

Cheers,
jesus


>
>  3- Implementing a WebViewSource { }, that inherits from WebView.
>> *Pros: a specialized and separate component,
>>
>
> This is to me the least ideal solution, as a specialized and separate
> component is a con to me, indicating that we could not find a good API that
> ties in with the existing WebView or base QML items.
>
> Cheers,
> Tor Arne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20120509/7400bfba/attachment.html>


More information about the webkit-qt mailing list