execution order context menu items should only appear if the the sort order type is by execution order

[erikvold]

When a user is sorting user scripts by name or date last updated, and then tries to use the execution order context menu items there is no feedback that the operation was completed successfully, and this could cause confusion I think.

[sizzlemctwizzle]

I agree. I was confused at first when I used one of the change execution order menu items when the list wasn't sorted by execution order. They should only show up in the context men when sorting by execution order imo.

[arantius]

Or should they be available, and using them implicitly also switches you to that sort order? I'm just worried about discoverability.

[erikvold]

is this really a useful feature to your mind if GM ever supports @run-at?

[arantius]

The point of this feature is to let script A which modifies the page in such a way that page B breaks be configured to run at a later point in time. If they both declare the same @run-at (I'd expect 90%+ of scripts to leave it at default) you still need this.

[erikvold]

If they both declare the same @run-at (I'd expect 90%+ of scripts to leave it at default) you still need this.

I implemented a @priority header for Scriptish to deal with this issue, so I don't think it is needed for this case.

[sizzlemctwizzle]

Or should they be available, and using them implicitly also switches you to that sort order?

I think this is the way to go.

If they both declare the same @run-at (I'd expect 90%+ of scripts to leave it at default) you still need this.

I concur. Changing execution order of scripts is how we've always dealt with this issue in the past and I believe it is the correct solution. It deals with the problem directly rather then creating some workaround.

[erikvold]

@sizzlemctwizzle saying it's right b/c you think it's right isn't a reason for it being right.. in the past there wasn't a @run-at (yaya GM is still living in the past..)

[sizzlemctwizzle]

@run-at doesn't directly solve the problem of certain scripts needing to be run before other. As arantius already stated, if you have two scripts that need to be run at document-start and one needs to be run before the other then @run-at is no help. Allowing users to directly modify execution order does work and this is why it's the correct solution.

(yaya GM is still in the past..)

No need to take a cheap shot at GM.

[erikvold]

@run-at doesn't directly solve the problem of certain scripts needing to be run before other

I never said that was the case...

As arantius already stated, if you have two scripts that need to be run at document-start and one needs to be run before the other then @run-at is no help.

I don't think that was a point that Anthony was making, that is obvious.

Allowing users to directly modify execution order does work and this is why it's the correct solution.

Ok, now I think that you've misunderstood the argument I'm trying to make.

[arantius]

So, if we support @run-at (we want to: #1103; Erik: does Scriptish's solution work in Firefox 3?) then I wholly agree that any existing "choose your execution order" UI will fail to make sense.

At best, it would have to have N sections (at least start" and domcontentloaded, plus any other points like load or idle or whatever @run at actually supports). And it would have to make sense why there are separate sections, and you could only order things within sections. Ugh.

P.S. Yes, GM moves slower than our wishes, but that's (partially) because we care about keeping our large existing user base happy. We still work in Firefox 3, which is important.

[erikvold]

does Scriptish's solution work in Firefox 3?

No unfortunately, it won't work for FF3, imo the method used in Scriptish should be used when it's available though, but the other method that's been tried over in #1103 might be a suitable for FF3; I tried it briefly long ago and it worked as I recall, tho I didn't try iframes.

[qufighter]

If we still need drag and drop sorting that's the type of thing I like doing... unless there's just a sortable list already... but it seems like the execution order needs to be indicated in any view (colorize? show numbers? or not)... (I like the @priority notion at least for default ordering), if the list is sorted by name and someone drags and drops a script it could still move it in execution order although it's definitely a mess, but if you drop a script before or after another then one could infer what order is desired in most cases,

yet I personally think that search feature or filtering is more useful than alphabet sort... if it's shown by execution order and you can search for starts with A or F something like ^a|^f (maybe a filter creator eventually) then ordering any two scripts gets a lot easier because you won't have to drag very far, you order the two you want, the only two that show.

It does make sense that ordering any @run-at doc-start scripts will be interesting, since they will essentially always be sorted first and can only be sorted with other doc-start scripts, so the user would need to be shown this (red line means cannot drop drag, try it twice and get a message? some divider line between them? confusion)

but it gets crazier yet since document start scripts can still inject doc-end code, they do it independently from our injection process, so some research of the order this occurs could be done in various ff versions....

Does adding doc-start and your own doc-end listener suddenly give you first dibs at doc-end execution versus any script? I tend to think not but also that someone will at some point want to have each execution of a script sorted, doc-start first and domContentLoaded in between other normal scripts. I tend to think skipping this won't be a problem at first...

Listeners get called in the order they are added, anyone ever try to re-order that stack? I know you can make it at least roughly first or last, maybe that's enough, maybe not. The author can always write two scripts or come up with inter-operability solutions somehow, sorting is a very important way to keep using scripts that are no longer supported without trying to re-engineer anything.

Every author wants their script to run first just so they don't have to check if that element still exists before messing with it, which could be considered a bad scripting practice in the first place given the stochastic nature of web pages. Ordering alone cannot solve all problems but it gives the user community a lot of much needed power.

[sizzlemctwizzle]

If we still need drag and drop sorting that's the type of thing I like doing...

If you'd like to implement that I'm sure we'd all like to have that.

if the list is sorted by name and someone drags and drops a script

I don't think dragging should be allowed if the execution order is not selected. It was just be confusing to the user.

Does adding doc-start and your own doc-end listener suddenly give you first dibs at doc-end execution versus any script?

I don't think scripts with with different @run-at should be sortable together at all. See issue #1339.

Every author wants their script to run first just so they don't have to check if that element still exists before messing with it

Which is why I'm against implementing @priority.

[arantius]

Wow, that was sort of a rambly novel there.

Purely personally: First, I think the whole need to reorder scripts is weird. I have personally never used a script that broke because another script changed the page. If I did, however, I know that the solution is just to pick the broken script and tell it "execute first". That's it, now everything works. I don't need to click into execution order because I don't care what it is, I just know this one script needs to go earlier.

Drag 'n drop: I don't like this. It's confusing at best if the current sort isn't execution order. What should we do if, by name, the first-to-execute sorts second and the last-to-execute sorts first, and I drop a script in between them? When should it execute? It's extremely nonobvious, and unpredictability provides a poor user experience.

Ordering at all after run-at: if we implement run-at, I'd aim for (near) compatibility with Chrome, which provides three separate points (start, end, idle) and Scriptish also provides load.

A) If there are four separate run points, all we can really offer is ordering within those groups.
B) If an at-end script breaks an at-load script, no amount of ordering with in the load group will make the broken load script run before the end script.
C) Even so, the UI to communicate that "you can reorder this list, but you can't put item X above point Y" is not likely to come through clearly. It will probably look broken.

At this point we need to rely on authors to make scripts that work.

[erikvold]

At this point we need to rely on authors to make scripts that work.

I agree, and my thought is that @priority is giving authors a tool they can use to make their scripts more compatible with other scripts. It can also do the opposite though in the hands of bad authors..

Every author wants their script to run first just so they don't have to check if that element still exists before messing with it

Which is why I'm against implementing @priority.

I think users will either bitch slap those authors, ignore them, fork, or simply alter the @priority.

[sizzlemctwizzle]

I think users will either bitch slap those authors, ignore them, fork, or simply alter the @priority.

It could work, but we'd be moving another thing from the UI to the script metadata and we already learned how much users hate when we do that. It might be the right thing to do, but it also might be a hard sell.

[qufighter]

An author (or user) could alternatively create one script that @requires each of them in the correct order of priority. Scripts can always be coded to work in any order, yet some scripts will try to use the least code and require a certain order.

I kind of think the menu items for sorting should be grayed out and above them a new item appears that says "script sorting..." where it switches modes and the clicked script is mid-view selected, however this lends to drag-ability... otherwise they should only show when in sort mode as suggested.

[sizzlemctwizzle]

Returning to the actual topic of the issue, I wrote a simple patch that just disables the execution order context menu items when not sorting by execution order.

Edit: And here is an alternate patch that switches to the execution order sort when one of the execution order items are selected.

[qufighter]

Even so, the UI to communicate that "you can reorder this list, but you can't put item X above point Y" is not likely to come through clearly. It will probably look broken.

I agree there are problems with this, however the type of drag sorting I was thinking about has a transparent version of the row moving while you drag, also spaces in the list opening up for that script to be dropped, so if you drag it out of it's section then spaces will no longer open up, the script could not move any further, it will not move beyond last or first in it's section, auto scrolling would stop, ect. If we place an empty, 1/8th height item between sections (when needed) then they will be delineated pretty nicely, which can have a user friendly title for the @run-at type. Early|Normal|Final Userscripts ... perhaps the install dialogue could inform the user what type of script they are installing.

Mousing over the section title could explain:

"The script(s) in this section was(were) designed by it's(their) author(s) to run at "...

" document-stat. This means each will start to run while the page is downloaded, and each starts running before all other Userscripts"

" document-end. This means each will start to run as soon as the document is fully downloaded"

" document-idle. This means each will run after all normal Userscripts have already started running"

...". You can only sort the execution order within each script type"

I would love to speed up switching between sort modes. I only have 93 scripts and it lags quite a bit.

[arantius]

(deleted comments-in-wrong-issue)