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:
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
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
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
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
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
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.
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
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
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
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.
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
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
: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
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
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
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
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
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
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
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},
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
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
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:
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
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
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
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
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
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
30 matches
Mail list logo
