To develop Chrome extensions, crx is the best way. But the user scripts that are developed in general for Greasemonkey can also be delivered for Chrome, if a few easy rules are followed.
1. @required and @resource don't work.
By default, atleast for now, These two Userscript metatags donot work on Chrome. If you need to load a js file, instead of using @required - try to use document.createElement. Similarly with @resource.
2. Some GreaseMonkey helper methods don't work or are restricted.
Methods with GM_ prefix from userscript api may not work. Particularly, unsafeWindow, GM_registerMenuCommand, GM_setValue, or GM_getValue are not supported. GM_xmlhttpRequest will work but not only on the same domain.
3. @includes are not shown while installing.
This may not be a deal breaker for developers, but sure is for users. The patterns used in @include is not shown while installing. Instead a generic message is shown as below. This message may scare the users away.
To over come this, add @match and show the @include pattern there. The message window pics up the domain portion of the pattern.
This actually can be used maliciously. A developer may install a script with a different include pattern and show a different match pattern, there by luring the users to install a malicious script. Although Chrome follows the @include pattern to add script to the page. Just the installation window pops open with @match pattern. Please use this for responsibly.
1. @required and @resource don't work.
By default, atleast for now, These two Userscript metatags donot work on Chrome. If you need to load a js file, instead of using @required - try to use document.createElement. Similarly with @resource.
2. Some GreaseMonkey helper methods don't work or are restricted.
Methods with GM_ prefix from userscript api may not work. Particularly, unsafeWindow, GM_registerMenuCommand, GM_setValue, or GM_getValue are not supported. GM_xmlhttpRequest will work but not only on the same domain.
3. @includes are not shown while installing.
This may not be a deal breaker for developers, but sure is for users. The patterns used in @include is not shown while installing. Instead a generic message is shown as below. This message may scare the users away.
To over come this, add @match and show the @include pattern there. The message window pics up the domain portion of the pattern.
This actually can be used maliciously. A developer may install a script with a different include pattern and show a different match pattern, there by luring the users to install a malicious script. Although Chrome follows the @include pattern to add script to the page. Just the installation window pops open with @match pattern. Please use this for responsibly.
Here is comments from The Chromium source that explains the reasoning, valid/invalid patterns @match can take:
// Examples of valid patterns: // - http://*/* // - http://*/foo* // - https://*.google.com/foo*bar // - file://monkey* // - http://127.0.0.1/* // // Examples of invalid patterns: // - http://* -- path not specified // - http://*foo/bar -- * not allowed as substring of host component // - http://foo.*.bar/baz -- * must be first component // - http:/bar -- scheme separator not found // - foo://* -- invalid scheme // - chrome:// -- we don't support chrome internal URLs // // Design rationale: // * We need to be able to tell users what 'sites' a given URLPattern will // affect. For example "This extension will interact with the site // 'www.google.com'. // * We'd like to be able to convert as many existing Greasemonkey @include // patterns to URLPatterns as possible. Greasemonkey @include patterns are // simple globs, so this won't be perfect. // * Although we would like to support any scheme, it isn't clear what to tell // users about URLPatterns that affect data or javascript URLs, so those are // left out for now.