@run-at metafield

[quoid]

Using the @run-at metafield, the user can decide when a script gets injected.

• document-end: when DOMContentLoaded fires
• document-start: asap
• document-idle: after DOMContentLoaded

Currently the extension injects at document-end.

[lojza3d]

Would it be possible to enhance this a bit more? For my needs, I would prefer manual (even repeated) injection on-demand, if that's somehow possible in Safari. My use case is that I need to run the same script occassionally when using an on-line WYSIWYG editor (for advanced content manipulation), therefore one-shot injection right after the page is loaded doesn't quite work for me.

Also, is there a way how to delay the script from running after the page is loaded? E.g. so it would run after 10 seconds or so... setTimeout() in the main script doesn't seem to do the job.

Thanks.

[quoid]

@lojza3d

Would it be possible to enhance this a bit more? For my needs, I would prefer manual (even repeated) injection on-demand, if that's somehow possible in Safari. My use case is that I need to run the same script occassionally when using an on-line WYSIWYG editor (for advanced content manipulation), therefore one-shot injection right after the page is loaded doesn't quite work for me.

In a way this is already possible, but how would you imagine a user would go about executing a script on demand? Are there examples in other userscript managers that do this?

I haven't thought much about this, but my initial reaction is that there are so many events and mutations in the JS api one can use to execute a script. Chances are, most of the time, it's just about choosing the right one and on-demand execution isn't truly needed. Rather, on-demand an easier path not the only path to appropriately timed execution.

As a mentioned above, you can already do the type of on-demand execution I think you are referring to (having some sort of UI element execution some bit of code). That is, if there really aren't the right "triggers" for code execution.

Here's a really quick example, try it on https://www.k21p.com.

// ==UserScript==
// @name        On Demand Demo
// @description This is your new userscript, start writing code
// @match       *://*k21p.*
// ==/UserScript==

function test() {
    alert("You clicked me!");
}

function test2() {
    alert("You ran me from the console!");
}

let btn = document.createElement("button");
btn.style.cssText = "position: absolute; top: 20px; left: 20px"; 
btn.innerHTML = "Click Me!";
btn.addEventListener("click", test);
document.body.appendChild(btn);

window.test2 = test2;

The first method here created a button, that button runs code when the user clicks it.

The second method created a function in the global scope - you can run this function from your browser console to execute code.

These are just two examples, but really, you could create any sort of element and/or special interaction to execute code.

Also, is there a way how to delay the script from running after the page is loaded? E.g. so it would run after 10 seconds or so... setTimeout() in the main script doesn't seem to do the job.

Can you tell me a little bit more about why you want to delay your code? I find a lot of the time people are really just searching for the right "trigger".

There's discussion about a delay method in the issue.

[lojza3d]

First of all, thanks @quoid for such a prompt reaction.

In a way this is already possible, but how would you imagine a user would go about executing a script on demand? Are there examples in other userscript managers that do this?

