Greasemonkey 0.8 candiate -- Let us know what you think

12 views
Skip to first unread message

Aaron Boodman

unread,
Dec 9, 2007, 2:57:46 AM12/9/07
to greasemon...@googlegroups.com, greasemo...@googlegroups.com
Hello everyone,

We're getting close to releasing a new version of Greasemonkey and I'd
like to get your feedback. Here's what new in Greasemonkey 0.8:

* FF3 beta support
* Songbird support (thanks Ian McKellar)
* New cute monkey icons in the status bar and addons panel (thanks to driz).
* Resources (see below for details)

You can download the new release here:
http://youngpup.net/z_dropbox/greasemonkey-0.8.20071208.0.xpi

Please try it out and let us know what works and what doesn't. We are
especially interested in what the script authors think of the APIs.


Resources Details

This is one that people have been asking for for a long time now.
Thanks mainly to Gareth Andrew, you can now include images, css,
javascript files, and any other resource in a Greasemonkey script. So,
for example, you can use the Prototype or MochiKit javascript
libraries with Greasemonkey.

You can see a working example here:
http://www.youngpup.net/userscripts/i-can-has-mochikit.user.js
(obviously only works with Greasemonkey 0.8).

Resources are implemented using two new metadata tags and two new API
functions. Here are the new metadata tags:

@resource <name> <url>
Include the resource <url> when this script is installed and make it
available to the script using the name <name>. So, for example:
@resource google-logo http://www.google.com/intl/en_ALL/images/logo.gif

@require <js-url>
A special form of @resource for including JS libraries. The URL is
included, just like with @resource, but it is automatically added to
the beginning of the script. @require'd libraries are included in the
order they are declared. Here is an example:
@resource mochikit ../shared-libs/MochiKit-1.3-packed.js

Both metadata tags can accept relative or absolute URLs. Relative URLs
are resolved relative to the path of the user script requesting them.

Here are the new API functions:

GM_getResourceURL(resourceName)
Gets a URL for the resource with name <resourceName>. For example, you
could use this to set the src attribute of an image element to a
resource you included.

GM_getResourceText(resourceName)
Gets the textual content of the resource with name <resourceName>.

Note: some popular JS libraries will not work with @require because
they don't work in Greasemonkey's XPCNativeWrapper environment. You
have two choices:

* Fix the script (and ideally submit a patch to the developer)
* Use @resource and GM_getResourceText, like this:

@resource prototype http://www.prototypejs.org/assets/2007/11/6/prototype.js
location.href = "javascript:void(" + GM_getResourceText("prototype") + ")";


Looking forward to hearing your feedback,

- a

esquifit

unread,
Dec 9, 2007, 5:02:47 AM12/9/07
to greasemo...@googlegroups.com
On Dec 9, 2007 8:57 AM, Aaron Boodman <bo...@youngpup.net> wrote:
>
> Hello everyone,
>
> We're getting close to releasing a new version of Greasemonkey and I'd
> like to get your feedback. Here's what new in Greasemonkey 0.8:
>
> * FF3 beta support
> * Songbird support (thanks Ian McKellar)
> * New cute monkey icons in the status bar and addons panel (thanks to driz).
> * Resources (see below for details)

Good! Thank you all who worked hard to achieve this milestone!

> @require <js-url>
> A special form of @resource for including JS libraries. The URL is
> included, just like with @resource, but it is automatically added to
> the beginning of the script. @require'd libraries are included in the
> order they are declared. Here is an example:
> @resource mochikit ../shared-libs/MochiKit-1.3-packed.js

You intended to give us an example of @require, didn't you? ;)

A couple of questions:
1a) Are @required'd libraries downloaded every time a script
@requir'ing them runs?
Or does some caching take place? (either managed by Greasemonkey or
directly by the browser according to the caching directives in the
http header)
I mean, if I open 20 tabs it would not be optimal to download
Prototype 20 times (assuming that in every tab runs at least one
script @requiring Prototype)
1b) Same question with regard to @resources
2) Is it possible to use local libraries (@require file:///...), or is
this also disallowed do to security considerations? Not that
important, anyway.

Aaron Boodman

unread,
Dec 9, 2007, 5:39:33 AM12/9/07
to greasemo...@googlegroups.com
On Dec 9, 2007 2:02 AM, esquifit <esqu...@googlemail.com> wrote:
> > @require <js-url>
> > A special form of @resource for including JS libraries. The URL is
> > included, just like with @resource, but it is automatically added to
> > the beginning of the script. @require'd libraries are included in the
> > order they are declared. Here is an example:
> > @resource mochikit ../shared-libs/MochiKit-1.3-packed.js
>
> You intended to give us an example of @require, didn't you? ;)

Yeah, sorry about the typo. See the example I linked to for a working
script you can try.

> A couple of questions:
> 1a) Are @required'd libraries downloaded every time a script
> @requir'ing them runs?
> Or does some caching take place? (either managed by Greasemonkey or
> directly by the browser according to the caching directives in the
> http header)
> I mean, if I open 20 tabs it would not be optimal to download
> Prototype 20 times (assuming that in every tab runs at least one
> script @requiring Prototype)
> 1b) Same question with regard to @resources

Resources (and required js files) are downloaded once at install time.
This is important for bandwidth and reliability reasons, but also for
security reasons. It shouldn't be possible for a script's dependencies
to change once the user has OK'd the script.

> 2) Is it possible to use local libraries (@require file:///...), or is
> this also disallowed do to security considerations? Not that
> important, anyway.

It's possible to use file:/// resources only when the script you're
installing is also at a file:/// URL. This makes it easy to develop
scripts (using relative paths) from the local disk. Then when you're
ready, you post them to your server and they keep working.


- a

Aaron Boodman

unread,
Dec 9, 2007, 5:41:09 AM12/9/07
to greasemo...@googlegroups.com
On Dec 9, 2007 2:39 AM, Aaron Boodman <bo...@youngpup.net> wrote:
> On Dec 9, 2007 2:02 AM, esquifit <esqu...@googlemail.com> wrote:
> > > @require <js-url>
> > > A special form of @resource for including JS libraries. The URL is
> > > included, just like with @resource, but it is automatically added to
> > > the beginning of the script. @require'd libraries are included in the
> > > order they are declared. Here is an example:
> > > @resource mochikit ../shared-libs/MochiKit-1.3-packed.js
> >
> > You intended to give us an example of @require, didn't you? ;)
>
> Yeah, sorry about the typo. See the example I linked to for a working
> script you can try.

Just to be clear, this should have been:
@require ../shared-libs/MochiKit-1.3-packed.js

I sux.

esquifit

unread,
Dec 9, 2007, 3:36:02 PM12/9/07
to greasemo...@googlegroups.com
On Dec 9, 2007 11:39 AM, Aaron Boodman <bo...@youngpup.net> wrote:
>
> Resources (and required js files) are downloaded once at install time.
> This is important for bandwidth and reliability reasons, but also for
> security reasons. It shouldn't be possible for a script's dependencies
> to change once the user has OK'd the script.

I understand. But this also means that if the library is subsequently
updated, different users will end up with the same script using
different versions of the library. This is, of course, better than
silently updating the library code without the user noticing it.

By the way, by the same reasoning that the script code is displayed
before installation (if the users chooses to), one should somehow make
the user aware that s/he is installing more than the script,
eventually even 3rd party code, or is there some same-origin check for
libraries in place? How can one quickly check if the library code is
safe? Is it stored along with the scripts in the gm_scripts folder?

Anyway I will install 0.8.20071208.0 and test it myself before stating
more questions :)

Aaron Boodman

unread,
Dec 9, 2007, 3:58:26 PM12/9/07
to greasemo...@googlegroups.com
On Dec 9, 2007 12:36 PM, esquifit <esqu...@googlemail.com> wrote:
> On Dec 9, 2007 11:39 AM, Aaron Boodman <bo...@youngpup.net> wrote:
> > Resources (and required js files) are downloaded once at install time.
> > This is important for bandwidth and reliability reasons, but also for
> > security reasons. It shouldn't be possible for a script's dependencies
> > to change once the user has OK'd the script.
>
> I understand. But this also means that if the library is subsequently
> updated, different users will end up with the same script using
> different versions of the library. This is, of course, better than
> silently updating the library code without the user noticing it.

