Greasemonkey: The user should be able to control script execution order

Created on 15 Nov 2017 · 10Comments · Source: greasemonkey/greasemonkey

"Execution order" sorting is the feature I miss the most from the legacy full-tab "manage" dialog.
Currently (in GM 4.0), as it seems, the scripts are executed as they are listed in the popup, i.e. in alphabetical order.
With this sorting no longer available, there's no quick way to resolve userscript conflicts anymore.

For reference, I quote from the (now removed) 'Script order' wiki page :

_Script order_

_Scripts can be displayed in order by:_

_Status - Scripts are ordered by activation status: enabled or disabled, then name._

_Name - Scripts are ordered alphabetically by name regardless of status._

_Execution order - Scripts are ordered by execution index._

_This last order is important for user scripts that conflict with each other. By changing the order of the scripts the conflict can be resolved. You can change the order by right-clicking an user script and choose one of the actions: Execute first, Execute sooner, Execute later or Execute last._

Source

darkred

Most helpful comment

This is indeed a feature of 3.x missing from 4.x.

I'm definitely not going to promise any particular feature/UI, but being able to have two scripts installed that must run in a particular order would be good.

arantius on 15 Nov 2017

👍3

All 10 comments

This is indeed a feature of 3.x missing from 4.x.

I'm definitely not going to promise any particular feature/UI, but being able to have two scripts installed that must run in a particular order would be good.

arantius on 15 Nov 2017

👍3

What if in the script source we had a // @priority (int) feature, or perhaps we should call it a runlevel as priority could be miss leading
each tear can be started at/near the same time via async functions
we should probably support negative values also

GM-Script-Writer-62850 on 20 Nov 2017

Unlike UNIX runlevels, for which there's sort of a natural order, the order of execution for scripts seems more arbitrary. I think it should be up to the user. A default priority that comes from a tag in the script isn't a bad idea, but there needs to be a facility for overriding the order, as there has been in previous versions of GM.

tonycpsu on 20 Nov 2017

I do agree with that, but we could edit the runlevel/priority of scrips from the source if need be; i assume that would be easier to implement, at which point a ui could be built around it

GM-Script-Writer-62850 on 20 Nov 2017

Vote for this too. Some of my scripts need to be run in particular order and break if run not in their time.
I too think this should be up to the user to decide this order. UI can refer to a kind of "order"/"runlevel" directive from the script but the last word must be the user's. I can even imagine a pair of scripts which behave intentionally different when run 1st-2nd or 2nd-1st, as both refer to the page's DOM which is changed by them.

Unchqua on 24 Nov 2017

IMHO a runlevel is not what we need here.
I think, in most cases, it's just about executing script A before script B.
This is a (relative) restriction. Runlevel is an absolute measure. Not adequate.
Also, the restriction is quite sparse. All you need is the "earlier"/"later" thing,
and maybe, just for comfort, "first"/"last"...

Eselce on 24 Nov 2017

This is not (strictly) a property of the script itself, so it should not be a header @tag baked into the source. This is a symptom of some combination of scripts whereby one's changes breaks the other (but not vice versa), so the other must run first.

arantius on 28 Nov 2017

Will this feature still be a thing some day? I've been missing it since 4.x came out, and had to do some poor workarounds in my scripts to be executed in the right order for the time being.

StrikeAgainst on 14 May 2019

... some poor workarounds ...

What was the workaround, and why was it poor?

arantius on 14 May 2019

I remember creating an invisible div with one script, and setting a timer in the other, which was to check whether the div existed yet. Or was that stupid?

I don't think one can set global variables with Greasemonkey and have them be accessible by other scripts? And even that would require setting a timer, wouldn't it?