On Wed, Jan 13, 2010 at 2:28 PM, <mpcompl...@chromium.org> wrote:
> I've shared Extensions
> Incognito<http://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZz&hl=en&invite=CJ3Si8MG>
> *
> *
>
The idea of having the ability to do both read-only and read-write access to
the main profile is one that's mirrored in the low-level APIs inside
Chromium, where we have an enum that differentiates between these cases that
we can pass when trying to gain access to various data stores, which
modifies what happens. I like this parallel and maybe we can implement the
high-level APIs in terms of those low-level ones.
On Wed, Jan 13, 2010 at 2:45 PM, Antony Sargent <asarg...@chromium.org>
wrote:
> Right now a convenient way to see if a website is having problems due to
> some extension's content script is to open an Incognito window. Would it
> make sense to add a way to easily disable extensions in Incognito mode,
I think the use case is important ("does one of my extensions break stuff"),
but the current method to solve it (open an incognito window) is a hack, so
I wouldn't want to tie a proper solution to Incognito mode. It seems like
this is a good use case to keep in mind when figuring out what UI to give
users to control extensions (and plugins). We have some, but there seems to
be general agreement that we can do more/better (e.g. a simple "disable all"
button).
I also think there's a use case for saying that X extensions should be
enabled/disabled in normal mode but not Incognito, but that may be more
granularity than we can coherently expose in UI.
PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