That is OK, the main script is still presumably compatible with the
library in both cases: either the library and script are both under
the developer's control, in which case he updated them both together,
or the library doesn't change (eg the archived/versioned/dated
versions of prototype.js) and so the developer doesn't worry about it.

> By the way, by the same reasoning that the script code is displayed
> before installation (if the users chooses to), one should somehow make
> the user aware that s/he is installing more than the script,
> eventually even 3rd party code, or is there some same-origin check for
> libraries in place? How can one quickly check if the library code is
> safe? Is it stored along with the scripts in the gm_scripts folder?

At first Gareth had some UI in the install dialog that allowed you to
click the names of the included resources to examine them. But I
figured that the same sort of person who will read a script file to
determine if it is safe will be able to understand the @resource lines
and go look at those scripts if he wants to.

Was trying to avoid adding more clutter that most people won't use to
the install dialog. Basically, for most people the install dialog is a
trust decision: the website you are visiting is about to do something
which could be unsafe. Do you trust them? If you do, you should trust
them to not accidentally or purposefully include bad libraries.

- a

corg...@gmail.com

unread,
Dec 9, 2007, 8:19:43 PM12/9/07
to greasemonkey-dev


On Dec 9, 12:39 am, "Aaron Boodman" <bo...@youngpup.net> wrote:
> Resources (and required js files) are downloaded once at install time.
> This is important for bandwidth and reliability reasons, but also for
> security reasons. It shouldn't be possible for a script's dependencies
> to change once the user has OK'd the script.

Is it possible to have a way to update the @require'd files, maybe
prompting the user if there's a new version of a dependency?

Aaron Boodman

unread,
Dec 9, 2007, 8:25:41 PM12/9/07
to greasemo...@googlegroups.com

I think what you really want is a way to update the script and get new
copies of all its dependencies at the same time. I don't think it
makes sense to have a script's dependencies updating underneath it.

Even if you are very very careful and control both sides, this is hard
to do well. Are you going to remember how every version of foo.user.js
worked when you update library.js so that they work well together?

What Greasemonkey is offering here is basically equivalent to "static
linking" in C. It's a simple include system.

Auto-updating scripts is another very important request and should
also be addressed, but I think it should be addressed separately. And
when a script updates, all of it's dependencies will update at the
same time.

- a

BD

unread,
Dec 10, 2007, 1:12:13 AM12/10/07
to greasemo...@googlegroups.com
Even if it wasn't auto-updating, but gave you a message to let you know that an update was available, that would be better than nothing. You would need some way of knowing you gave the message and not do it again, though, which would be possible.

Anthony Lieuallen

unread,
Dec 10, 2007, 12:23:10 PM12/10/07
to greasemo...@googlegroups.com
On 12/10/2007 1:12 AM, BD wrote:
> Even if it wasn't auto-updating, but gave you a message to let you
> know that an update was available, that would be better than nothing.

If that message is appearing automatically, it is still "auto updating".
The critical part is that it (the checking for new versions) happens
automatically without user interaction.

Marti

unread,
Dec 10, 2007, 7:14:54 PM12/10/07
to greasemonkey-dev
On Dec 9, 12:57 am, "Aaron Boodman" <bo...@youngpup.net> wrote:

> Looking forward to hearing your feedback,

Using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/
20071127 Firefox/2.0.0.11

Existing profile with greasemonkey about:config entries reset to
default, then uninstalled, then installed this RC

Onload
-----------------------------
Warning: test for equality (==) mistyped as assignment (=)?
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 248, Column: 32
Source code:
while (result = lines[lnIdx++]) {

FIX: while ((result = lines[lnIdx++])) {

Warning: test for equality (==) mistyped as assignment (=)?
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 260, Column: 34
Source code:
while (result = lines[lnIdx++]) {

FIX: while ((result = lines[lnIdx++])) {


Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 344
Source code:
};

FIX: Make sure all return conditionals return something even if it's
undefined

Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/config.js
Line: 104
Source code:
}

FIX: Make sure all return conditionals return something even if it's
undefined


Right click Greasemonkey status bar icon
-----------------------------------------
Warning: assignment to undeclared variable s
Source file: chrome://greasemonkey/content/convert2RegExp.js
Line: 6

FIX: Declare the variable e.g. var s; somewhere in scope

Warning: assignment to undeclared variable res
Source file: chrome://greasemonkey/content/convert2RegExp.js
Line: 7

FIX: Declare the variable e.g. var res; somewhere in scope


Manage User Scripts via monkey menu icon in status bar
--------------------------------------------------------------------
Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/manage.js
Line: 224, Column: 2
Source code:
},

FIX: Make sure all return conditionals return something even if it's
undefined


Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/manage.js
Line: 264, Column: 18
Source code:
return false;

FIX: Make sure all return conditionals return something even if it's
undefined


Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/manage.js
Line: 266, Column: 18
Source code:
return false;

FIX: Make sure all return conditionals, return something even if it's
undefined


Warning: anonymous function does not always return a value
Source file: chrome://greasemonkey/content/manage.js
Line: 277, Column: 15
Source code:
return true;

FIX: Make sure all return conditionals return something even if it's
undefined


After deleting two scripts (including associated preferences) tried to
reorder list via mouse and got this
--------------------------------------------------------------------------------------------------------------
Error: Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIDOMXULElement.removeChild]
Source file: chrome://greasemonkey/content/manage.js
Line: 176

Didn't do it, but decided to test it again... and it did do it, just
didn't show in previous window and threw the error.


While some of these may seem trivial, they DO affect the speed at
which the extension runs... Firefox is still creating the warning
messages from the JavaScript interpreter, regardless if they are
shown, and thus slowing overall execution, and opening more
possibilities for memory leaks.

In a while I will test out the new API functions/metadata and report
back in.

Thankx for your time and I LOVE the new monkey... a lot less pixely
than the prior one in the Add-ons (extensions) manager.

- Marti -

Marti

unread,
Dec 10, 2007, 11:40:47 PM12/10/07
to greasemonkey-dev
Just a note... I'm not done testing 0.8.0 yet, but I have created the
API reference articles for two of the functions based off what's here
in replies, and also from examining the source. It's not complete,
and not linked into the main API reference wiki link, but it will be
available for editing.

I am probably going to redo the metadata block article to be able to
link to direct items as well... but it does take quite a bit of time
to do that and confirm with the source code.

Anywho... here's the direct links... currently it's the only way to
access them unless you view recent changes... when 0.8 is officially
released it should be relatively simple to link them in. 8D

http://wiki.greasespot.net/GM_getResourceText
http://wiki.greasespot.net/GM_getResourceURL

Thomas Pifer

unread,
Dec 11, 2007, 12:04:49 AM12/11/07
to greasemonkey-dev
I accidentally created a new topic in this group about a week ago with
the subject "Hm" on the new build (0.7.20071118.0), meaning to reply
to the topic already started on that build (This being the first time
ever using Google Groups). In it I mentioned how after installing the
new build, the memory in Firefox 3 Beta 1 (running in Ubuntu Gutsy)
jumped from an average of 70 MB to a whopping 170+ MB. I am now happy
to say that it is averaging at a steady 95 MB, but it still seems
rather excessive for this extension to be using up this much extra
baggage. Is anyone else having this problem, and if so, is this just
the result of a new release candidate?

Other than this, it is working flawlessly as ever and I can't wait for
the final 0.8 version to be released.

Marti

