On Wed, Jan 13, 2010 at 3:09 PM, Drew Wilson <atwil...@chromium.org> wrote:
> Interesting. So if an extension has a background page, the idea is that as
> soon as we open an incognito page every extension with a background page
> would load up a second instance, which would remain running even after the
> incognito window has closed?
I think we can terminate the second background page when the incognito
window closes, but otherwise that is the idea.
One of the things I'm looking at is allowing extensions to expose UI through
> systray icons (part of my proposal to add persistence to extensions) - if
> multiple instances of these extensions were loaded due to incognito windows,
> you'd end up with multiple duplicate systray icons, which seems wonky.
>
> These are all issues that would also occur if you had multiple profiles,
> but I think it'd be confusing to users if there were user-visible artifacts
> of having multiple extensions loaded due to incognito windows.
>
One of the reasons I wanted to address extensions in incognito now is so we
come up with a solution before painting ourselves into a corner. Depending
on the way this systray API is designed, it can be specced so that only one
systray icon is created regardless of incognito.
That said, you bring up a good point in general, and I will add it to the
list of cons. Unfortunately I don't know of any alternative approach that
doesn't cause extensions to violate incognito mode.
> -atw
>
> On Wed, Jan 13, 2010 at 2:57 PM, Peter Kasting <pkast...@google.com>wrote:
>
>> 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
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
