[Webkit-unassigned] [Bug 166969] [SOUP] Fix handling of accept language property

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 13 00:39:17 PST 2017


--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #2)
> Comment on attachment 298672 [details]
> Patch
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=298672&action=review
> I noticed this back before we supported network session. (That said, is it
> actually possible to have multiple network sessions in our port yet, or is
> that a future step?)

It is. Open MiniBrowser and enable private browsing in the settings, for example. The other case is testing, NetworkStorageSession::switchToNewTestingSession() creates a new session that is private from the cookie storage point of view, but non ephemeral from the session point of view, so it replaces the default session.

> > Source/WebKit2/NetworkProcess/soup/NetworkProcessSoup.cpp:101
> > +    g_object_set(NetworkStorageSession::defaultStorageSession().soupNetworkSession().soupSession(), "accept-language", acceptLanguages.data(), nullptr);
> > +    NetworkStorageSession::forEach([acceptLanguages](const WebCore::NetworkStorageSession& session) {
> > +        g_object_set(session.soupNetworkSession().soupSession(), "accept-language", acceptLanguages.data(), nullptr);
> Hmmmm
> I think our SoupNetworkSession class should have a helper function that
> wraps this g_object_set(..., "accept-language", ...) so that you don't have
> to do this manually from outside the class. Up until this patch, that was
> SoupNetworkSession::setAcceptLanguages. So I really don't see the advantage
> to this approach. Instead of changing setAcceptLanguages to be static, I
> would call it here, and add a new static function
> SoupNetworkSession::setInitialAcceptLanguages to set it for new
> SoupNetworkSession objects. (I guess it's not possible to pass in via the
> constructor for some reason?)
> This is just a matter of style; I'm willing to give r+ if you disagree, but
> I don't think this is the nicest way.

No, I think this is good idea.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170113/c0dc9cb4/attachment-0001.html>

More information about the webkit-unassigned mailing list