Hacker News Reader

Comment by nuclear_eclipse | Hacker News Reader

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...

View on HN

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.

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.

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/

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.

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...

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.

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

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.

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.

Reply on news.ycombinator.com