grack.com

UPDATE (Jan 6, 2010): The Chrome team has turned on extensions on Mac in the latest dev channel build. Even better, you can install directly from extension pages without this bookmarklet. Hooray!

We just officially launched our extension on the Chrome extension gallery today and Mac users are having trouble installing the extension. The ‘Install’ button for Chrome extensions is disabled if you are running on a Mac.

You can manually download extensions from the Google download site using a URL like so:

https://clients2.google.com/service/update2/crx?response=redirect&x=id%3Danfibeojfgdfejcfflalkebdfgojfbbm%26uc.

The bolded part of the URL above is the extension’s public ID (a hash of the public key).

Here’s a bookmarklet that’ll re-enable the button and allow you to download the extension. It recreates the download URL from the current page you are viewing:

Enable Extension Install

Try it out on the DotSpots extension page here. Click the bookmarklet and the Install button will be activated.

UPDATE: I removed the lang=en-US part of the URL. Some extensions fail to load with that attribute in place.

Note that you’ll need an extension-supported build. The next developer channel build should support it. If you are too anxious to wait, you can install the latest Chromium build from here: http://build.chromium.org/buildbot/snapshots/chromium-rel-mac/34059/.

Read full post

GWT 2.0 ships with a new HtmlUnit-based testing system that makes testing faster, but isn’t full web-browser under the hood. It can’t perform layout, so any tests that rely on layout measurements won’t succeed.

There are a number of alternate run styles that are useful, however. Manual mode, which outputs a URL that you can connect any browser to, works well for quick testing, but is a pain when you need to keep running it over and over. RemoteWeb and Selenium automate the process of starting and stopping browsers, but require you to start an external server before testing.

There’s another run-style that isn’t well-documented, but I’ve found to be the most useful for testing locally: ExternalBrowser. It requires an executable name in the command-line, the name of the browser to start. On OSX, you can specify the fully-qualified name of the executable beneath the application bundle, or you can use a shell script to launch the browser of your choice.

Place the following script under /usr/bin named safari and make it chmod a+x. This allows you (and ExternalBrowser) to launch Safari from the command-line’s $PATH. The argument to open is the name of any browser that lives under your /Applications/ directory, including subdirectories.

#!/bin/sh
open -W -a Safari $1

Add a Java system property gwt.args to your testing launch configuration in Eclipse, Ant script or other IDE. You can then specify the run style like so:

-Dgwt.args="-runStyle ExternalBrowser:safari"

Now, when you run your unit tests, you’ll see GWT launch Safari and navigate to the appropriate URL on its own. Tests will leave windows up on your screen after they complete, but you can safely close them after the run terminates.

Read full post

I went down to Mountain View last week to show off the company we’ve been building, DotSpots, plug our brand-new Chrome extension and demo some of the great new features of GWT 2.0.

See it directly on YouTube here:

Kudos to the Google team for putting together such a great event. You don’t realize how much planning and preparation goes into an hour-long event like that.

Read full post

I briefly blogged earlier this year about our internal project that allowed us to write Firefox extensions using the Google Web Toolkit framework. I’m happy to say that I’ve just pushed out the first version of the code for developers to start playing with.

Building a Firefox extension isn’t much different than writing a standard GWT web application. There are some caveats: there isn’t a global window ($wnd) or document ($doc) and the GWT widget system doesn’t work without some tweaks. You can, however, take advantage of GWT’s extensive DOM bindings to manipulate pages that the user loads and interact with the Chrome DOM to add toolbar buttons and menu items. I’m slowly working on extracting the code to work with these browser elements from our proprietary codebase, cleaning them up and pushing them into the open-source project.

For now, the current version of gwt-firefox-extension should be sufficient to write an application with the same functionality as a greasemonkey script without dipping into more advanced concepts. We’ve also generated bindings for the whole set of XPCOM IDL, so you’ll have access to most every service and component in the browser if you need to do something more complicated.

Try it out and join our open-source mailing list if you’ve got any feedback or suggestions.

Read full post