@include / @exclude rules should be more expressive and/or safer #1016

Closed
arantius opened this Issue Aug 11, 2009 · 11 comments

3 participants

@arantius
Collaborator

See:

There is both demand and room for enhancement of the behavior of @include and @exclude rules. Proposals include:

@avindra

"leading (and trailing) slash means pure regular expression"

Any word on if, or which version this will be implemented in?

@erikvold

"leading (and trailing) slash means pure regular expression"

This is something I would like as well, it would mean that the pattern would not need to be converted into a reg exp for 1, and 2nd it will mean that a far fewer number of regular expressions will have to be executed against the location.

@arantius
Collaborator

The set of 36 thousand scripts I have from the survey I ran back in September has exactly one script with an include or exclude that has a leading and trailing slashes: one that has the entire script all in many @include lines, including some /* ... */ lines.

I call that zero backwards compatibility issues, and a feature win that I have wanted for a plenty long time, so I'm planning on putting it in 0.9!

@erikvold

sweeeet =]

I forgot reason 3: the regular expressions executed will be faster, because they are smarter.

And reason 4: the include patterns will be more accurate

@erikvold

I did my testing by modifying http://gist.github.com/303782

@erikvold

I'd like to vote against implementing @match, the rationale seems to be that Google wanted to be able to tell users which domains the userscript being installed runs on, so they created @match which is more restrictive than @include such that they will be able to deduce the domains the userscript runs on.

I agree w/ the rationale (it's good to show the user the domains the userscript is requesting access to), and I think that userscripts should only be able to opt-in to domain access, and not say they want access to everything accept domains x, y, and z; that will add to a user's confusion, because saying it needs access to everything is enough. This is why I think that they didn't @exclude (or did they?)

So I'd like to suggest a new metadata attribute @domain (or whatever else you think is better) to be a list of domain host names, one @domain for each domain, and the optional @domain *.

This could hit 3 birds with one stone I think. Firstly no need for @match. Secondly w/ some work we could reduce the number of user scripts that have @include/@exclude patterns compared to a page's location (on page loads) per request by indexing user scripts (or simply putting them into domain 'buckets'/folders) based on the domains they request access to. Thirdly it could be used for GM_xhr in issue #1052.

Thoughts?

If you are wondering what I have against a having @match implemented, well if you have a userscript with say 5 @include patterns, and a couple of @excludes, or one ~complicated reg exp :) and you decide to implement @match patterns for better compatibility w/ chrome, only that ended up being about 13 @match patterns.. well when you run that userscript in GM pages that the userscript does not run on will have executed 13+(1 or 7) regular expressions against page locations per request, because GM will execute both @match and @include (like chrome does atm...) which is slower.

@arantius
Collaborator

I'd like to vote against implementing @match

I'm not aware of any GM developer's plans to implement @match today.

So I'd like to suggest a new metadata attribute @domain ... Thoughts

Complicated, and for little benefit. I don't like it.

As a big part of GM 0.9, I want to significantly simplify the UI for the average user, and encourage the sort of users that want to know things like what domain a script might run on to inspect the actual source. The vast majority of users won't read this list anyway, so it's potential value is small.

And remember:
http://www.greasespot.net/2009/11/greasemonkey-api-usage.html
At least of scripts that use GM APIs, the vast majority only affect 1 (~75%), 2, or all domains (~9% each). The list of includes will already communicate this about as plainly as it can be communicated.

@erikvold

@domain is complicated? I didn't think of that.. even tho authors can ignore it? meaning @domain * by default?

The benefit grows the more you use greasemonkey.

What domains would @include /.[jksgdfh][oasjdfh][jkaogkjb][jkagdnhfjk][ajsdhfksdfl][asghkfejk]./i run on?

@erikvold

btw I created a new branch in my repo, w/o any of my other changes, and just the @include reg exp update, which you can pull from http://github.com/erikvold/greasemonkey/commit/f2ecddecd632256264825ae2d81558574e5fd5f5 if you wish.

@arantius
Collaborator

I'm going to split this into two issues:

@arantius arantius closed this Jul 20, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment