[Webkit-unassigned] [Bug 29975] [Qt] Inform the application when a new request is created.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29975





--- Comment #18 from Simon Hausmann <hausmann at webkit.org>  2009-10-07 06:01:24 PDT ---
(In reply to comment #12)
[...]
> In the existing Wallet support of Arora we must wait until the createRequest
> comes through to QNetworkAccessManager to be able to read the outgoingData
> which contains the final form data.  At this point in time We only have a
> QNetworkRequest and need a way to make a request->qwebframe to find the form in
> the frame.  Not only do we want the frame, but we want the
> QWebPage::NavigationType.

That is a good example! So in an ideal world you'd have the QWebFrame pointer
as an argument in the virtual createRequest function in QNetworkAccessManager,
right?

We might be able to fix that, but what about the navigation type? By the time
we create the QNetworkRequest we do not know the underlying Navigation type.

Can you explain how you would use the NavigationType?

What we otherwise thought of was to have an extension in QWebPage, similar to
Robert's proposal, that would change the current call chain from
QNetworkReplyHandler -> QNetworkAccessManager::createRequest() to
QNetworkReplyHandler ->
QWebPage::CreateNetworkRequestExtension-with-same-arguments-as-createRequest-and-a-QWebFrame-pointer
-> QNetworkAccessManager::createRequest(), where you could hook into the middle
part.

> On the status bar Arora currently only shows a percentage of the webpage that
> was loaded.  If we had a way to see what frame requests came from we could
> provide better information about what a page is downloading.

Can you elaborate on what you would display?

> All of the QNetworkAccessManager signals that bring up a dialog currently only
> give you a QNetworkReply
> 
> void authenticationRequired ( QNetworkReply * reply, QAuthenticator *
> authenticator )
> void finished ( QNetworkReply * reply )
> void proxyAuthenticationRequired ( const QNetworkProxy & proxy, QAuthenticator
> * authenticator )
> void sslErrors ( QNetworkReply * reply, const QList<QSslError> & errors )
> 
> Because of this if you have multiple QWebPages you must block the entire
> application rather then just the QWebPage that need to prompt the user for
> something.

That is a very good point!

> QtWebKit actively encourages that application have only 1 QNetworkAccessManager
> that is shared among all of the existing QWebPages.  There are a number of
> valid reasons for this
> - Only X number of connections to a host at a time
> - QNetworkCookieJar and QNetworkDiskCache syncing issues
> - Memory and cpu usage of running multiple of these of course
> 
> While you can go through and setup a QNetworkAccessManager that is a proxy for
> each QWebPage this has many downsides such as more confusing code, memory
> overhead for each manager/cookiejar object.  You can see this approach in Arora
> today here: http://github.com/Arora/arora/tree/master/src/utils/

That is also a very good point. It should not be necessary to write such a
proxy. Avoiding it should be a goal of the API. Thanks for the elaborate
explanation!

> Talking with Thiago back in the day about this he mentioned how
> QNetworkAccessManager and QNetworkRequest were designed so that it was
> QNetworkRequest that had the ability for developers to add data to that would
> be sent through the system using QNetworkRequest::User
> http://doc.trolltech.com/4.5/qnetworkrequest.html#Attribute-enum
> 
> Having a QNetworkAccessManager proxy is working around the fact that QtWebKit
> currently actively doesn't let you set anything in QNetworkRequests.

I admit I like the idea of adding properties or attributes to QNetworkRequest
"on the way" as it is passed through the software stack, but I am concerned
about storing a pointer to a QObject in this value based class.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.