Bug 16589 – WebCore::cookies, WebCore::setCookies and WebCore::cookiesEnabled need access to the WebCore::Document

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Holger Freyther]

Similar to the bug #16588 we need to access the QNetworkAccessManager that the QWebPage is using to return and set the cookies. The information that is always available when calling the function is the WebCore::Document. This allows us to access the WebCore::Frame->FrameLoader->FrameLoaderClient->QWebFrame->QWebPage.

[Holger Freyther]

Created attachment 18078 [details]
add WebCore::Document to the cookie functions

This adds WebCore::Document as the first parameter to the WebCore cookie functions. This allows the Qt port to access the QNetworkAccessManager.

[Maciej Stachowiak]

Comment on attachment 18078 [details]
add WebCore::Document to the cookie functions

r=me

[Alexey Proskuryakov]

Not really disagreeing with Maciej's r+ here, but seeing Document* as a setCookie() parameter is rather confusing to me. Perhaps it would be better to pass FrameLoader or even FrameLoaderClient?

[Darin Adler]

(In reply to comment #3)
> Not really disagreeing with Maciej's r+ here, but seeing Document* as a
> setCookie() parameter is rather confusing to me. Perhaps it would be better to
> pass FrameLoader or even FrameLoaderClient?

When it comes to the Frame constellation of objects, we never want to pass around sub-objects like FrameLoader. FrameLoader is really only the loader aspect of the frame.

So you'd want to pass either Frame or Document. I think Document is the right one.

[Darin Adler]

Comment on attachment 18078 [details]
add WebCore::Document to the cookie functions

This patch no longer applies cleanly, and since it's a git patch and not Subversion, I can't easily figure out what Subversion version it's based on.

So I'm not landing it today. I would have landed it otherwise.

I know it's easier for the Qt hackers to supply git patches since you are using git, but perhaps you could do the additional work to supply them in a form that identifies the base Subversion revision. I know that's possible because the folks here at Apple using git are posting patches that don't show any sign of their git origins.

[Simon Hausmann]

Landed in revision 29566