Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
Okay, in that case I've posted a similar fix for notifications permissions ( http://codereview.chromium.org/455004). It still seems like if there is a common rule, there might be a better way to do this at the Profile level rather than in each feature; could we mark or otherwise separate certain preferences as origin-specific preferences rather than just overall browser settings? Then the off-the-record PrefsService could filter those out and not persist? -John On Wed, Nov 25, 2009 at 6:35 PM, Peter Kasting wrote: > On Wed, Nov 25, 2009 at 11:38 AM, John Gregg wrote: > >> if you whitelist an origin for popups while in incognito mode, that origin >> is whitelisted permanently even when you go back to normal mode. >> > > On further reflection I'm convinced persisting these changes is wrong. I > have now posted a patch to fix this at > http://codereview.chromium.org/434109 . > > I have similarly updated my change to add per-host remembering of zoom > levels ( http://codereview.chromium.org/437077 ) to also avoid persisting > changes while off the record. > > PK > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 11:38 AM, John Gregg wrote: > if you whitelist an origin for popups while in incognito mode, that origin > is whitelisted permanently even when you go back to normal mode. > On further reflection I'm convinced persisting these changes is wrong. I have now posted a patch to fix this at http://codereview.chromium.org/434109. I have similarly updated my change to add per-host remembering of zoom levels ( http://codereview.chromium.org/437077 ) to also avoid persisting changes while off the record. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:49 PM, John Gregg wrote: > On Wed, Nov 25, 2009 at 12:26 PM, Peter Kasting wrote: > >> This is the sort of thing for which Profile::ServiceAccessType was >> invented. Ideally, things like recording whitelisted popup hosts should >> request IMPLICIT_ACCESS, which should result in no read happening. >> > > From reading the code, I'm not sure that's consistent. Adding a > whitelisted host for popups is a result of a user action (the user choosing > "always allow" from the blocked popup container), so according to the code > comments, that would be an explicit access. It's kind of a gray area: it's > like adding a bookmark in terms of user-initiation, but it also affects web > browsing. > Hmm. On the one hand, we persist things like created bookmarks and downloaded files. On the other hand, we don't preserve changes due to other "user actions" like clicking a link. It's not obvious to me what the best example is. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:26 PM, Peter Kasting wrote: > On Wed, Nov 25, 2009 at 12:14 PM, Adam Barth wrote: > >> On Wed, Nov 25, 2009 at 11:38 AM, John Gregg wrote: >> > if you whitelist an >> > origin for popups while in incognito mode, that origin is whitelisted >> > permanently even when you go back to normal mode. And in my case, it >> > behaves likewise for notifications, since those permissions are stored >> in >> > the PrefsService. Is that how we want it to work? >> >> Nope. That sounds like a bug. We should never write URLs or hosts >> the user visits while in incognito to disk. >> > > This is the sort of thing for which Profile::ServiceAccessType was > invented. Ideally, things like recording whitelisted popup hosts should > request IMPLICIT_ACCESS, which should result in no read happening. > >From reading the code, I'm not sure that's consistent. Adding a whitelisted host for popups is a result of a user action (the user choosing "always allow" from the blocked popup container), so according to the code comments, that would be an explicit access. It's kind of a gray area: it's like adding a bookmark in terms of user-initiation, but it also affects web browsing. -John -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:14 PM, Adam Barth wrote: > On Wed, Nov 25, 2009 at 11:38 AM, John Gregg wrote: > > if you whitelist an > > origin for popups while in incognito mode, that origin is whitelisted > > permanently even when you go back to normal mode. And in my case, it > > behaves likewise for notifications, since those permissions are stored in > > the PrefsService. Is that how we want it to work? > > Nope. That sounds like a bug. We should never write URLs or hosts > the user visits while in incognito to disk. This is the sort of thing for which Profile::ServiceAccessType was invented. Ideally, things like recording whitelisted popup hosts should request IMPLICIT_ACCESS, which should result in no read happening. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 11:38 AM, John Gregg wrote: > Hi, > I was investigating how notifications should work in incognito mode, and > came across the fact that the PrefsService for the incognito profile is the > same one as the real profile. In some ways I guess that makes sense, since > it's state about how the user uses the browser, not what the user is doing. > > But it does lead to some things that seem odd, like if you whitelist an > origin for popups while in incognito mode, that origin is whitelisted > permanently even when you go back to normal mode. And in my case, it > behaves likewise for notifications, since those permissions are stored in > the PrefsService. Is that how we want it to work? Nope. That sounds like a bug. We should never write URLs or hosts the user visits while in incognito to disk. Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] PrefsService shared with OffTheRecordProfile
Hi, I was investigating how notifications should work in incognito mode, and came across the fact that the PrefsService for the incognito profile is the same one as the real profile. In some ways I guess that makes sense, since it's state about *how* the user uses the browser, not what the user is doing. But it does lead to some things that seem odd, like if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. And in my case, it behaves likewise for notifications, since those permissions are stored in the PrefsService. Is that how we want it to work? -John -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