unread,
Dec 11, 2007, 3:23:54 AM12/11/07
to greasemonkey-dev
There are a few memory leaks that I can detect, and eventually they
will get addressed... however the excessive part may be in part due to
additional factors. Linux, by default, likes to cache EVERYTHING...
the motto I have hit walls with is "Free memory is wasted memory"... I
do like caching but not at the expense that the operating system may
never release the memory until one reboots. (another wall I've hit
multiple times). Also FF also has it's own cache, there is an
extension at https://addons.mozilla.org/en-US/firefox/addon/1881
called Cache Status that I use to free up FF's cache automatically
(however it's not FF3 compatible yet)... Thirdly, JavaScript trash
collection is still NOT PERFECT (and I'll probably get contradicted on
this)... so there are leaks in JavaScript. User scripts especially
can have artifacts laying around when a tab is close for example
because cleanup never occurred. So... don't know if any of this info
helps, but that's what I've observed and confirmed.

- M -

Marti

unread,
Dec 11, 2007, 7:13:15 PM12/11/07
to greasemonkey-dev
On Dec 9, 2:57 am, "Aaron Boodman" <bo...@youngpup.net> wrote:

> Looking forward to hearing your feedback,
>
> - a

When using:
@require file:///home/user/foo.js
@require foo.js

separately in a test script... script failed on installation and threw
an error

Error: downloadNext is not defined
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 166

FIX: This is a guess here because I haven't examined the entire code
routine yet... should it be this.downloadNextDependency(); instead of
downloadNext();

Marti

unread,
Dec 11, 2007, 7:26:43 PM12/11/07
to greasemonkey-dev
On Dec 9, 2:57 am, "Aaron Boodman" <bo...@youngpup.net> wrote:

> Looking forward to hearing your feedback,

> - a

When using:
@resource test_name file:///home/user/foo.png
@resource test_name foo.png

separately in a test script... script failed on installation and threw
an error (and yes target existed... alerts the user if the target
doesn't exist and soft fails installation)

Error: downloadNext is not defined
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 166

FIX: This is a guess here because I haven't examined the entire code
routine yet... should it be this.downloadNextDependency(); instead of
downloadNext(); Same as previoius bug report btw.

Marti

unread,
Dec 11, 2007, 7:33:36 PM12/11/07
to greasemonkey-dev
On Dec 9, 2:57 am, "Aaron Boodman" <bo...@youngpup.net> wrote:

> Looking forward to hearing your feedback,
> - a

This is actually an old bug that I see A LOT of and fix locally every
release that GM has.

Warning: function requires argument
Source file: chrome://greasemonkey/content/xmlhttprequester.js
Line: 76

CURRENT: req.send(details.data);
FIX: req.send( (details.data) ? details.data : null);

Marti

unread,
Dec 12, 2007, 12:13:54 AM12/12/07
to greasemonkey-dev
Aaron Boodman wrote:

> Looking forward to hearing your feedback,
>
> - a

Okay... you asked for it ;D *GRIN*

---------------
Warning: assignment to undeclared variable scriptScheme
Source file: chrome://greasemonkey/content/scriptdownloader.js
Line: 181

CURRENT: scriptScheme = ioService.extractScheme(this.uri_.spec);
FIX: var scriptScheme = ioService.extractScheme(this.uri_.spec);

----------------------------------------
THIS RELASE CANDIDATE IS MISSING
A TON OF LOCALE TRANSLATIONS

Where'd they go?
----------------------------------------

BIG ANNOYANCE
---------------
Typically when installing a user script from anywhere, including
u.s.o... if the author ADDS NEW @resource and @require metablock keys,
it won't retrieve the new resources.

---------------
install.rdf doesn't have FF3 localizations for Description

CURRENT:
<em:name>Greasemonkey</em:name>
...
<em:description>A User Script Manager for Firefox</em:description>

FIX (REPLACE WITH):
<em:localized>
<Description>
<em:locale>en-US</em:locale>
<em:name>Greasemonkey</em:name>
<em:description>A User Script Manager for Firefox</em:description>
</Description>
</em:localized>
<em:localized>
<Description>
<em:locale>fi-FI</em:locale>
<em:name>Greasemonkey</em:name>
<em:description>Replace the translated description from above in
here</em:description>
</Description>
</em:localized>

etc... Reference: http://developer.mozilla.org/en/docs/Localizing_extension_descriptions

---------------
OLD BUG Installation dialog occasionally automatically shows view
source instead of installation dialog when dropping a user script onto
FF. Hard to track down the cause at this time. Occasionally this will
kill FF

-------------
MINOR STUFF HERE
-------------

Empty Mochikit folder present under contents... is this some short of
shortcut for developers that use mochikit?

Icons folder still there, not sure if needed but might be there for
older browser compatibility?!?

Graphics aren't in recommended folder, skin/classic/1.0, but this is
usually at the authors discretion... depends on if one wants to be
compatible with other themes and add-ons that fill missing icons.

Marti

unread,
Dec 12, 2007, 12:27:01 AM12/12/07
to greasemonkey-dev
Aaron Boodman wrote:

> Looking forward to hearing your feedback,
>
> - a

After I fixed the warnings and one of the errors all in all it seems
GREAT!!! I'll be able to move the documention at the GM wiki to beta
probably tomorrow.

Things not done:
* Tracked down the error I got when deleted two scripts and reordered.
* Filled in the other locale translations... not very fluent in any
other language so this probably won't happen.
* Scrubbed the code with my eyes line by line... but maybe I'll save
that for a branch in the future ;D
* Memory consumption tests with leak detection. (see previous point)

Just need to fill in the missing holes in the code and with some other
feedback from developers and how it runs on windoze (haven't tested
that either... don't have one built at the moment)

Thanks for the added capabilities!!

- Marti -

Marti

unread,
Dec 12, 2007, 1:23:40 AM12/12/07
to greasemonkey-dev
On Dec 9, 12:57 am, "Aaron Boodman" <bo...@youngpup.net> wrote:
> You can see a working example here:http://www.youngpup.net/userscripts/i-can-has-mochikit.user.js

Btw when I use this script above, without mochikit, I load google... I
get a few dozen warnings like below

Warning: reference to undefined property _701.pulses
Source file: file:///home/user/.mozilla/firefox/MyNewRandomSeededFolder/components/greasemonkey.js
Line: 7105

WHAT IS THIS?!?!?! There is no line 7105 in that file... is this part
of MochiKit or is it Google screwing with my profile?

Marti

unread,
Dec 12, 2007, 1:30:38 AM12/12/07
to greasemonkey-dev
> WHAT IS THIS?!?!?! There is no line 7105 in that file... is this part
> of MochiKit or is it Google screwing with my profile?

Never mind it's the MochiKit... I'm a little worried that it exposed
my profile directory there.

Marti

unread,
Dec 12, 2007, 2:26:35 AM12/12/07
to greasemonkey-dev
Aaron Boodman wrote:

> Looking forward to hearing your feedback,
>
> - a

I do have a security concern regarding the @require...

If a user script was crafted carefully to have an external source via
the @require, and someone installed this crafted script on their
machine, say from u.s.o... let's theorize that the external script had
a cookie observer, and when it detected someones php session id, it
could potentially send that to another server using XHR... I'm not
real thrilled with this idea, but it is a possibility.

I know this feature is designed for the betterment of scripting but
potential for abuse is present. It does merit some discussion, and how
to word this warning in the documentation.

Any response from anyone?

Johan Sundström

unread,
Dec 12, 2007, 2:55:10 AM12/12/07
to greasemo...@googlegroups.com
On Dec 12, 2007 8:26 AM, Marti <thal...@hotmail.com> wrote:
> I do have a security concern regarding the @require...
>
> If a user script was crafted carefully to have an external source via
> the @require, and someone installed this crafted script on their
> machine, say from u.s.o... let's theorize that the external script had
> a cookie observer, and when it detected someones php session id,

Just echoing to make sure I follow your line of thought -- the exteral
host has a session with the user, of some sort, somehow identifying
him/her by session cookie.

> it could potentially send that to another server using XHR... I'm not
> real thrilled with this idea, but it is a possibility.

and when the script being installed from us.o (assuming us.o does not
rewrite scripts to re-host all their needed components on-site, which
I think will be a likelier development, in the particular case us.o),
the external host replaces the contents of the @require:d resource
with something custom tailored to the user session -- worst case,
malicious.

> I know this feature is designed for the betterment of scripting but
> potential for abuse is present. It does merit some discussion, and how
> to word this warning in the documentation.
>
> Any response from anyone?

I still think this maps back to the basic premises Aaron et al have
already suggested -- installing user scripts is about trusting the
script author to know what (s)he does and to be benign, and should
that assumption not hold, users are cooked, whether the potential
malicious code comes in a @resource or the script body itself.

--
/ Johan Sundström, http://ecmanaut.blogspot.com/

Marti

unread,
Dec 12, 2007, 4:16:22 AM12/12/07
to greasemonkey-dev
Correction here in my bug tracker:

FIX (REPLACE WITH):
<em:localized>

Should be
FIX (ADD TO RDF):
<em:localized>

Just tried it out without the 2.X style and there was no
description... but it's still missing the 3.X localization style.

Marti

unread,
Dec 12, 2007, 4:23:08 AM12/12/07
to greasemonkey-dev
Johan Sundström wrote:
> Just echoing to make sure I follow your line of thought -- the exteral
> host has a session with the user, of some sort, somehow identifying
> him/her by session cookie.

Every site on the internet does this.

> > it could potentially send that to another server using XHR... I'm not
> > real thrilled with this idea, but it is a possibility.
>
> and when the script being installed from us.o (assuming us.o does not
> rewrite scripts to re-host all their needed components on-site, which
> I think will be a likelier development, in the particular case us.o),
> the external host replaces the contents of the @require:d resource
> with something custom tailored to the user session -- worst case,
> malicious.

This is actually a branch that I hadn't thought of... that's pretty
nasty too. But the branch I'm talking about is the external script
sets up an event listener to monitor cookies, then mirrors them to
another server via XHR, and of course PHP/ASP is quite good at
automating things... so a session can be mirrored based off the cookie
values... almost all site don't do continual monitoring of ip changes.
One site I'm on takes about 12 minutes to detect that the ip is
different... a lot of damage can be done in that time. Most sites
require the old password to be entered before the new one is set, but
not everyones up to par yet.

> > I know this feature is designed for the betterment of scripting but
> > potential for abuse is present. It does merit some discussion, and how
> > to word this warning in the documentation.
> >
> > Any response from anyone?
>
> I still think this maps back to the basic premises Aaron et al have
> already suggested -- installing user scripts is about trusting the
> script author to know what (s)he does and to be benign, and should
> that assumption not hold, users are cooked, whether the potential
> malicious code comes in a @resource or the script body itself.
>
> --
> / Johan Sundstr�m, http://ecmanaut.blogspot.com/

Well thank you for your input... i'm a coder and know how useful this
metadata key can be, but I have also experienced the flip side as
well, by identity theft.

Johan Sundström

unread,
Dec 12, 2007, 2:54:12 PM12/12/07
to greasemo...@googlegroups.com
On Dec 12, 2007 10:23 AM, Marti <thal...@hotmail.com> wrote:
> > > it could potentially send that to another server using XHR... I'm not
> > > real thrilled with this idea, but it is a possibility.
> >
> > and when the script being installed from us.o (assuming us.o does not
> > rewrite scripts to re-host all their needed components on-site, which
> > I think will be a likelier development, in the particular case us.o),
> > the external host replaces the contents of the @require:d resource
> > with something custom tailored to the user session -- worst case,
> > malicious.
>
> This is actually a branch that I hadn't thought of... that's pretty
> nasty too. But the branch I'm talking about is the external script
> sets up an event listener to monitor cookies, then mirrors them to
> another server via XHR,

Is your point that malicious code (phoning home session cookies,
performing bank transactions or whatnot) could be hidden in the script
part that is being included via @require / @resource provisions, and
that they would not show up in the new scheme when viewing script
source code prior to installation?

If so, it was already covered in Aaron's second-to-last post earlier
in this thread -- to reiterate the reasoning:

"At first Gareth had some UI in the install dialog that allowed you to
click the names of the included resources to examine them. But I
figured that the same sort of person who will read a script file to
determine if it is safe will be able to understand the @resource lines
and go look at those scripts if he wants to.

Was trying to avoid adding more clutter that most people won't use to
the install dialog. Basically, for most people the install dialog is a
trust decision: the website you are visiting is about to do something
which could be unsafe. Do you trust them? If you do, you should trust
them to not accidentally or purposefully include bad libraries."

(The term "bad libraries" includes malicious code doing identity theft.)

I'm not arguing against your opinion here, just trying to home it into
the part of the thread where it would be most constructive. If you
disagree with the reasoning above, how would you prefer the
installation dialog be instrumented instead to cover up the issue of
malicious code? I personally consider it a mostly unresolvable
(technically) social issue, just like how extensions encoutered in the
wild could harbour malicious code.

--
/ Johan Sundström, http://ecmanaut.blogspot.com/

> and of course PHP/ASP is quite good at automating things...

Aaron Boodman

unread,
Dec 12, 2007, 3:12:29 PM12/12/07
to greasemo...@googlegroups.com
Marti,

I'm having trouble keeping up with your many (very helpful and
appreciated) bug reports. I've given you SVN write access on
greasemonkey.devjavu.com with the email address thal...@hotmail.com.
Go create an account with that email address and you should be able to
make changes to SVN.

Can you setup a branch (eg /branches/marti1) with all these changes in
it? Then it will be easier for us to review all at once and merge in.

Thanks very much for your help,

- a

Marti

unread,
Dec 12, 2007, 4:44:00 PM12/12/07
to greasemonkey-dev
Johan Sundström wrote:
> Is your point that malicious code (phoning home session cookies,
> performing bank transactions or whatnot) could be hidden in the script
> part that is being included via @require / @resource provisions, and
> that they would not show up in the new scheme when viewing script
> source code prior to installation?
>
> If so, it was already covered in Aaron's second-to-last post earlier
> in this thread -- to reiterate the reasoning:

I understand that it was covered... I'm not trying to get the
interface (GUI) changed, although would be nice to have some sort of
marker to the end user that externals will be applied... Most of the
users that I have install scripts from, aren't at any of our levels. I
spend hours trying to explain stuff to them in private communications
about what GM is, and how to utilize any script I make and how NOT TO
BLANKET TRUST anyone, including myself. But not everyone is a
programmer. The simplest script I use is Likifier, and that has
caused confusion in my network. I'm doing my best to document
Greasemonkey at the wiki for all types... I haven't even gotten into
the non-API pages yet... but it seems to be a fantastic tool for
showing everything that I normally have to type out over and over and
over to my network of contacts on the internet. I also LOVE GM very
much as it cleans up the mess that some sites have... but I've also
been spoofed before by a meta tag refresh that encapsulated my session
in an iframe, then because FF can do XSS, they nabbed my cookies and
mirrored my session. I've since then disabled the meta refresh tag
via RefreshBlocker and of course I've tightened up my security almost
to the point that it's difficult to do anything.

But back to my spoof example... a cookie observer watches for cookie
changes... it doesn't matter that GM is in the "sandbox"... cross site
cookie "borrowing" is possible in Mozilla products (and even IE
too)... so a SINGLE script could borrow the cookies, and mirror a
session elsewhere for a period of time. Having EXTERNAL scripts
complicates things further... and yes I always tell my contacts to
REVIEW everything... but if they don't have the necessary background
in programming they are going to get confused. My one and only public
script that I've published, I needed translations... that was an
undertaking to say the least... not everyone of my contacts speaks
English well, so that was actually a chore for me to get them to
translate my messages correctly (cross ref'd with babelfish and some
knowledge that I have about other languages). Even at my current
skill level, I freaked earlier when the MochiKit script for pulsate
made my error console go crazy... call it being overcautious... I
calmed down and discovered the root of it rather quickly... but had
mochikit been "evil" I would have been compromised for a short period
of time. I'm still getting used to the new api methods and metadata
block keys, which is why the documentation has been changing daily.
I'm doing my best to understand these and the documentation is
critical for new users (and even old users).

Anyhow... I'll ponder over this entire thread again and again like
I've done several times (I usually reread everything a few dozen times
to gain further insight).

Marti

unread,
Dec 12, 2007, 4:53:39 PM12/12/07
to greasemonkey-dev
Aaron Boodman wrote:
> Marti,
>
> I'm having trouble keeping up with your many (very helpful and
> appreciated) bug reports. I've given you SVN write access on
> greasemonkey.devjavu.com with the email address thal...@hotmail.com.
> Go create an account with that email address and you should be able to
> make changes to SVN.
>
> Can you setup a branch (eg /branches/marti1) with all these changes in
> it? Then it will be easier for us to review all at once and merge in.
>
> Thanks very much for your help,
>
> - a

