Hi Sergio-- There are certainly some good use cases for having multiple sets of cookies at once. As Peter mentioned, though, there are challenges to providing a good user experience for this.
For example, suppose you're viewing a page like Amazon where you're logged in, and you open a link to a product page in a new tab. Chromium will keep the second tab in the same process, so it would share the same cookies (and thus shopping cart) as the first tab. That's probably what you want, since it's all part of one "browsing instance." However, how can the user tell that those two tabs are connected but a third independent tab with an Amazon page is not? This is especially hard if the user drags tabs to different windows, where he could end up with something like: Window 1: [ Amazon-session-1, Gmail ] Window 2: [ Amazon-session-1, Amazon-session-2 ] It becomes very hard to know which tabs are sharing cookies and which tabs are not. With our Incognito Mode, you can't drag an Incognito tab into a normal window, and we have a different colored window to show this. It's easy to see which tabs are Incognito and which aren't. Unfortunately, that solution doesn't scale as well if every renderer process has to be colored differently. It's not an impossible problem to solve, but I think we would need to agree on a good UI before doing anything like this. If you or anyone else has ideas, feel free to write them up or create design mocks for discussion. Charlie On Fri, Dec 18, 2009 at 8:57 AM, Sergio Tudela Romero < sergiotudelarom...@gmail.com> wrote: > 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 > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
