[chromium-dev] [extensions] Extension Process Model Draft
I wrote up a short design doc covering what our extension process model will look like. Feedback welcome. http://dev.chromium.org/developers/design-documents/extensions/process-model --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Extension Process Model Draft
On Wed, Feb 4, 2009 at 6:07 PM, Charles Reis cr...@chromium.org wrote: This seems good-- I like the fact that the chrome parts of each extension are isolated from page content and have to use message passing. That will make it easier to understand which extensions actually need to access page content. One small wording question, just be sure I'm clear: Process separation by origin is done similarly to web renderers, in that each extension generally gets its own process, but may share a process with another extension as resource constraints demand. I assume by origin, you mean extension? In other words, if I have 3 extensions installed and 10 tabs showing pages from different origins, I'll have 3 extension processes. (Then if I have 30 extensions installed, some of them will share processes.) Yes. Something which was probably unclear in the doc is that each extension will have a unique origin associated with it (something like chrome-extension://EXTENSION_ID), so I was imagining a similar grouping-by-origin could be done for extensions as for web content. Thanks for the feedback. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Extension Process Model Draft
On Tue, Feb 10, 2009 at 5:54 PM, Nick Baum nickb...@chromium.org wrote: Hey Matt, I like this new model, it's nice and simple. One thought: if chrome scripts were actual html pages, they could easily embed an NPAPI plugin for native code. It could have other uses too, for example we could allow the user to reveal this page to see settings, or debug information. On the other hand, I suppose we could provide this functionality in other ways, and keeping them as js makes them somewhat cleaner (no html tags). Any other reasons not to make them full HTML pages? The main reason I made them scripts rather than pages is that they won't be displayed anywhere, so I thought it would be confusing to have extraneous HTML and a DOM. Behind-the-scenes, they'll probably be implemented as an empty page. You bring up some good points, though. I initially considered having a single index.html which would serve as sort of an about plugin page, but I didn't see a compelling use. Now that I think about it, that model might simplify things, and allow NPAPI plugins as you mentioned. Does anyone else have any thoughts about scripts vs full HTML? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how drawing works
Thanks for taking the time to send this out. It was a good learning experience. I have a tangential comment/question, but didn't think it was worth splitting off a second thread. Any thoughts how well extensions will play with our drawing system? Our plan is to allow multiple surface areas in the UI which will be drawn by renderers. Chrome's current backing store cache seems like it was optimized for the 1-tab-at-a-time case, but soon we will be able to have multiple renderers (an arbitrary number, really) visible at all times. What happens if the number of visible renderers exceeds the cache limit? Obviously it's possible to pull tabs out and show more than 5 windows at once. Will this be bad for performance? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Thoughts on scaling
Interesting thoughts. This is sounding more like Android's services (long-running background tasks) and activities (apps run in response to a user action) model. One thought I had in response to this is, who would display the UI? We'd be able to do something primitive in the browser, like static button + text, but for more complicated things, we'd want an HTML renderer. On Mon, Feb 23, 2009 at 11:20 AM, Aaron Boodman a...@chromium.org wrote: The other day I mentioned off-hand in a hallway conversation that I thought it should be a goal for the extensions system in Chrome to significantly increase the average number of extensions installed per user, and to happily support up to 20 or 30 extensions installed at once (both visually and technically). It occurred to me that our current thoughts for how extensions are built may not be the best match for this kind of scalability. For example, we have said that extensions will have a background context that has the same lifetime as the browser process. Such a background context is useful for many types of extensions, but there are probably just as many that don't need it. For example, there are probably lots of tool use cases that only really need to run code after a button is clicked in the toolbar. Similar thoughts around user scripts. Sure it's useful to run code on page load, but there are lots of use cases that don't require that. They only need to inject code into the page when a button is clicked. Another interesting related thought is that an extension which runs code only in response to declared UI is safer than an extension which automatically runs code for every page, or runs code persistently in the background. This all led me to the conclusion that background contexts and user script injection should be options, but not the default way to get things done. Many extensions can be accomplished with some declarative UI, and then some code which will be run when the UI is used. No extension code needs to be run until the user actually chooses to use the extension. As soon as the code is complete the execution environment can be torn down. Extension processes can be created as necessary to support calls from user scripts, or to display HTML UI, but then could go away once they aren't needed anymore. Running background processes and running user scripts automatically could event be a permission that an extension declares that it wants to do and is presented to the user on installation. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient now supports safesync URLs
Would http://build.chromium.org/buildbot/continuous/LATEST/REVISION work
here as well?
On Thu, Apr 9, 2009 at 5:29 PM, Alex Russell slightly...@google.com wrote:
Not sure what our build-bots report. M-A?
Regards
On Thu, Apr 9, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote:
Does this use the latest version that works on windows, linux and mac?
...
or, only windows?
-Darin
On Thu, Apr 9, 2009 at 4:45 PM, Alex Russell slightly...@google.com
wrote:
Howdy all:
The tree has been incredibly green of late thanks to continued
dedication to stability and test fixing, but there are those times
when you might still get bitten by non-green revs costing you time as
you try to figure out why a build failed only to discover it's not
your fault. To avoid this, you can now specify a safesync_url param
in your .gclient solutions. For users with existing .gclient files,
simply add a line like this to your main chrome solution:
solutions = [
{ name: src
#...
safesync_url: http://chromium-status.appspot.com/lkgr;
},
# ...
]
If you're making a fresh checkout, you can just add this URL to your
inital gclient config call. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://chromium-status.appspot.com/lkgr
For the even less adventurous, you might try the unit-and-layout test
green build version # instead. E.g.:
gclient config http://src.chromium.org/svn/trunk/src
http://build.chromium.org/buildbot/continuous/LATEST/REVISION
Regards
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: depricating CppBindingClass
On Wed, Apr 29, 2009 at 6:47 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: 3. Is there a way to specify native getter/setter functions for a property defined on the JS side? For instance, myobject.foo = bar would somehow call a natively defined setFoo function with the bar argument. If this isn't possible, are there any plans to support native properties directly? You can always use __define[SG]etter__. See webkit/extensions/v8/gears_extension.cc for an example. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here
Cookies will not help user scripts, but they will help you with toolstrips and background pages. Both of the latter pages run in an extension process under a common origin, so you can access your extension's cookies from those contexts just fine. You'd need to use the content script communication if you need to inform content scripts about stored settings, though. (Note that cookie support is not in yet.) 2009/5/13 jack js2...@gmail.com Hi Nick, Thanks for your feedback. My understanding is that Chrome is actively working on an official user preference system based on HTML 5 local storage. In the meantime, I was suggested trying bookmarks as a workaround. I haven't tried the new release yet, but in last week it didn't work out because it seemed the communication between the content script and extension (namely chromium.extension.connect() blabla) was not ready yet. As for cookie, unless I missed sth, I think it is not a decent solution because of its strict security/domain restriction (to keep in mind user preference should work browser-wide instead of domain-wide). Any comments are welcome. -Jack On May 13, 8:16 am, Nick Baum nickb...@chromium.org wrote: Hey Jack, This is super cool, thanks for sharing! Matt (cc'd) is working on letting extensions store cookies. Is that what you're missing? Cheers, -Nick 2009/5/12 jack js2...@gmail.com Thanks for your feedback and glad to know it worked for you. Your guess is correct. Although such features are OK in Cleeki's IE/Firefox addons, I haven't figure out a way for Chrome yet. I tried the trick using bookmarking and script/extension communication but it didn't work so far. If anybody here knows how to do this, I'd love to know and integrate it into the add-on. -Jack On 5月12日, 下午10时11分, PhistucK phist...@gmail.com wrote: Works for me. The IE8 Accelerator importing and the preferences work only in the corresponding pages, because the lack of Extensions cookie support, I assume, right? Great job! ☆PhistucK On Tue, May 12, 2009 at 20:47, jack js2...@gmail.com wrote: I recently migrated the Firefox add-on, called Cleeki, into Google Chrome. Cleeki can be used as Google Chrome's Accelerators, only superior to IE8 accelerators. Basically you select any text to search/ share/publish on the Internet, and preview the results in the same page instantly. Installation guideline:http://blog.cleeki.com/?p=70 A quick overview:http://blog.cleeki.com/?p=112 Based on the discussion last week, there is a known issue in current Chrome that the first page might not load the add-on script. Also there is no (easy) user customization yet because of the lack of an official user preference system. I would like to share the add-on in this community in case it is helpful for testing any new release of Chrome. I will actively test it in the up-to-date Chrome and report any bugs. Any of your bug reporting is also welcome. I hope when Chrome add-on system becomes official, this add-on will also be ready (or almost). Thanks for your attention and any of your comments are welcome. -Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How do I deploy an NPAPI plugin over the internet from HTML ?
On Wed, Jun 24, 2009 at 4:42 AM, Non-Stick kevin.ra...@ntlworld.comwrote:: embed id=MY_PLUGIN type=application/my-plugin width=640 height=480 pluginspage=http://mysite.com/test/npapi/chrome/ myplugin.crx ..snip.. What am I doing wrong ? You can't embed Chrome extensions (.crx files). You can only embed NPAPI plugins. These are two different beasts. CRX files must be manually installed by the user - embed won't download them for you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: extensions and memory usage
I suspect a big chunk of the memory is the V8 heap. Each process that uses V8 will need a separate heap. We could experiment with lowering the heap size for extensions, if we think extensions will be less script heavy than web pages. On Fri, Jul 10, 2009 at 5:37 PM, Erik Kay erik...@chromium.org wrote: As we add more subprocesses (workers, utilities, extensions, etc.), it would be great if we could reduce the minimum memory that these processes consume. I know that there was some work done a while back to look at what was the minimum cost of a new process on Windows given our dll size, etc. (maruel?), but I'm sure that there's more than can be done for us to reduce memory usage above this level. Erik On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: As extensions are visible in the task manager, it's also possible to see their memory usage. I was experimenting with some sample extensions, and the usage seems to be in range 1 MB - 12 MB. Typically 3-5 MB. I wonder if it would be possible to reduce that memory usage. In case it negatively affects performance, we could have some opt-in way for extension developers to say I want my extensions to run as fast as possible, even with increased memory usage. What do you think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Notes on storing extension manifest in preferences
On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman a...@chromium.org wrote: a) I think it is important to not break the extension system with this mod, so that means that for awhile (1 or 2 dev channel releases?) we will both write the entire manifest to the prefs and load from disk normally. What if on extension load, we checked the prefs first, and if the manifest entry was absent, then we loaded from disk? New extension installs would write only to the pref. Seems like that would get us transparent backwards compat. b) Extension prefs are currently written in ExtensionsService::OnExtensionInstalled. At this point, we no longer have the JSON form of the manifest, it has already been parsed into an Extension object. It's easy enough to pass along the JSON object from OnExtensionUnpacked, which calls OnExtensionInstalled. b) and c) lead me to the conclusion that we should refactor the Extension class so that it is a lightweight wrapper around a JSON dictionary and has no state of its own. This would fix the problem of not having access to the JSON representation and therefore having to write serialization code for it. A less radical approach would be to keep a copy of the JSON dictionary in the Extension class while we're in this migration period. That's not to say we shouldn't refactor the Extension class (I have no opinion on that). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal: chrome.tabs.executeContentScript()
One pie-in-the-sky idea I have is to pre-compile content scripts. Restricting the API to static JS files would allow us to do such a thing. On Wed, Jul 15, 2009 at 11:41 AM, Jói joi.sigurds...@gmail.com wrote: This seems very useful to me. Perhaps it would be useful to also let extensions directly execute snippets of script, both for convenience and so that they don't need to be static files that are baked into the extension. You could imagine e.g. a content script that is dynamically generated based on preferences. Cheers, Jói On Jul 15, 2:26 pm, Aaron Boodman a...@chromium.org wrote: On Wed, Jul 15, 2009 at 11:22 AM, Aaron Boodmana...@chromium.org wrote: Hence: http://sites.google.com/a/chromium.org/dev/developers/design-document... Typo. Should have been: http://sites.google.com/a/chromium.org/dev/developers/design-document... - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Proposal: get extension views by type
nit: I'd prefer getTabs instead of getTabContents. On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman a...@chromium.org wrote: We currently have the ability to get a list of references to all the DOMWindows in your own extension via chrome.extension.getViews(). But there have been requests to be able to get just the toolstrips, or just the background page. Additionally, I've heard requests for getting just the toolstrips associated with a particular window. Hence: http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal Feedback desired! - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Proposal: get extension views by type
Also, for most of our APIs, not specifying a windowId generally means my current window, while this means all windows. It might be better to be consistent with those APIs here. We could introduce a special windowId constant like kAllWindows to satisfy the other case. On Wed, Jul 15, 2009 at 3:46 PM, Matt Perry mpcompl...@chromium.org wrote: nit: I'd prefer getTabs instead of getTabContents. On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman a...@chromium.org wrote: We currently have the ability to get a list of references to all the DOMWindows in your own extension via chrome.extension.getViews(). But there have been requests to be able to get just the toolstrips, or just the background page. Additionally, I've heard requests for getting just the toolstrips associated with a particular window. Hence: http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal Feedback desired! - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] Using system libraries for Chromium
Rather than changing the code, can you do some tricks so that #include
third_party/libpng/png.h
that includes a forwarding file that includes png.h? I'm thinking, in the
case that we want to build with system libpng:- ensure forwarding_includes
is first in the include order
- add file forwarding_includes/third_party/libpng/png.h that does #include
png.h
Or maybe just
- change the code to #include forwarding_includes/libpng/png.h
- add forwarding_includes/libpng/png.h that includes either png.h or
third_party/png.h, depending on the build flags.
On Wed, Jul 22, 2009 at 2:43 PM, Adam Langley a...@chromium.org wrote:
Context: both fta (Ubuntu) and Tom (Fedora) patch Chromium to use the
system versions of libpng, libz etc. This seems perfectly reasonable,
it saves memory, startup times etc. We should support this without
patching the code.
I have a prototype CL for libpng: http://codereview.chromium.org/159229
I'm requesting comments on the style.
At first I thought about creating a 'shadow includes' directory which
would look like
build/
linux/
shadow/
third_party/
libpng/
png.h - #include png.h
If this directory was first on the include path list, it would
override the normal path. However, it is a little spooky and it
depends on a GYP change ('early_include_paths' or some such) to set
the ordering. (I couldn't find a good way to do it with the existing
make and SCons builds.)
The above CL uses a macro include:
#include INCLUDE_LIBPNG_PNG_H
In order to support build tools which do header chasing, I also kept
the old include in an #if 0 block.
This is a little more ugly in the source code, but it doesn't hide the
fact that something odd is happening. Here's the current Fedora patch
showing that not too many locations need patching like this:
http://spot.fedorapeople.org/chromium/patches/chromium-20090715-codechanges-system-bz2-xml2-xslt-zlib-minizip-libevent-jpeg-png-nss-nspr-v8.patch
If the above technique is acceptable, I'll do the rest of the common
libraries in the coming weeks. libevent is one exception since we have
local bug fixes there which need to be upstream first. (I sent them
upstream ages ago, but to no reply.)
AGL
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-extensions] Inter-extension communication API proposal
Two suggestions (one I accidentally sent only to James):
chrome.extension.Port:
// ID of the extension at the other side of this port.
String senderID;
Port currently has a 'tab' property if the sender was a tab. Maybe we
should group these:
chrome.extension.Port:
Object sender:
Object tab; // if the sender was a tab
String id; // ID of the sending extension.
chrome.extension:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
// with the onConnectExternal event
Port connectExternal(string ID, [string channelName])
It makes more sense to me to have the API mirror the regular connect event:
chrome.extension.connect(); // connects to my own extension
other = new chrome.Extension('abcef...');
other.connect(); // connects to extension abcdef...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-extensions] Inter-extension communication API proposal
On Thu, Jul 30, 2009 at 10:44 AM, James Robinson jam...@google.com wrote:
On Tue, Jul 28, 2009 at 6:02 PM, Matt Perry mpcompl...@chromium.orgwrote:
Two suggestions (one I accidentally sent only to James):
chrome.extension.Port:
// ID of the extension at the other side of this port.
String senderID;
Port currently has a 'tab' property if the sender was a tab. Maybe we
should group these:
chrome.extension.Port:
Object sender:
Object tab; // if the sender was a tab
String id; // ID of the sending extension.
chrome.extension:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
// with the onConnectExternal event
Port connectExternal(string ID, [string channelName])
It makes more sense to me to have the API mirror the regular connect
event:
chrome.extension.connect(); // connects to my own extension
other = new chrome.Extension('abcef...');
other.connect(); // connects to extension abcdef...
The reason I shied away from this is that the behavior of the statement
new chrome.Extension('abdef...').connect() is very different depending on
if 'abcdef...' is the ID of the extension containing that code or a
different one.
How is it different? Sounds like a bug to me.
It's also not clear from the documentation what an extension should expect
to be able to do with the result of new chrome.Extension('abcdef...').
According to
http://dev.chromium.org/developers/design-documents/extensions/content-scripts
the
available APIs in addition to connect() are the onConnect event, which
another extension should _not_ have access to, and getURL(path), which seems
like it would just return chrome-extension://abcdef.../path. Based on that
I don't see much value in exposing the new chrome.Extension('abcdef...')
syntax for inter-extension interaction.
The value is consistency. extensionObject.connect() is how you open a port
to that extension. It should be the same regardless of who you're talking
to.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gears:// and HTML dialogs
On Thu, Aug 13, 2009 at 3:11 PM, Tim Steele t...@chromium.org wrote: On Thu, Aug 13, 2009 at 2:56 PM, Tim Steele t...@chromium.org wrote: Thanks for the speedy response guys. I got the impression chrome-resource is coupled to the new tab page from stuff like this: hm. make that chrome-internal. Does chrome-resource still exist? chrome-resource replaced chrome-internal. That hack exists only to support people who have bookmarked the old URL. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Defining operator is fine. Other types do this: http://www.google.com/codesearch?as_q=operatorbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunk/srcas_filename=\.has_case=http://www.google.com/codesearch?as_q=operator%3C%3CbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunk/srcas_filename=\.has_case= string16 is a good example. http://www.google.com/codesearch?as_q=operator%3C%3CbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunkas_filename=\.has_case= I say just use iosfwd and add the operator. On Thu, Aug 20, 2009 at 10:10 PM, Jim Roskind j...@chromium.org wrote: Looking at the example you gavehow about: EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds()); Is that really that painful to write? ...and you could get all the microseconds to compare if you wanted to via ...InMicroseconds(). I suspect you don't really want absolute comparisons at the microsecond level, and more likely you'd want something like; EXPECT_LT((kEpected - foo).InMilliseconds(), 20). ...but if you really wanted the example you cited, the first line seems relatively short. Jim On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkus scher...@chromium.orgwrote: I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.orgwrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.org wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [extensions] RFC: NPAPI manifest change
Right now we have this manifest key for plugins: plugins: [ {path:
path/to/file, public: true}
]
This won't work well for cross platform extensions. Here's a simple addition
to address that:
plugins: [
{
platform_paths: [
{winxp: plug_xp.dll}, {winvista: plug_vista.dll}, {linux:
libplug_linux.so}, {osx: libplug_osx.so}
],
public: false,
path: fallback/path/here
}
]
Note: the idea of keeping support for the path key is mostly for backwards
compatibility. If the plugin is loaded on an OS that isn't present in the
platform_paths key, we can fall back to the plugin in path. Obviously
it'll fail to load on the wrong platform (hopefully gracefully).
Question: What platforms will we need to specify for different plugin
versions? Do we need to distinguish between XP/Vista/7?
Any other feedback?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Calling functions in the host process from a webpage
We only expose the extension bindings for pages with URLs of the form chrome-extension://*. See chrome/renderer/render_thread.cc and search for RegisterExtension. The (unfortunately named) v8 extension mechanism is how the bindings get added. On Fri, Oct 23, 2009 at 2:13 PM, Patrick Horn path...@berkeley.edu wrote: Hi, I am writing a new browser (source at http://github.com/danielrh/berkelium/ ) using the RenderViewHost layer of chrome. I want to be able to send messages to the host process, and it looks like the chrome.extensions.sendMessage() API is perfect for this. However, when I do host()-AllowBindings(BindingsPolicy::EXTENSION) (before CreateRenderView, where it is used), no extension object is added to window.chrome. I have also tried with AllowBindings(BindingsPolicy::EXTERNAL_HOST) which would provide an alternative message passing API. However, adding this flag just created an empty javascript object at window.externalHost. Any thoughts? Thanks, Patrick --~--~-~--~~~---~--~~ 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] Heads up: safely ignored regression on Linux Startup perf test
Yeah, I'm sure it's my revert. We're now starting the extension processes in parallel with the UI loop (on the launcher thread), rather than always deferred until the next pass through the UI loop. It probably won't make much difference in practice, so I'm torn on whether to undo that change. On Thu, Nov 19, 2009 at 1:57 PM, Tony Chang t...@chromium.org wrote: For reasons unknown to me, this line jumped back up. It seems it's because of Matt's revert: http://src.chromium.org/viewvc/chrome?view=revrevision=32524 This is a startup test, so it basically times how long it takes for LaunchApp to return. Maybe the methodology here is a bit off? On Wed, Nov 18, 2009 at 6:02 PM, Chase Phillips c...@google.com wrote: t_ref shouldn't move, though, since it was isolated from your change. Tony, I don't think there's a problem with the graph pulling the wrong numbers. I see the same difference between extension_toolstrip50 and extension_toolstrip1 when comparing the linux release hardy's graph values, the .dat file the graph code uses, and the output of the startup test itself. I thought maybe extension_toolstrip50 could be using the reference build on accident, so I verified startup_test.cc runs extension_toolstrip50 on the current build instead of the reference build (it does). Things look fine on Windows (the perf graph is what I'd expect, and running the test locally results in toolstrip50 results greater than toolstrip1). These tests don't run on Mac. We should run the tests on Linux to verify things look sane locally, too. No explanation for the odd results yet. Chase On Wed, Nov 18, 2009 at 3:08 PM, John Abd-El-Malek j...@chromium.orgwrote: I don't have an answer to that. The t_ref line didn't move either. On Wed, Nov 18, 2009 at 11:42 AM, Tony Chang t...@google.com wrote: Why didn't the black line on the linux warm perf bot change? It says that that is the extension_toolstrip50 test, which I would expect to run slower than the extension_toolstrip1 test. Maybe the graph is pulling the wrong numbers? http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warm On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek j...@chromium.orgwrote: Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.comwrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- 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 -- 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
Re: [chromium-dev] Heads up: safely ignored regression on Linux Startup perf test
On Thu, Nov 19, 2009 at 2:14 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 19, 2009 at 1:57 PM, Tony Chang t...@chromium.org wrote: For reasons unknown to me, this line jumped back up. It seems it's because of Matt's revert: http://src.chromium.org/viewvc/chrome?view=revrevision=32524 This is a startup test, so it basically times how long it takes for LaunchApp to return. Maybe the methodology here is a bit off? Yeah, I think New Tab tests are more important, since they measure what the user sees, not when internal APIs are called. In the case of the above change by Matt, New Tab Cold hasn't changed so I think it's fine to ignore the rise. http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150 New Tab hasn't changed because none of those tests load any extensions. Maybe we should add some. On Wed, Nov 18, 2009 at 6:02 PM, Chase Phillips c...@google.com wrote: t_ref shouldn't move, though, since it was isolated from your change. Tony, I don't think there's a problem with the graph pulling the wrong numbers. I see the same difference between extension_toolstrip50 and extension_toolstrip1 when comparing the linux release hardy's graph values, the .dat file the graph code uses, and the output of the startup test itself. I thought maybe extension_toolstrip50 could be using the reference build on accident, so I verified startup_test.cc runs extension_toolstrip50 on the current build instead of the reference build (it does). Things look fine on Windows (the perf graph is what I'd expect, and running the test locally results in toolstrip50 results greater than toolstrip1). These tests don't run on Mac. We should run the tests on Linux to verify things look sane locally, too. No explanation for the odd results yet. Chase On Wed, Nov 18, 2009 at 3:08 PM, John Abd-El-Malek j...@chromium.orgwrote: I don't have an answer to that. The t_ref line didn't move either. On Wed, Nov 18, 2009 at 11:42 AM, Tony Chang t...@google.com wrote: Why didn't the black line on the linux warm perf bot change? It says that that is the extension_toolstrip50 test, which I would expect to run slower than the extension_toolstrip1 test. Maybe the graph is pulling the wrong numbers? http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warm On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek j...@chromium.orgwrote: Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.comwrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- 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 -- 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
Re: [chromium-dev] Heads up: safely ignored regression on Linux Startup perf test
On Thu, Nov 19, 2009 at 2:20 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 19, 2009 at 2:17 PM, Matt Perry mpcompl...@chromium.orgwrote: On Thu, Nov 19, 2009 at 2:14 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Nov 19, 2009 at 1:57 PM, Tony Chang t...@chromium.org wrote: For reasons unknown to me, this line jumped back up. It seems it's because of Matt's revert: http://src.chromium.org/viewvc/chrome?view=revrevision=32524 This is a startup test, so it basically times how long it takes for LaunchApp to return. Maybe the methodology here is a bit off? Yeah, I think New Tab tests are more important, since they measure what the user sees, not when internal APIs are called. In the case of the above change by Matt, New Tab Cold hasn't changed so I think it's fine to ignore the rise. http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150 New Tab hasn't changed because none of those tests load any extensions. Maybe we should add some. good point, thanks for the explanation. I think your change will improve the user-visible response time even if this particular test shows a drop in perf. If I'm reading your change correctly, things have to be faster since the process creation on the launcher thread is kicked off earlier (instead of after a PostTask to the UI thread). Yes, but the point of the PostTask in the first place was to defer extension load - they're not essential processes, so they don't need to slow down startup. If postponing them until after the UI thread settles down improves user perceived startup time, then we should do that. That said, I think I'm going to revert my change. If nothing else, it'll bring the extension startup test time back to normal so we can see regressions better. On Wed, Nov 18, 2009 at 6:02 PM, Chase Phillips c...@google.com wrote: t_ref shouldn't move, though, since it was isolated from your change. Tony, I don't think there's a problem with the graph pulling the wrong numbers. I see the same difference between extension_toolstrip50 and extension_toolstrip1 when comparing the linux release hardy's graph values, the .dat file the graph code uses, and the output of the startup test itself. I thought maybe extension_toolstrip50 could be using the reference build on accident, so I verified startup_test.cc runs extension_toolstrip50 on the current build instead of the reference build (it does). Things look fine on Windows (the perf graph is what I'd expect, and running the test locally results in toolstrip50 results greater than toolstrip1). These tests don't run on Mac. We should run the tests on Linux to verify things look sane locally, too. No explanation for the odd results yet. Chase On Wed, Nov 18, 2009 at 3:08 PM, John Abd-El-Malek j...@chromium.orgwrote: I don't have an answer to that. The t_ref line didn't move either. On Wed, Nov 18, 2009 at 11:42 AM, Tony Chang t...@google.com wrote: Why didn't the black line on the linux warm perf bot change? It says that that is the extension_toolstrip50 test, which I would expect to run slower than the extension_toolstrip1 test. Maybe the graph is pulling the wrong numbers? http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warm On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek j...@chromium.org wrote: Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.comwrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- 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 -- 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
Re: [chromium-dev] Extensions and the Mac
Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
crash. I'll definitely have to figure something out soon.
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):
{
name: My extension,
...
*plugins: [
{ path: content_plugin.dll, public: true },
{ path: extension_plugin.dll }
]*,
...
}
Are you kidding me? How can we get away with not specifying what platform
the extension will run on? (Hint: we can't.)
If we had something like:
plugins: {
mac: ...
win: ...
linux: ...
}
then at least we could warn on the extensions website that a given
extension is only compatible with a certain platform. On a load attempt we
could know that the extension requires a certain native library and fail to
load it with a real user-friendly warning.
And developers could *make* extensions that are cross-platform compatible.
Today?
- We can't tell in advance what platforms an extensions runs on, so we
can't warn the user (either on the extensions site or in the app)
- The developer has no way of creating a cross-platform extension.
This is a *really* bad situation we've created. We need to get a new
syntax out for extensions to fix this, and soon, before world-breaking
becomes prohibitively expensive.
Avi
--
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
Re: [chromium-dev] Process Model Extension API Proposal
Would it be possible to implement the same functionality using an NPAPI plugin? Extensions are allowed to bundle native plugins and interact with them from script. On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis cr...@chromium.org wrote: Hi folks-- I've put together a proposal for a Chromium extensions module that exposes data about the browser's processes. I think this could be useful for things like per-tab CPU/memory utilization graphs, custom task managers, or visualizing which tabs are sharing processes. http://docs.google.com/View?id=dhr988kp_4f76886hc Please let me know what you think. Thanks! Charlie Reis -- 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
Re: [chromium-dev] RFC: Extensions Incognito
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.comwrote: On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=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
Re: [chromium-dev] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth aba...@chromium.org wrote: Have you considered how incognito interacts with extensions that have NPAPI components? It might not be feasible to create a second, isolated instance of those extensions because the NPAPI component has direct access to system calls. Good point, I hadn't considered that. This is similar to Drew's point about a systray API. I wonder if read-only access to localStorage will be confusing to authors. I can imagine extensions doing wonky things if they assume they can write to localStorage. Maybe we should have a separate API for reading information from the non-incognito localStorage? Would localStorage start off empty (and have no persistence) as it does in regular renderers, then? I think read-only access to localStorage is important because extensions currently use it for storing preferences, and ideally they would share settings without the extension explicitly supporting it. Adam On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Message from mpcompl...@chromium.org: Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. Click to open: - Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.google.com -- 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
Re: [chromium-dev] RFC: Extensions Incognito
After the feedback I received, I realized that my original proposal didn't actually meet one of the goals I intended (that existing extensions would work in incognito transparently). I decided to dial it back a bunch and incorporated some other feedback from Erik and Aaron. Here is v2 of the proposal: https://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=en Changes: - No more separate incognito instance of extension pages. - Users have to opt-in to enable an extension in incognito. - Extension developers can mark their extension incognito safe. We might warn the user if he tries to enable an unsafe extension in incognito. - Some API changes to support incognito data. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