The only one I'm currently aware of is Code Injector add-on for Firefox. This one allows to manually inject saved scripts into any page, repeatedly. There may be more similar add-ons, but I wasn't able to find any for Safari (I'd suppose there may be some restrictions on Safari's side, which won't allow extensions to use their own pop-up windows or so... not sure, however).

These are just two examples, but really, you could create any sort of element and/or special interaction to execute code.

This is amanzing. Thank you for pointing me this way! I suppose this will solve my use case perfectly.

Can you tell me a little bit more about why you want to delay your code? I find a lot of the time people are really just searching for the right "trigger".

This was just an idea how to execute the script once the WYSIWYG editor I was mentioning gets fully loaded / initialized, which takes a few seconds, whereas the script gets fired right after the page is loaded. Anyway, with the possible solutions you suggested, the delay for the script is no longer relevant for me.

Thanks again.

[quoid]

This was just an idea how to execute the script once the WYSIWYG editor I was mentioning gets fully loaded / initialized, which takes a few seconds, whereas the script gets fired right after the page is loaded. Anyway, with the possible solutions you suggested, the delay for the script is no longer relevant for me.

If you share the website with me, there's probably a way to detect that load and execute the script once that happens. It'd be cleaner than a persistent button or console function.

Either way I'm glad my reply was helpful. I'm leaning towards not implementing built in on demand injection for now, but that could change in the future if I create a popover in the toolbar button area.

@lojza3d

[quoid]

done in above commits

[JesseFarebro]

Just to add to this: I was looking to port a user script from Tampermonkey which supports @run-at context-menu. I guess for the time being I can inject a button into the webpage as outlined by @quoid, but is there any interest in supporting the context menu? Is this even possible in Safari?

[quoid]

@JesseFarebro does it actually work in TamperMonkey?

I really want to support it, but the API doesn't exist for Safari App Extensions. It seems like it could work with Safari Web Extensions from my testing, though. It really irks me that there is not API parity between the two and it seems like Apple is really pushing for Web Extensions now after making us all move to App Extenions a few years ago. end rant

I posted in the dev forums months ago specifically because I wanted to implement what you suggest, but I got no replies.

Since the API does not exist, it can't be supported unless the entire extension is rewritten in Web Extension "format" and then other features would disappear (like being able to read/write directly to the file system). I've been toying with the idea of rewriting in both web extension and app extension to get the best of both worlds, but that would take a lot of time and might end up being worthless if App Extension support gets dropped by Apple soon (which I reckon might happen).

[JesseFarebro]

@quoid yes, it works as expected in TamperMonkey.

Hmm, I never knew there was this disparity between the two APIs. What's the reason for wanting to read/write from the file system? Would this be supported on iOS / is it even possible to port this extension to iOS given some of the restrictions? If it is possible to port to iOS maybe a pure WebExtension rewrite might be in order?

[quoid]

Hmm, I never knew there was this disparity between the two APIs.

Massive disparity.

What's the reason for wanting to read/write from the file system?

All userscripts are files on the file system, so reading and writing is at the core of the app. Other userscript managers, I believe, store userscripts in browser storage. I wanted the ability to edit userscripts, easily, in my editor of choice and the best way to do that was to read from a file system location. It also gave me the ability to allow easy syncing through my iCloud folder to share userscripts between machines (since I can set the location of my userscripts to any location on the filesystem, which happens to be my iCloud folder). Those are the main reasons that I can think of right now.

Also note that when this extension was first written, WebExtension format was not an option.

Would this be supported on iOS / is it even possible to port this extension to iOS given some of the restrictions? If it is possible to port to iOS maybe a pure WebExtension rewrite might be in order?

Browser extensions are not supported in mobile Safari, so there was never the option to make it iOS compatible.

However, this week it was announced that Apple will allow browser extensions in mobile Safari. However they will only seemingly support WebExtension extensions and not App Extensions. Considering that, this extension would not work on iOS.

maybe a pure WebExtension rewrite might be in order?

That's a big ask and a lot of work. I want to rewrite it in WebExtension format, but I have to manage my time because of work. If this was my only focus, it would be a no brainer, but that's not the reality.

I figure it could happen at some point, but will likely take quite a while.

[JesseFarebro]

Hmm, I never knew that you stored userscripts this way, this makes it easier for me to edit them now.

Yes, I was speaking of iOS extensions on Safari 15+ announced this week. I definitely respect your time and thank you for the amazing extension. I have no problem hacking away at some of this stuff when I get the spare time. I do have a couple of questions after a cursory glance at the code.

Why would @run-at context-menu not currently be possible? It seems that you send a native message to the backend to collect any userscripts that may run for a given URL. Once you receive a message back with a script that supplies @run-at context-menu couldn't you dynamically update the context menu via contextMenus.create e.g., in extension/Userscripts Extension/UserscriptsSafari.js? If you could do this you can immediately hook the context menu item to inject the loaded script? Or am I misunderstanding the bridge between Safari App Extensions vs. WebExtensions?

I think I get it, the injected scripts in Safari App Extensions just don't have access to the WebExtensions APIs? If that's the case couldn't we just change the "communication" layer, i.e., do this so we could still have the file system access of the native app but have a WebExtension frontend?

Furthermore, after looking more into it I don't see the reason to do a WebExtension rewrite unless Apple goes ahead and completely deprecates the App Extensions API, I even think it would be straightforward to support this on iOS with the current framework you have.

[quoid]

@JesseFarebro

I definitely respect your time and thank you for the amazing extension. I have no problem hacking away at some of this stuff when I get the spare time.

I appreciate that. If you are seriously interested, shoot me an email. If someone was to help out, I would want to organize the tasks with them rather than getting a spontaneous PR that might include features I am already in the process of working on.

I think I get it, the injected scripts in Safari App Extensions just don't have access to the WebExtensions APIs?

That's the way I understand it.

As mentioned in an earlier comment, there seems like there could be a way to rewrite in WebExtension format, and retain the currently functionality that already exists (some some ways).

EDIT: I see you updated your comment, yes that is the way I am speaking of which I alluded to in the above comments.

Furthermore, after looking more into it I don't see the reason to do a WebExtension rewrite unless Apple goes ahead and completely deprecates the App Extensions API, I even think it would be straightforward to support this on iOS with the current framework you have.

How though? It seems Apple has noted that only WebExtension format will be supported in iOS.