shinzlet
commented
3 years ago Well, I'm glad you're interested in the project! Seeing as there's a lot to cover here, I'm going to address this all as a list.
Readme change: I've actually always seen the userscript API as a bit of an unfortunate weakness, due to its poor adoption and glaringly lacking implementation. However, it does let me get a lot done with very few LOC, which is why it's in the project. That's actually a very important justification for why many attributes of Oildrop are the way that they are - the more code there is, the less accessible and desirable a self-audit becomes. Regardless, I do see what you mean! There might be some people who find the userscript API desirable.
CSS Injection: That looks like a much more appropriate method, I agree. I'll have to take some time in the future (or if you want to, feel free) to explore that improvement. I imagine that the URI globbing is the same for the contentScripts API but I don't have time to check right now. I agree that security does not superficially seem to be compromised, but I would want to consider that more fully before adding it to a release.
GM Header: I think I agree with you there. This feature would definitely require reworking Oildrop's guts a little bit, but I'm in support of it. I also imagine it could be done modularly and with a reasonable code footprint - just off the top of my head, I think that the best way to do this would be to parse the GM header during the saving process to extract the Oildrop relevant metadata and store it outside the script text for easy sorting / filtering later on.
I have considered making oildrop handle .user.js files (there's actually some old code in a previous commit for it), but I think I want to give it an excess of caution with respect to the user interface. Generally speaking, I think that installing a userscript that you / someone you trust did not author or audit is a really bad idea, and I do not want to compromise user privacy by treating userscripts like they're lighthearted and collectable.
Thanks for your expertise about GM.xmlHTTPRequest - I don't actually have a ton of familiarity with GreaseMonkey, so that's useful to know. I agree that implementing GM header support and this api call would be a good MVP for GreaseMonkey compatibility, and perhaps even an endpoint - while some GM compatibility would be good, I do not want to implement function calls that are niche or redundant.
With respect to the editor and aesthetics - Oildrop actually has always supported editing in a new tab. The option is under Settings / Open Oildrop in a new tab:
It might be a good idea to bring that up more prominently - I do agree that it can be annoying to write in a different tool then copy/paste.
One consideration I had for a while was integrating Oildrop with a different website that acts as a web IDE (like JSFiddle), so that you could write a script in that full page, then tell Oildrop to copy source code from the text field without ever having to trust that IDE with your browser data. Ultimately I stopped pursuing that because I couldn't find a web IDE that felt right for the job, and it would have added bloat where I didn't want it.
I'm not horrifically opposed to allowing the font to be disabled, but I would rather add web IDE integration as mentioned before or just change the default font to one that is more agreeable. The font currently used is SpaceMono, and it was chosen without much consideration beyond "ooh, pretty".
The new script click away issue you mentioned is not something I have control over - from what I can tell, popups will always close when the user clicks outside of them. This could be fixed in one of two ways:
- Just use Oildrop in a new tab (I generally do this for longer scripts)
- Adding the option for Oildrop to be opened as a sidebar in firefox (e.g. bitwarden's default). I would definitely want that to be opt-in, though, because Firefox sidebars have always seemed a little clunky to me.
"Use tab to indent" is strictly for accessibility - it isn't about the spaces vs tabs debate commonly seen in programming. If a user does not have a mouse, or uses a screen reader, they'll likely rely on the tab key to mean "navigate to the next field in this form". However, if the code field captures the tab keypress in order to indent, they aren't able to tab-navigate out of that field, and therefor cannot use Oildrop at all. If you have a better idea for a name, I'm happy to use it, but that feature is both necessary and intended.
Anyhow, my apologies for the lack of editing and carefulness that went into my reply - I'm quite busy lately, so I figured it was worth replying even if I didn't have time to comb through my words. I really appreciate your interest in Oildrop - your passion for it definitely made me smile.
If you want to discuss any of these points further, I'd appreciate it if you opened a new issue that's specific to the feature, just to make tracking them easier. Additionally, feel free to get ahold of me at sethhinz@me.com if it's ever more fitting than opening an issue.
Cheers!
Excited to see a new user script project. I have a couple of ideas for you, let me know if you want anything split into separate issues.
If I understand correctly, you're using the new-ish userScript API. That's great! I'm glad to see it receive more adoption. Since it's a potential selling point of oildrop, I suggest putting that fact in the README.
It looks like the way you're injecting CSS is creating a function that injects it into the page, and saving that function as a userScript. A cleaner way to do that would just be to register a contentScript for each CSS script. Surprisingly, the contentScript API supports CSS even though the userScript API does not. Since no JS would be running in content scope, I don't believe this would have any security implications.
Support for the standard Greasemonkey header wouldn't be hard to add or too complicated, and would make way for a number of convenient features:
GM.*API. In conforming userscript managers, API access is gated behind the@grantheader. There is a very good reason for this: if I make a mistake when coding a script, it is possible to accidentally give a malicious script in the page the ability to execute arbitrary code in the same context as my code. If my code has access to theGM.xmlHttpRequestAPI, then this malicious script will be able to make arbitrary cross origin requests, breaking the security assumptions countless sites rely on. So well designed scripts don't grant themselves access to the APIs unless they absolutely need them. In other words, if you plan to implement theGM.*API, supporting the@grantheader is a necessary preliminary step.The
GM.xmlHttpRequestAPI is an interesting case because it's (a) easy to implement, and (b) by far the most common GM API used by scripts. There are good reasons for both these things.So I think an excellent starting point for user script compatibility would be to implement the above two suggestions. I think I could make every user script I use work with oildrop if that happened.
The interface is not great at present for creating scripts of more than a dozen lines. You mention this in the Readme, but a few more lines of code and some alternate CSS could likely make it good enough for most purposes. I'm not asking for auto-complete, linting, or even syntax highlighting, but other user script managers are at least able to pop open a full size editor window, and that's really all I usually need. (Think about making a small change to an existing script.)
A couple of interface tweaks that would be extremely useful:
Hope all these ideas aren't too overwhelming. Feel free to say "not really interesting in any of them, go make your own user script manager", which is something I've been thinking of doing for a while now. 😀 Honestly, though, I have too many projects where I decided to do something entirely myself because I wasn't happy with the available options, so contributing to someone else's project would be ideal for me.