I have to do some reading on SVN in the next day or two... I basically
know how to checkout the source and that's about it... I have SVN
installed by default under Mandriva Linux, but I want to be sure I
don't have any "accidents"... So I'll have to read the recommended
reading for SVN to understand it completely, fully, and absolutely.

You are quite welcome, I appreciate the helpful nature of everyone
here. 8D

Anthony Lieuallen

unread,
Dec 12, 2007, 5:04:06 PM12/12/07
to greasemo...@googlegroups.com
On 12/12/2007 1:23 AM, Marti wrote:
> Warning: reference to undefined property _701.pulses
> Source file: file:///home/user/.mozilla/firefox/MyNewRandomSeededFolder/components/greasemonkey.js
> Line: 7105
>
> WHAT IS THIS?!?!?! There is no line 7105 in that file...

This is probably a new bug, caused by the way @require works.

There's some tricky logic in GM, to attempt to work around a bug in
Mozilla, about how it reports which line an error is on when eval() is used.

Now that @require is putting extra lines of text in front of the script,
the line numbers will seem wonky, as they could easily be greater than
the number of lines in multiple files (if the user reading the message
even realizes there are multiple files involved!).

Moreover, reporting which file the error really came from will be
further complicated. I need to take a look at how this code really
works, and then I can make some suggestions.

