Chrome Gets Plugins: How to Write a Chrome Extension in Three Easy Steps(mattcutts.com)
mattcutts.com
Chrome Gets Plugins: How to Write a Chrome Extension in Three Easy Steps
http://www.mattcutts.com/blog/write-chrome-extension/
8 comments
The terms plugin, extension, add-on, widget, drop-in, applet, cram-thru, etc. have all historically been used interchangeably to mean little more than "lack of modular design".
Don't expect actual extensibility from Chromium any time soon. If they can't be bothered to even plan for platform independence (http://dev.chromium.org/developers/browser-bootstrapping) then they don't have the design wherewithall to retrofit a C++ app with a comprehensive extension mechanism.
My hope is that a Google-independent fork will start that extracts the nifty subsystems in Chromium, like process level isolation, and uses them to build a more thoughtfully architected browser/platform.
Don't expect actual extensibility from Chromium any time soon. If they can't be bothered to even plan for platform independence (http://dev.chromium.org/developers/browser-bootstrapping) then they don't have the design wherewithall to retrofit a C++ app with a comprehensive extension mechanism.
My hope is that a Google-independent fork will start that extracts the nifty subsystems in Chromium, like process level isolation, and uses them to build a more thoughtfully architected browser/platform.
1) If they had planned for platform independence, they wouldn't have been able to release anything for a long time.
2) Since Chrome relies heavily on process isolation, I would think that a lot of the architecture of the browser is tied to the platform. Even the html rendering pipeline (based on WebKit) runs out-of-band and the rendered bitmap is send to the browser window via IPC. (I don't work on the team but from my understanding of someone's comments, this is how it roughly works)
3) Regarding extensibility, I agree that I doubt Google is going to provide much extensibility of the actual browser chrome. Google's interests are in the web sites themselves and as such, the greasemonkey-like extensions are what they're probably going to promote. They want to hide the browser container as much as possible and move the focus to the web page inside it.
2) Since Chrome relies heavily on process isolation, I would think that a lot of the architecture of the browser is tied to the platform. Even the html rendering pipeline (based on WebKit) runs out-of-band and the rendered bitmap is send to the browser window via IPC. (I don't work on the team but from my understanding of someone's comments, this is how it roughly works)
3) Regarding extensibility, I agree that I doubt Google is going to provide much extensibility of the actual browser chrome. Google's interests are in the web sites themselves and as such, the greasemonkey-like extensions are what they're probably going to promote. They want to hide the browser container as much as possible and move the focus to the web page inside it.
1 & 2) I should hope that a company worth hundreds of millions of dollars and employing a vast army of the greatest programming minds in the world could take the time to wrap their platform specific code in an abstraction layer, a relatively minor task that is now practiced almost universally, or at least use some of the many mature cross-platform libraries available.
3) If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
Firefox Greasemonkey scripts are used by power users to make minor tweaks to specific sites. I don't see how that functionality will further Google's lofty plans for Chrome. This was a quick hack that nominatively fulfilled a very popular feature request.
3) If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
Firefox Greasemonkey scripts are used by power users to make minor tweaks to specific sites. I don't see how that functionality will further Google's lofty plans for Chrome. This was a quick hack that nominatively fulfilled a very popular feature request.
> If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
I'm certainly not the one in charge of directing Google's vision but it would seem to logical to me that they are not interested in creating a new 'platform' in the sense that xul is a platform. As far as I can see, the purpose of Chrome is to promote web apps as a reasonable alternative to desktop apps.
I'm certainly not the one in charge of directing Google's vision but it would seem to logical to me that they are not interested in creating a new 'platform' in the sense that xul is a platform. As far as I can see, the purpose of Chrome is to promote web apps as a reasonable alternative to desktop apps.
If they'd done that, they wouldn't even be in beta yet, let alone out of it. Look at how long Netscape 6, let alone Firefox, took to materialize. Remember that most of the Chrome team are ex-Firefox-luminaries: these are not stupid people, and you probably use their other products all the time.
Still doesn't offer any real extension functionality; it's more a glorified, built-in version of Greasemonkey. This precludes such popular and useful Firefox extensions such as Firebug, Foxmarks, AdBlock, or just about any other extension besides Greasemonkey itself...
A lot of Firefox's bloat comes from the XUL interface. It's their cross-platform GUI which is written in XML and Javascript. It's what allows add-ons to reach in and modify some very deep elements of the browser. For example, I run the Tab Mix Plus extension which radically changes the operation of tabs.
However, XUL and Javascript is a very heavy-weight way of doing things. Chrome and other browsers have a native UI. That is partially what makes Chrome a light-weight browser. It also means that the deep level of cross platform add-on's available for Firefox will not be possible for Chrome in it's current state.
I've read the proposals for expanding Chrome extensions and it sounds like they want to go a similar route to XUL. It probably won't be as low-level because they'll want to keep their native UI code. That will help Chrome to provide some more complex plugins with their own UI but still won't allow for some of the more radical and interesting plugins available for Firefox.
However, XUL and Javascript is a very heavy-weight way of doing things. Chrome and other browsers have a native UI. That is partially what makes Chrome a light-weight browser. It also means that the deep level of cross platform add-on's available for Firefox will not be possible for Chrome in it's current state.
I've read the proposals for expanding Chrome extensions and it sounds like they want to go a similar route to XUL. It probably won't be as low-level because they'll want to keep their native UI code. That will help Chrome to provide some more complex plugins with their own UI but still won't allow for some of the more radical and interesting plugins available for Firefox.
http://www.w3.org/TR/xbl/
Check out the editor of XBL - for those not familiar, XBL is what XUL is built on top of as well as all the widgets you see in the mozilla platform (ff/tb etc), including all your html controls. I think if google went this route, they are definitely picking up where netscape left off and where moz foundation has limped along with, ie. building a platform around the browser.
Check out the editor of XBL - for those not familiar, XBL is what XUL is built on top of as well as all the widgets you see in the mozilla platform (ff/tb etc), including all your html controls. I think if google went this route, they are definitely picking up where netscape left off and where moz foundation has limped along with, ie. building a platform around the browser.
Read the design document on the _real_ extension functionality which is coming soon:
http://dev.chromium.org/developers/design-documents/extensio...
I'd expect announcements in May:
http://code.google.com/events/io/
http://dev.chromium.org/developers/design-documents/extensio...
I'd expect announcements in May:
http://code.google.com/events/io/
I'm not sure that's entirely true.
I can imagine AdBlock, as well as other plugins that deal mainly with the DOM, as entirely possible. I mean, how much does AdBlock really do? Grabs a list of blacklisted URLs (with wildcards), matches applicable elements in the DOM, and removes them.
AdBlock may prevent these requests from being issued at all, but that isn't to say you can't implement something similar in a Greasemonkey-like environment.
I can imagine AdBlock, as well as other plugins that deal mainly with the DOM, as entirely possible. I mean, how much does AdBlock really do? Grabs a list of blacklisted URLs (with wildcards), matches applicable elements in the DOM, and removes them.
AdBlock may prevent these requests from being issued at all, but that isn't to say you can't implement something similar in a Greasemonkey-like environment.
The whole point of AdBlock is that it does block the actualy requests in the first place. Why should I have to download 800k of ads for a 200k webpage, and open myself to adware tracking cookies? Removing them from DOM after they've been downloaded is not a proper solution to me at all...
I disagree. I have an internet plan with 100 gigs of allotted transfer. I don't care if a few kb here and there come down. I understand that your position may be different, but in my opinion most use Adblock the way I do -- to not see advertisements.
Transfer totals has no bearing on bandwidth speed. When I'm on wireless connections, or at work where I am forced to work from a connection shared with 400 other employees, the bandwidth required by ads actually takes up a significant amount of time. I don't even have any caps on my usable bandwidth, in any of the above situations or at home, but the speed can still be greatly affected by the number of ads being loaded that I don't even see. Even my cable internet provider still gives me only a measly 384kilobit upload speed, and that now has to be shared between even more outgoing connections?
To top it all off, from an ad-provider's perspective, why should I be paying for ad impressions that the end user doesn't even get to see? At least with Adblock, my server bandwidth isn't used, and my impression statistics aren't being impacted by users who aren't actually getting the chance to view the content...
To top it all off, from an ad-provider's perspective, why should I be paying for ad impressions that the end user doesn't even get to see? At least with Adblock, my server bandwidth isn't used, and my impression statistics aren't being impacted by users who aren't actually getting the chance to view the content...
I don't think there's anything adblock does that a chromium extension script (or a greasemonkey script) can't do.
You can write a script that just looks for the html fragments that represent ads and nuke them before the page renders, right? - in the same way adblock does
You're assuming that Chrome extensions can do cross-domain XHR... which I'm not sure about.
Yup...you're right. Maybe the URLs or even embedded within the script. An extension update mechanism (if any?) could bring in new versions.
But now I'm way out into conjectureland. Just thinking out loud here.
But now I'm way out into conjectureland. Just thinking out loud here.
In firefox, the only way to do cross domain xhr was to access a javascript object outside of the browser sandbox, make the call, then send the data back. I'd be pretty confident that google chrome's version would have the same security limitations.
Greasemonkey lets you do it - with GM_xmlhttpRequest:
http://diveintogreasemonkey.org/api/gm_xmlhttprequest.html
http://diveintogreasemonkey.org/api/gm_xmlhttprequest.html
The thing is that for browser extensions, I want hooks into the UI (even if fairly limited), not just modification of page content.
Hopefully chrome moves in this direction. I realize that it's a really hard thing to get right, especially in a browser.
Hopefully chrome moves in this direction. I realize that it's a really hard thing to get right, especially in a browser.
Chrome is WebKit, WebKit has an amazing inspector/Firebug clone. In using both, I actually prefer the WebKit inspector. I haven't used Chrome yet, so I'm not sure what magical incantation is required to activate the inspector (in Safari it's part of the "Develop" menu"), but it should be there.
I'm not sure what your point is, but Chrome doesn't use WebKit for JS, it uses Google's internally developed V8 engine, so don't expect JS to always run identically in Safari and Chrome.
Greasemonkey-esque functionality is the main thing I've been missing in Chrome, so this looks appealing.
well the cool thing about greasemonkey was that you could do a little more than just inject javascript code... for example, you could make cross domain xhr calls as well, and it did so by jumping out of the security sandbox to do this. I'm not so sure if it will be possible in chrome...
Fair enough; I've never had call to do that in my own GM scripts, but I can easily see the use.
I can't wait to see how many people pick the unique number 00123456789ABCDEF0123456789ABCDEF0123456
It's never a good idea to put valid UUIDs in tutorials, there's just too many copy-pasters out there.
Having to create an ID manually is temporary.
When complete, the ID is going to be a hash of the extension's public key, and extension content will be signed with the key. So there won't be conflicts (unless you share your private key).
When complete, the ID is going to be a hash of the extension's public key, and extension content will be signed with the key. So there won't be conflicts (unless you share your private key).
Does anyone know how to add a right click menu item so I can invoke a external download tool for URLs?
Anyone switched to the developer-channel version of Chrome yet?
can somebody write a plugin to port Chrome to other OSes?
Note: i'm being sarcastic
Note: i'm being sarcastic
My simplified definition: plugins run native code, extensions run Javascript. Flash if a plugin, Firebug in an extension.