[Webkit-unassigned] [Bug 35942] [GTK] Fails http/tests/plugins/third-party-cookie-accept-policy.html

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Xan Lopez <xan.lopez at gmail.com>  2010-03-10 05:52:05 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > About the patch, I'm not sure why it's stopping calling setDefaultCookieJar on
> > the jar it creates, not sure that's right.
> 
> If you look at the old code, if you called defaultCookieJar(), and then called
> setDefaultCookieJar() with a different cookie jar, the original default would
> get leaked. The change makes it not leak.

Oh, I see, because it has one extra reference right? OK. I was confused because
I thought you meant the function didn't try to release it, but that it does.

> 
> (In reply to comment #3)
> > Attachment 50363 [details] [details] did not build on gtk:
> > Build output: http://webkit-commit-queue.appspot.com/results/547002
> 
> > checking for LIBSOUP_2_29_90... no
> > ...
> > ../../WebCore/platform/network/soup/CookieJarSoup.cpp:41: error: ‘soup_cookie_jar_set_accept_policy’ was not declared in this scope
> 
> so, I guess the build would be fixed by adding some #ifdef HAVE_LIBSOUP_2_29_90
> to the patch, but assuming that this is the build that would get used for the
> tests, the test would still fail because it was using a pre-cookie-policy
> version of libsoup. So I don't think we can unskip the test until the
> build/test machines have a newer libsoup.

Keep in mind that the bots without a new libsoup are the EWS ones, our own GTK+
bots do have a recent enough libsoup.

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