Marti

unread,
Dec 13, 2007, 1:48:01 AM12/13/07
to greasemonkey-dev
Aaron Boodman wrote:
> Marti,
>
> I'm having trouble keeping up with your many (very helpful and
> appreciated) bug reports. I've given you SVN write access on
> greasemonkey.devjavu.com with the email address thala...@hotmail.com.
> Go create an account with that email address and you should be able to
> make changes to SVN.
>
> Can you setup a branch (eg /branches/marti1) with all these changes in
> it? Then it will be easier for us to review all at once and merge in.
>
> Thanks very much for your help,
>
> - a

Hrmm anyone awake that can help me with this... signed up at
http://www.devjavu.com, got the email confirmation, confirmed, logged
in there.... but in svn I get the message of:

svn: Commit failed (details follow):
svn: MKACTIVITY of '/greasemonkey/!svn/act/SomeReallyLongHash': 403
Forbidden (http://svn.devjavu.com)

All my local changes are in branches/mm/* as confirmed with svn
status... and i did have to specify the --username myemailhere when
attempting to commit. Did specify the -m note switch too. Do I need to
specify a port too?

H
E
L
P L E A S E

- Marti -

Marti

unread,
Dec 13, 2007, 5:50:26 PM12/13/07
to greasemonkey-dev
On Dec 12, 1:12 pm, "Aaron Boodman" <bo...@youngpup.net> wrote:
> Marti,
>
> I'm having trouble keeping up with your many (very helpful and
> appreciated) bug reports. I've given you SVN write access on
> greasemonkey.devjavu.com with the email address thala...@hotmail.com.
> Go create an account with that email address and you should be able to
> make changes to SVN.
>
> Can you setup a branch (eg /branches/marti1) with all these changes in
> it? Then it will be easier for us to review all at once and merge in.
>
> Thanks very much for your help,
>
> - a

Still no luck... tried everything that was suggested from a search
engine search too... I'm assuming that my privi's aren't set
correctly.

S
T
I
L
L

Anthony Lieuallen

unread,
Dec 13, 2007, 5:51:44 PM12/13/07
to greasemo...@googlegroups.com
On 12/13/2007 5:50 PM, Marti wrote:
>> Can you setup a branch (eg /branches/marti1)
> Still no luck... I'm assuming that my privi's aren't set correctly.

Can you please show exactly what commands you're running, and what their
output is?

Marti

unread,
Dec 13, 2007, 6:02:20 PM12/13/07
to greasemonkey-dev
1) $svn commit -m "Here's the changes"

Didn't like this one because it chose my local username over my email
addy so I had to specify it on the command line

2) $svn commit --username thal...@hotmail.com -m "Here's the changes"
Didn't like this one

3) $svn commit --no-auth-cache --username thal...@hotmail.com -m
"Here's the changes"
Thought I'd make sure the password cache was clear... but didn't like
this one either

4) $svn commit --no-auth-cache --username=thal...@hotmail.com -m
"Here's the changes"
Tried an equals... no luck

All of them returned this in some form... the hash or class value kept
changing... guessing it's a date/time hash

svn: Commit failed (details follow):
svn: MKACTIVITY of '/greasemonkey/!svn/act/529fc440-b9f1-46ee-88a7-
dae82d7f303a': 403 Forbidden (http://svn.devjavu.com)

I can log in to www.devjavu.com just fine with my user/pass.

Marti

unread,
Dec 13, 2007, 6:03:28 PM12/13/07
to greasemonkey-dev
On Dec 13, 3:51 pm, Anthony Lieuallen <arant...@gmail.com> wrote:
P.S. I'm using Subversion command-line client, version 1.4.5.

Johan Sundström

unread,
Dec 13, 2007, 6:18:18 PM12/13/07
to greasemo...@googlegroups.com
On Dec 13, 2007 11:50 PM, Marti <thal...@hotmail.com> wrote:
> On Dec 12, 1:12 pm, "Aaron Boodman" <bo...@youngpup.net> wrote:
> > Marti,
> >
> > I'm having trouble keeping up with your many (very helpful and
> > appreciated) bug reports. I've given you SVN write access on
> > greasemonkey.devjavu.com with the email address thala...@hotmail.com.
> > Go create an account with that email address and you should be able to
> > make changes to SVN.
> >
> > Can you setup a branch (eg /branches/marti1) with all these changes in
> > it? Then it will be easier for us to review all at once and merge in.
> >
> > Thanks very much for your help,
>
> Still no luck... tried everything that was suggested from a search
> engine search too... I'm assuming that my privi's aren't set
> correctly.

Chances are this (see comments) might be helpful:

http://blog.devjavu.com/2007/04/04/free-ssl-for-beta-users/#comment-909

If not, you're probably going to have to state what commands you try
to invoke (assuming you run command line svn), and their output, or
it'll be hard for us to help you get it right.

Marti

unread,
Dec 13, 2007, 6:36:37 PM12/13/07
to greasemonkey-dev
On Dec 13, 4:18 pm, "Johan Sundström" <oyas...@gmail.com> wrote:
See previous two replies for exact syntax, and what I'm using.

Tried again today:
$svn switch --relocate http://svn.devjavu.com/greasemonkey
https://svn.devjavu.com/greasemonkey

Tried again today initializing it all over again using
$svn checkout https://svn.devjavu.com/greasemonkey

$svn mkdir branches/mm1
$svn status
A mm1

retried my commit, got...

svn: Commit failed (details follow):
svn: MKACTIVITY of '/greasemonkey/!svn/act/601c6bd3-3b73-40a1-be1a-
a8f0f93688cc': 403 Forbidden (https://svn.devjavu.com)

Like I said I've tried a bunch here... even read an article stating
the "greasemonkey" in the URI may be case sensitive... but I'm not
going to guess.

Thanks for the suggestions... any more?

Marti

unread,
Dec 13, 2007, 6:46:12 PM12/13/07
to greasemonkey-dev
> A mm1

LOL now it shows
A branches/mm1

still not committing

Nikolas Coukouma

unread,
Dec 13, 2007, 6:55:51 PM12/13/07
to greasemo...@googlegroups.com
Marti wrote:
> See previous two replies for exact syntax, and what I'm using.
>
> Tried again today:
> $svn switch --relocate http://svn.devjavu.com/greasemonkey
> https://svn.devjavu.com/greasemonkey
>
> Tried again today initializing it all over again using
> $svn checkout https://svn.devjavu.com/greasemonkey
>
> $svn mkdir branches/mm1
> $svn status
> A mm1
>
> retried my commit, got...
>
> svn: Commit failed (details follow):
> svn: MKACTIVITY of '/greasemonkey/!svn/act/601c6bd3-3b73-40a1-be1a-
> a8f0f93688cc': 403 Forbidden (https://svn.devjavu.com)
>

The following worked fine for me. I assume you have Subversion 1.4.x,
but you can check with svn --version (see below). I strongly suspect
that the permissions aren't set correctly ... at least you can now check
out a revision with your branch and start making some changes; hopefully
this will be sorted out soon, but if not I recommend saving patches
(from svn diff) or even using a git repo to stash changes (probably not
worthwhile if you don't already know git).

branches$ svn cp ../trunk/ mm1
branches$ svn ci --no-auth-cache --username at...@atrus.org -m "Created
branch for marti"
Authentication realm: <http://svn.devjavu.com:80> DevjaVu
Password for 'at...@atrus.org':
Adding mm1

Committed revision 505.
branches$ svn --version
svn, version 1.4.4 (r25188)
compiled Jun 7 2007, 20:42:05

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme

(Note: 1.4.5 is a win32 security fix release)
Good luck,
-Nikolas

signature.asc

Marti

unread,
Dec 13, 2007, 7:16:52 PM12/13/07
to greasemonkey-dev
On Dec 13, 4:55 pm, Nikolas Coukouma <at...@atrus.org> wrote:
> $ svn --version
> svn, version 1.4.4 (r25188)
> compiled Jun 7 2007, 20:42:05
>
> Copyright (C) 2000-2006 CollabNet.
> Subversion is open source software, seehttp://subversion.tigris.org/
> This product includes software developed by CollabNet
> (http://www.Collab.Net/).
>
> The following repository access (RA) modules are available:
>
> * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
> - handles 'http' scheme
> - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
>
> (Note: 1.4.5 is a win32 security fix release)
> Good luck,
> -Nikolas
AHHHH I was lookin' for that command... wasn't in the available sub-
commands of the man page... but higher up in the man page it was
buried... THANKS!!!!! 8D and Thank you for creating the branch... I
suspect it's a perm's issue too... but at least I can copy from my old
checkout into the new one eventually.

$svn --version
svn, version 1.4.5 (r25188)
compiled Oct 3 2007, 04:04:57

Anthony Lieuallen

unread,
Dec 14, 2007, 9:56:04 AM12/14/07
to greasemo...@googlegroups.com
On 12/13/2007 6:02 PM, Marti wrote:
>> Can you please show exactly what commands you're running, and what
>> their output is?
> svn: Commit failed (details follow):
> svn: MKACTIVITY of '/greasemonkey/!svn/act/529fc440-b9f1-46ee-88a7-
> dae82d7f303a': 403 Forbidden (http://svn.devjavu.com)

This is either a problem with username/password, or privileges of said user.

Marti

unread,
Dec 14, 2007, 4:17:08 PM12/14/07
to greasemonkey-dev
Aaron Boodman wrote:
> Marti,

> I'm having trouble keeping up with your many (very helpful and
> appreciated) bug reports. I've given you SVN write access on
> greasemonkey.devjavu.com with the email address thal...@hotmail.com.
> Go create an account with that email address and you should be able to
> make changes to SVN.
...
> Thanks very much for your help,

> - a

Anthony Lieuallen wrote:
> On 12/13/2007 6:02 PM, Marti wrote:
> >> Can you please show exactly what commands you're running, and what
> >> their output is?

> > $svn commit --no-auth-cache --username=thal...@hotmail.com -m "Here's the changes"
> >
> > svn: Commit failed (details follow):
> > svn: MKACTIVITY of '/greasemonkey/!svn/act/529fc440-b9f1-46ee-88a7-
> > dae82d7f303a': 403 Forbidden (http://svn.devjavu.com)
>
> This is either a problem with username/password, or privileges of said user.

I'm guessing that if it's hosted on a Linux server, that I am not a
member of the SVN Commit group. I've actually never heard of
"reservations" on Linux before, so not really sure what Aaron did to
let the system know that I was going to be signing up at http://www.devjavu.com.
That's another thing I have to look up to see if SVN server has that
ability... core Linux/BSD Apache doesn't, and neither does M$ Windows
IIS.

I've got some suggestions that you all may like, and I know it's going
to take some time to review... but it would be handy to get the ball
rolling.

- Marti -

Marti

unread,
Dec 14, 2007, 4:49:40 PM12/14/07
to greasemonkey-dev
Looks like the @ symbol is reserved for defining a back reference to
groups in SVN administration... so IF Aaron did set me up as my email
address, it could being doing something it shouldn't be. I've tried
Marti1, marti1, thalamew, etc. as well but I can't guess at what he
set up my username as... I assumed it was based off of what he said in
his message about using my email.

Ref: http://svnbook.red-bean.com/en/1.4/svn.serverconfig.pathbasedauthz.html

Marti

unread,
Dec 15, 2007, 1:35:15 AM12/15/07
to greasemonkey-dev
Aaron Boodman wrote:
> Marti,
>
> I'm having trouble keeping up with your many (very helpful and
> appreciated) bug reports. I've given you SVN write access on
> greasemonkey.devjavu.com with the email address thal...@hotmail.com.
> Go create an account with that email address and you should be able to
> make changes to SVN.
>
> Can you setup a branch (eg /branches/marti1) with all these changes in
> it? Then it will be easier for us to review all at once and merge in.
>
> Thanks very much for your help,
>
> - a

Well I just ruled out my machine and Linux distro as being the
problem... tried it under Windows svn client... same forbidden
message. *le sigh*... the balls in your court.

Thankx
- Marti -

Aaron Boodman

unread,
Dec 15, 2007, 11:36:35 AM12/15/07
to greasemo...@googlegroups.com
On Dec 14, 2007 10:35 PM, Marti <thal...@hotmail.com> wrote:
> Well I just ruled out my machine and Linux distro as being the
> problem... tried it under Windows svn client... same forbidden
> message. *le sigh*... the balls in your court.

"le sigh"? Is that like a french sigh? I loves it.

I totally screwed up and forgot how my fancy permissions groups
worked. Sorry for all the trouble. Try again now?

- a

Marti

unread,
Dec 15, 2007, 3:24:57 PM12/15/07
to greasemonkey-dev
I saw that it takes quite a bit... unfortunately the bit is still
biting...

svn: Commit failed (details follow):
svn: MKACTIVITY of '/greasemonkey/!svn/act/ac1171f5-ac3a-42c2-938e-
e8c0372394ad': 403 Forbidden (https://svn.devjavu.com)

It's also possible that because someone else created my branch, the
the file permissions are set to theirs instead of mine now. My friend
left his windows lappy here for me to try... so i'll go try it there
too... but I suspect it's the same.

Oui Oui! - Marti - (and yes that's about the extent of my French LOL)

Aaron Boodman

unread,
Dec 15, 2007, 7:18:56 PM12/15/07
to greasemo...@googlegroups.com
On Dec 15, 2007 12:24 PM, Marti <thal...@hotmail.com> wrote:

> Aaron Boodman wrote:
> > I totally screwed up and forgot how my fancy permissions groups
> > worked. Sorry for all the trouble. Try again now?
>
> I saw that it takes quite a bit... unfortunately the bit is still
> biting...

Ok, try one more time please.

- a

Marti

unread,
Dec 15, 2007, 11:01:18 PM12/15/07
to greasemonkey-dev
Aaron Boodman wrote:
> Ok, try one more time please.
>
> - a

Vive la Greasemonkey!!! It worked!!!! 8D now I get the fun task of
importing all my rev's into my branch in the new local repository, and
then upload for review... I don't expect immediate feedback, but it
would be helpful too when the chance arrives. Probably won't be doing
much this evening tho... we'll see. I do have some more questions for
you too... but those can wait for a better time.

Thankx a million
- Marti -

Nikolas Coukouma

unread,
Dec 16, 2007, 12:14:33 AM12/16/07
to greasemo...@googlegroups.com
Marti wrote:
> Vive la Greasemonkey!!! It worked!!!! 8D now I get the fun task of
> importing all my rev's into my branch in the new local repository, and
> then upload for review...

Hrm, I see that in changeset 507[1] you removed all of the files from
your branch ...
If it was accidental, then ignore the following. If not, here's some
general info/insight/whatever:

In Subversion, using "svn copy" preserves history because it indicates
where the file(s)/directory came from (see changeset 505[2]); therefore
it's the preferred method of creating branches (and tags for that
matter). I can understand not wanting to have downloads/ and www/, but
it seems sensible to copy src/ from trunk.

Just like a regular file copy, changes (commits) only affect the copy
(i.e. the file(s) on the branch) and not the original (files on trunk).
It's generally recommended that you do commits on a (vague) "unit of
work" basis (generally a bugfix or progress on a feature).

Once you have things ready, you should e-mail the list to let people
know, along with a link to a diff in trac[3]. If approved, the changes
are "merged" (copied without clobbering other changes) into the trunk
version. Depending on how long your branch is around you might want to
merge changes from trunk into your branch, so they're in sync.

[1] http://greasemonkey.devjavu.com/changeset/507
[2] http://greasemonkey.devjavu.com/changeset/505
[3] http://greasemonkey.devjavu.com/anydiff

I hope the above is helpful and not overly presumptuous; it's just what
I've picked up from working on various projects. I also don't intend to
pick on you or anything, it's just that you seem to have little to no
experience with using version control (like Subversion) and this e-mail
might be informative to others who want to contribute... If it is
useful, I suppose I should copy it into the (trac) wiki.

Cheers,
-Nikolas

signature.asc

Marti

unread,
Dec 16, 2007, 1:45:12 AM12/16/07
to greasemonkey-dev
I appreciate the greek above... you are correct that I haven't used
svn before this last week, however, using it with SSL has caused
EXTREME unpredictable results and a lot of failures on commands. I've
been twiddling with my own local copy of the repository for about 5
days now, but not the secure (https) checkout... and I wanted to see
if the same commands worked with the https uri, and it MOST DEFINITELY
DOES NOT!... so I must checkout the repository via the http uri and
not use SSL at all... quite irritating actually.

It was my understanding that the branch is my "work zone" and any
changes in it could be reviewed THEN merged in. I usually test out a
software component for ease of use, and svn definitely doesn't agree
on the SSL... works fine under the non-SSL though... so somethings
awry. I'm guessing that my tests probably shouldn't be merged in... I
didn't want the www (and yes I could have just removed them, as
compared to other branches who have done that)... but I'll just leave
it in... the trunk has items that I would rather not work with (the
www)... but if it has to be on my local machine, it has to be.

I'll rereview your message and do some more reading... but I wasn't
expecting the SSL to screw up so much, especially after several days
of testing locally. At least it's committing... some of my questions
are:

1) How often do all of you want updates?... e.g. Shall I throw the
book at all of you all at once, or should I walk everyone through some
of the problems with the trunk one step at a time?

P.S. I'm not going to go near any other commands other than my own
folder for the time being, as I know it's important. So to answer your
question... it was on purpose, but was due to SSL failure with svn.

Marti

unread,
Dec 16, 2007, 2:19:28 AM12/16/07
to greasemonkey-dev
Nikolas Coukouma wrote:
> Once you have things ready, you should e-mail the list to let people
> know, along with a link to a diff in trac[3].
> ...
> Cheers,
> -Nikolas

I do appreciate the help... also have a specific one here..."e-mail
the list" doesn't mean much to me... does this mean start a new post
in this google group or use the email that I initially tried and it
bounced (or both)?

I'll make the diffs locally, but where am I supposed to put them?
This group only allows managers to post files, and I'm pretty sure I'm
not a manager... so there's no way to attach a file in a comment...
perhaps this answers the first question... email with the diff... not
create a post here perhaps?

Anyhow... at least I found out the servers SSL isn't compatible with
Mandriva's openSSL using svn... that should be something to be
investigated down the road... as long as no one minds cleartext use of
my branch, I'm kosher... I'm on a dedicated closed network so no probs
with anyone between my isp and me on sniffing.

Anyhow... I'll need some input from Aaron too as to, if all you guys
wanted was diffs, why he granted me branch privi's... like I said
earlier, I won't be doing anything of major importance tonight... just
wanted to make sure it worked. You'll note in http://greasemonkey.devjavu.com/changeset/512
it worked just fine... that was with the non-SSL checkout/copy from
trunk/commit... the rest of the changesets did all kinds of weird
things... like error 502 when it was trying to copy from the trunk...
I even rebooted my machine... then I went back to my non-SSL checkout
and tried the same commands and they worked fine... so no SSL for me.

Anyhow I hope this helps explain it to everyone a bit more... I am new
to some things, but to others I'm not, and I'm here to learn and help
one of my fave add-ons 8D (check out the greasespot wiki for
documentation changes I've been doing... still won't be done with that
for a while, but got a lot of holes plugged there)

THANK YOU FOR THE SUGGESTIONS!!!!! I do appreciate them very much.
- Marti -

Aaron Boodman

unread,
Dec 16, 2007, 2:43:14 AM12/16/07
to greasemo...@googlegroups.com
On Dec 15, 2007 11:19 PM, Marti <thal...@hotmail.com> wrote:
> Anyhow... I'll need some input from Aaron too as to, if all you guys
> wanted was diffs, why he granted me branch privi's...

It's easier for us to review large changes using branches than textual
diffs because we can just look at it using trac. For example, here's
one of my branches diffed against trunk a few revisions back:

http://greasemonkey.devjavu.com/changeset?old_path=branches%2Faa1&old=500&new_path=trunk&new=500

- a

Marti

unread,
Dec 16, 2007, 4:09:22 AM12/16/07
to greasemonkey-dev
Okay... well I'm going to start small for the moment (now that it's
tomorrow)... I couldn't wait any longer *GRIN* I built this a few days
ago based off of the original (I had a similar one, but this ones MUCH
better with the code from gm incorporated).

http://greasemonkey.devjavu.com/changeset/513

Check it out and let me know what you think of it. I've commented a
lot and hopefully that will answer some questions. Give it a whirl,
and I think it will be liked. 8D

- Marti -

Nikolas Coukouma

unread,
Dec 16, 2007, 9:04:05 AM12/16/07
to greasemo...@googlegroups.com
Marti wrote:
> http://greasemonkey.devjavu.com/changeset/513
>
> Check it out and let me know what you think of it. I've commented a
> lot and hopefully that will answer some questions. Give it a whirl,
> and I think it will be liked. 8D
>
Nit: the repeated code in if/else for making the xpi makes me cringe;
I'd prefer to set XPI_NAME and do the find and zip commands afterwards.

Perhaps this is actually important ...
The "find *| grep -v ..." stuff is a bit dangerous because you'll miss
things; you can actually do all of that using just find:

find . -name .svn -type d -prune -or -name CVS -type d -prune -or -name
.DS_Store -type d -prune -or -name '*~' -type f -or -type f -print

The above says "don't descend into directories names CVS, .svn, or
.DS_Store; ignore files ending in ~; print all other files". The
following is a more compact form that uses a regular expression instead
of a bunch of -ors; note that the default regular expression is *emacs*
and can be changed by the -regextype option. Also note that the quotes
are needed to keep the shell from expanding things (e.g. turning *~ into
install.rdf~ chrome.manifest~).

find . -regex '.*/\.svn\|CVS\|\.DS_Store$' -type d -prune -or -name '*~'
-type f -or -type f -print

The MochiKit case is handled by not printing directories. If directories
need to be printed, remove -type f before -print and you'll need to add
the MochiKit case to the regex; -empty -type d won't work as intended
because of the .svn (and so on) directories.


find . -regex '.*/\.svn\|CVS\|\.DS_Store\|MochiKit$' -type d -prune -or
-name '*~' -type f -or -print

Cheers,
-Nikolas

signature.asc

Marti

unread,
Dec 16, 2007, 3:57:02 PM12/16/07
to greasemonkey-dev
Nikolas Coukouma wrote:
> Nit: the repeated code in if/else for making the xpi makes me cringe;
> I'd prefer to set XPI_NAME and do the find and zip commands afterwards.

This is feasable to set a system variable to determine it. As I noted
in the top of the script, there could be more improvements. But in
the interest of this being my first suggestion as well as not "shell
shocking" Aaron (and everyone else), since he's ultimately the one
that will be executing this primarily for the releases... I wanted to
introduce the fix/wish grant, rather than discuss omptimization of the
script.

Btw... what does "Nit:" mean?

> Perhaps this is actually important ...
> The "find *| grep -v ..." stuff is a bit dangerous because you'll miss
> things; you can actually do all of that using just find:

Re: Your example of

find . -regex '.*/\.svn\|CVS\|\.DS_Store\|MochiKit$' -type d -prune -
or -name '*~' -type f -or -print

still includes the MochiKit folder in the xpi on my distro... No one
answered my question earlier in this thread about WHY IT EXISTS in the
first place, as well as I'm reminded of your statement in the context
of using grep.. "you'll miss things;". Please note, I'm not picking on
you either, I'm just offering some constructive observation from a
different vantage point.

Using a single find WITHOUT piping it through multiple greps is
definitely faster, but as far as readability goes, it's a bit more
complex for those who haven't utilized those functions before. This
seems like it could work with some tweaking for globalisation across
the Linux distro's... but missing a currently existing item that grep
doesn't, means it deserves further examination and perhaps changing it
to an extended regex instead of emacs would solve the issue... but
then you would lose the "compact" nature you are looking for due to an
additional switch parameter.

Nikolas Coukouma

unread,
Dec 16, 2007, 8:33:07 PM12/16/07
to greasemo...@googlegroups.com
Marti wrote:
> Nikolas Coukouma wrote:
>
>> Nit: the repeated code in if/else for making the xpi makes me cringe;
>> I'd prefer to set XPI_NAME and do the find and zip commands afterwards.
>>
>
> This is feasable to set a system variable to determine it. As I noted
> in the top of the script, there could be more improvements.
It's just a variable within the shell script and certainly isn't
system-level ;) Anywho ...

