Hello again.
Thanks for the explanation, I have been quite clear how the system
works currently. Also I've just seen in the code ... a profile has a
stock of biscuits.
The fact is that every time a cookie is saved the "key" to this is the
domain where it was created (is this the problme for me). Thus I could
never have 2 cookies in a single domain since both have the same
"key".
My question is:
Could we not use the key to this cookie as the process id of the tab
(I speak in the event of such Model: process-per-tab)? Thus we may
have several cookies for 1 domain.
In other: 1 domain with several different cookies differences with the
"key" the process id of that tab... using a single cookies store that
offers the profile of this render.
Current Model (process-per-tab) :
1 Render - 1 profile - 1 storage of cookies - 1 cookie per domain (the
key of the cookie is the domain).
My model optional (I always speak as a new option on your chromium):
1 Render - 1 profile - 1 storage of cookies - N cookies for 1 domain
(the key of the cookie is the process id of the tab).
Greetings !
On Dec 16, 10:53 pm, Peter Kasting <pkast...@google.com> wrote:
> Chromium code has the concept of a "Profile". All renderers are associated
> with a profile. There is one cookie store per profile.
>
> By default, renderers are all given the same profile. When you use
> Incognito mode, for the purposes of cookies you can think of it like
> creating a new profile which will never be saved to disk, so Incognito tabs'
> cookie stores are distinct from non-Incognito tabs.
>
> From a UI point of view we don't allow tabs from separate profiles to
> cohabit the same window. Thus to the user it appears we have Incognito vs.
> non-Incognito windows, not tabs.
>
> There is code in place to provide some basic UI for having multiple
> (non-Incognito) profiles. It's off by default. There are probably bugs and
> the user experience isn't good. The closest bug about providing a good UX
> for this functionality is crbug.com/812 . There is no timeframe on that
> work, or necessarily even agreement that it will ever happen.
>
> PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