> Btw... what does "Nit:" mean?
>

I was abbreviating "nitpick" to indicate that I was pointing out a
detail of little or no consequence.

>> Perhaps this is actually important ...
>> The "find *| grep -v ..." stuff is a bit dangerous because you'll miss
>> things; you can actually do all of that using just find:
>>
>
> Re: Your example of
>
> find . -regex '.*/\.svn\|CVS\|\.DS_Store\|MochiKit$' -type d -prune -
> or -name '*~' -type f -or -print
>
> still includes the MochiKit folder in the xpi on my distro...

I must have screwed up the test somehow; adding parentheses for grouping
fixes it

find . -regex '.*/\(\.svn\|CVS\|\.DS_Store\|MochiKit\)$' -type d -prune
-or -name '*~' -type f -or -print

> No one answered my question earlier in this thread about WHY IT EXISTS in the
> first place, as well as I'm reminded of your statement in the context
> of using grep.. "you'll miss things;".

I actually meant to say that it would be overzealous. It would filter
out a file or directory like "foosvnbar" (as unlikely as that is). Sorry
for the confusion and errors.

MochiKit was around for a bit, but has been gone since before the
migration to DevjaVu; the directory can be removed entirely, as far as I
know.

> Using a single find WITHOUT piping it through multiple greps is
> definitely faster, but as far as readability goes, it's a bit more
> complex for those who haven't utilized those functions before.

I thought we'd crossed that line with the use of sed, but I certainly
see your point ...

> This
> seems like it could work with some tweaking for globalisation across
> the Linux distro's... but missing a currently existing item that grep
> doesn't, means it deserves further examination and perhaps changing it
> to an extended regex instead of emacs would solve the issue... but
> then you would lose the "compact" nature you are looking for due to an
> additional switch parameter.

The regex does become more readable by switching to a more common syntax:

find . -regextype posix-extended -regex
'.*/(\.svn|CVS|\.DS_Store|MochiKit)$' -type d -prune -or -name '*~'
-type f -or -print

I'm also notconcerned with the length of the line as much as I am with
correctness and grouping things together... I find the regex much faster
to read (but I also know that I'm weird).

As for compatibility:
-regex is an extension. GNU find(utils) defaults to emacs syntax. BSD
find defaults to
"basic" syntax (no support for | alternation among other things) and
Solaris 9's find (from XPG4) doesn't support -regex at all. -regextype
is present in find 4.2, but not 4.1 which is still present on some
slightly crufty systems (e.g. previous stable version of Debian).

For maximum compatibility and readability, I'd use:

find . -name .svn -type d -prune \
-or -name CVS -type d -prune \
-or -name .DS_Store -type d -prune \

-or -name '*~' -type f \
-or -type f -print


... but the difference between using find and grep is pretty small in
our case since the directory trees are small and those weird file names
are unlikely. I also think it would be reasonable to drop the -type
checks even if find is used.

Cheers,
-Nikolas

signature.asc

Aaron Boodman

unread,
Dec 16, 2007, 10:18:26 PM12/16/07
to greasemo...@googlegroups.com, greasemo...@googlegroups.com
The mochikit directory should be removed.

> find . -regex '.*/\(\.svn\|CVS\|\.DS_Store\|MochiKit\)$' -type d -
> prune

Marti

unread,
Dec 16, 2007, 11:28:28 PM12/16/07
to greasemonkey-dev
Aaron Boodman wrote:
> The mochikit directory should be removed.

@Aaron
Will do... which leads to my next question questions...

@Nicokolas too
find * -regextype posix-extended -regex '.*/(\.svn|CVS|\.DS_Store|
MochiKit)$' -type d -prune -or -name '*~' -type f -or -print | zip
$GMNAME-$GMVER.xpi -9X

that line is what works for my distro... when I use . instead of *, it
won't remove the MochiKit (and yes Aaron I read what you said about
removal, but thinking to the short and long term future a lil bit
too.)

I can see Nickolas' point on using find by itself in his syntax. I
read regex's all the time and fix them when needed... (Firefox uses a
form of extended regex, and so does the sed command... which is why
that part works... it would be handy to have everything "sync'd" up
with regex types... OS X (including Leopard) and every Linux distro
I've twiddled with includes extended RegEx, which is why I use it...
so the decision to use it is fairly obvious to me). The decision is
up to you... grep filters out probably more than it should for future
ideas, whereas using finds regex is clearer but seems to have a cross
platform issue. I've put my feelers out to my NIX buddies and they
seem to think that using the . in bash will expand it to the current
directory versus meaning everything ... that's consistant with what I
know about . versus *... so if the find extended regex is used, it
needs to work on your system with the *, as it won't work without it
on Mandriva... I'm "bleeding edge" on my distro here as it's only a
few months old, but it's up to date... MAC is usually up to date as
well.

So use this in determining your decision if you want me to continue
using grep or find -regexp

@Aaron
Question 1) I do however need to know what's REALLY necessary.

I understand the .svn part, as svn has hidden folders all over the
place... but...

Is a CVS really necessary? The only time I can think it would be is
if the repository is still accessed via CVS.

Is the "#" filter that is currently there, for files or folders or
both? I currently don't know of any editor that actually subs that in
anywhere... but it was originally there for a reason... I just need to
be enlightened on why, please. (is this part of CVS ? btw
@Nickolas... Nit: you left this out of your expression test ;D

The *~ I see a lot under gedit and kwrite, so that needs to stay...
I usually turn that off in my own editors, but not everyone does.

The .DS_Store files are the "fork" bit in the MAC, so that needs to
stay too in case someones editing source on a MAC.


Question 2) If I do end up dumping the if/else construct... the
filename, IF there is a problem, will create a file called
greasemonkey-.xpi instead of greasemoneky.xpi... is this okay with you
Aaron? I've actually already got the code in there, and it does work
that way... but whether or not you want the trailing hyphen is the
burning question.

After this, I can move onto my next suggestion 8D and of course it has
a few questions too about it... but will wait for further comments on
this step.

Thankx,
- M -

Marti

unread,
Dec 17, 2007, 12:07:47 AM12/17/07
to greasemonkey-dev
P.S. Nikolas... sorry about typing your name wrong several times...
it's an unusual spelling for me, so it's hard to get the noggen to
type it correctly... I do have typos... (e.g. greasemoneky above too
should be greasemonkey LOL) Too bad this forum type doesn't seem to
have an edit to correct things like that. anywhooooooo. - Marti -

Nikolas Coukouma

unread,
Dec 17, 2007, 12:12:22 AM12/17/07