Working on a Greasemonkey fork for Pale Moon

[back2themoon]

Thanks for the 3.8 release!

Extension auto-update doesn't work, or is it intentional?

[sinfulosd]

I typically give it about couple more hours and then I make the update point to it, it's a new habit of mine, since I'm not really in a hurry for everyone to just start using the new version right away.

I will make the update point to it after few hours - you're more than welcome to manually download it right away if what's in the changelog is crucial for your needs right now.

[sinfulosd]

Version 3.8.1 has been released to fix a regression bug that flew over my head

In the meantime, I'll be working on both eliminating the new user script window (making you jump into the editor, the moment you decide to create a new userscript), and making the "show script source" in the install dialog open the new tab and support many QoL features like syntax-highlighting, line numbering, etc...

I think it's possible to utilize the browser's existing CodeMirror instance that it has and then I can create a xhtml file to implement it properly. We'll see how it goes.

[sinfulosd]

In the meantime, I'll be working on both eliminating the new user script window (making you jump into the editor, the moment you decide to create a new userscript), and making the "show script source" in the install dialog open the new tab and support many QoL features like syntax-highlighting, line numbering, etc...

I think it's possible to utilize the browser's existing CodeMirror instance that it has and then I can create a xhtml file to implement it properly. We'll see how it goes.

Here's a sneak peak into version 3.9

The changes are mostly done, but I'm still tuning some corners of it. This can also be a good opportunity to suggest any feature to be included into version 3.9

[back2themoon]

How about two further auto-update options for disabled scripts?

Check for updates once a week / once a month

The goal is to keep them updated without having to do it manually, and without adding unneeded background work (always check for updates).

[sinfulosd]

How about two further auto-update options for disabled scripts?

Check for updates once a week / once a month

The goal is to keep them updated without having to do it manually, and without adding unneeded background work (always check for updates).

There is an option for you to make the disabled scripts being checked for auto-update or not in Greasemonkey preferences, called "Disabled scripts are checked for automatic updates" and you can tick the box next to it to enable it or not (Unless if you're asking me to change the default setting to have it enabled).

But I do agree on giving the user the power to decide how often the scripts should be updated, in general. I'll be thinking of a way to implement that.

[back2themoon]

There is an option for you to make the disabled scripts being checked for auto-update.

Yes, I mentioned it ("always check for updates"). Perhaps I should've made it clearer. Essentially, I am suggesting these 4 available options for disabled scripts:

Always check for update (already exists)
Never check for update (already exists)
Check once a week
Check once a month

The last two I assume should be somehow independent of the enabled scripts update mechanism, which I guess makes it more complex than I initially thought.

[back2themoon]

Saw the "orphaned script" prompt earlier. Perhaps the name of the orphaned script(s) can be mentioned in that prompt?

(sorry if I missed it, I think it wasn't there - it did appear but only after having restored the script).

[sinfulosd]

Saw the "orphaned script" prompt earlier. Perhaps the name of the orphaned script(s) can be mentioned in that prompt?

(sorry if I missed it, I think it wasn't there - it did appear but only after having restored the script).

The orphan script mechanism was introduced, because when I was testing different versions, I noticed that some userscripts were no longer being shown in the tab, despite them existing in the disk folder, so I decided to create a mechanism that automatically scan them and prompt you to bring them back, in case if they have disappeared. It is not something that is made for you to see every often.

I also added it as a last-minute change in 3.7.0 and I haven't refined it, but I don't think it needs much refinement anyways, except adding it into the '.properties' for it to be translatable.

Essentially, I am suggesting these 4 available options for disabled scripts:

IDK, it seems redundant to me. I was already thinking of giving the users the power to decide how often exactly the userscripts should be updated and whether to include the disabled scripts in the update or not. I may not consider myself to be so much of a "power user" (yes, it may seem shocking for the one who develops the userscript manager is just a casual user, at the end of the day), but I personally do not see anyone's desire in setting the disabled scripts to be updated less or more frequent than the enabled one.

[sinfulosd]

Version 3.9 is finally out and can be downloaded from here

The long-awaited feature of jumping straight into the editor, the moment you decide to create a local userscript, new APIs to increase the extension's compatibility to support Tampermonkey-exclusive scripts, the updated source viewer that supports syntax-highlighting, and so many more features that can be viewed in the changelog.

I think I have reached the full parity with the mainstream userscript managers out there and any other feature/mechanism that would be introduced into the extension would be mainly covering the UI part of the extension.

The thing that I wanted to add into the extension, but couldn't find a good way to add it into the UI of the extension is the "Recycle Bin" feature, where the deleted userscripts are there, in case if someone wants to restore a deleted userscript - Feel free to weigh in any suggestion you have about it, I didn't want it to be another section on the left side, since it'll clutter the UI of the browser itself and having it accessable from the greasemonkey toolbar would be even worse and would clutter the already-refined toolbar.

I had the idea of the "recycle bin" page being accessible through the cog-wheel button on the page, despite that the visibility would be very low, but I decided to ask you guys about it first, in case if someone have a suggestion that didn't cross my mind or if you have the same suggestion of something that I dismissed, but you have a good reason why it would be suitable.

Off-topic:
It has been bothering me a bit on why do some users still use the old fork of Greasemonkey that not only is not functioning on many mainstream APIs, but also has a lot of vulnerabilities in it. Is it that they haven't heard of the new fork? Is it that they believe the new fork is in active development, so they assume they'll be facing a lot of bugs? Is it that they're skeptical about mine somehow introducing more vulnerabilities? I guess I'll never be able to satisfy everyone

[andyprough]

Off-topic:

It has been bothering me a bit on why do some users still use the old fork of Greasemonkey that not only is not functioning on many mainstream APIs, but also has a lot of vulnerabilities in it. Is it that they haven't heard of the new fork? Is it that they believe the new fork is in active development, so they assume they'll be facing a lot of bugs? Is it that they're skeptical about mine somehow introducing more vulnerabilities? I guess I'll never be able to satisfy everyone

I think the older version should be retired from the Pale Moon Add-ons and the Basilisk Extensions pages, as it is 8-years-old and unmaintained. If someone still wanted to use it for some reason, they could always just search 'github greasemonkey for pale moon' and find it easily. Once it is retired, I would expect more of a migration to your up-to-date version. I've been using your version and telling others to use it.

I've written a post in the add-ons section recommending de-listing the older, unmaintained version. We'll see if it gets a response.

I think I have reached the full parity with the mainstream userscript managers out there

This is an exciting milestone! Great work!!

[Gemmaugr]

Off-topic:

It has been bothering me a bit on why do some users still use the old fork of Greasemonkey that not only is not functioning on many mainstream APIs, but also has a lot of vulnerabilities in it. Is it that they haven't heard of the new fork? Is it that they believe the new fork is in active development, so they assume they'll be facing a lot of bugs? Is it that they're skeptical about mine somehow introducing more vulnerabilities? I guess I'll never be able to satisfy everyone

I've been using the old one because my scripts work with it, and yours was in the middle of being developed. I've also not looked into how much of a hassle it would be to migrate.

[sinfulosd]

Off-topic:

I think the older version should be retired from the Pale Moon Add-ons and the Basilisk Extensions pages, as it is 8-years-old and unmaintained. If someone still wanted to use it for some reason, they could always just search 'github greasemonkey for pale moon' and find it easily. Once it is retired, I would expect more of a migration to your up-to-date version.

I think someone reported an issue with my extension not being able to properly support old userscripts (that are also unmaintained and poorly written), but that's because they are poorly written and are not even supported in current Violentmonkey and Tampermonkey (which, whether we like it or not, are used as the current standard on how userscripts should be written). My extension, especially with version 3.9, is able to support every single userscript out there, whether they are written for Violentmonkey or Tampermonkey with their exclusive APIs. (Not to mention that it is superior in many ways that Violentmonkey and Tampermonkey are not, due to XPCOM's permissive environment)

I've been using your version and telling others to use it.

I wonder if all the Pale Moon developers are using my fork or if some of them are still using the old fork

I've been using the old one because my scripts work with it, and yours was in the middle of being developed. I've also not looked into how much of a hassle it would be to migrate.

Well, the good news is that there's absolutely no hassle, due to how the extension is storing the userscripts (They are stored on-disk, so whatever userscript manager fork you use, they'll use the same userscript directory). The only caveat is, if you're using userscripts that are either old to be compatible with the old fork or they're written in a niche way to be compatible with the old fork, they might not work as expected with the new fork (All the maintained userscripts and any userscripts that are written after 2020 are expected to be completely working with my fork). You're always welcome to report any issue you face, you'll be able to access my GitHub issues page through the extension toolbar menu, when you hover to the "Web sites..." label.

[UCyborg]

Is it just me or is it not possible to open options dialog of a disabled script?

[sinfulosd]

Is it just me or is it not possible to open options dialog of a disabled script?

It is indeed not possible to open the options dialog of a disabled script, since the page exist in the "About:addons" page, where it's also not possible to open the options dialog of a disabled extension.

[UCyborg]

So it's a pure semantics thing? Extensions are autonomous and it makes sense their code can't display options while disabled.

User scripts don't have that autonomy and are managed by an extension. If nothing else, from UI design perspective, it's weird to have a button that doesn't do anything. The equivalent button is hidden on extensions page in that case. Personally, I'd make it work regardless, especially since you also have enable/disable option in the dialog.

Stylem, which also extends about:addons page, also lets you edit disabled user styles.

[sinfulosd]

So it's a pure semantics thing? Extensions are autonomous and it makes sense their code can't display options while disabled.

User scripts don't have that autonomy and are managed by an extension. If nothing else, from UI design perspective, it's weird to have a button that doesn't do anything. The equivalent button is hidden on extensions page in that case. Personally, I'd make it work regardless, especially since you also have enable/disable option in the dialog.

Stylem, which also extends about:addons page, also lets you edit disabled user styles.

It's one of those design choices that was made, either by the original Greasemonkey developer or the old fork developer, that I don't exactly understand what is the point or what is the reason behind it. I had the intention to make the option page work, even when userscripts are disabled, when I was redesigning the options page, but I simply didn't know how. (I was already distracted by so many changes in the extension, including the architecture redesign) XML is my weak spot, and it was showing, no matter how great my Javascript skills were.

It is still something that I intend to look more into, hopefully I'm able to pull it off, by the next version of the extension. (not implying that there is currently an active development of a new version, right now) I'll checkout Stylem and see if this mechanism can be borrowed from Lootyhoof or how is it gonna go.

P.S. pull requests are welcome, if you're able to do it in a local change of your extension copy.

[back2themoon]

My humble opinion: since you said feature parity has more or less been reached, I wouldn't worry over secondary GM features (UI etc.).

I am sure everyone here is holding their breath for uBO news! 😋

(No pressure intended. UCyborg's version remains perfectly functional and helpful, and of course you know your resources best).

[UCyborg]

Oh, interesting, didn't realize that behavior with Options button not working for disabled scripts was inherited from the old version. Looks like it's been a long time since I tried using it on disabled script, otherwise, I might have remembered. But, my memory is not something to rely on...

Either way, no pressure, just food for thought and potential future enhancement.

[sinfulosd]

My humble opinion: since you said feature parity has more or less been reached, I wouldn't worry over secondary GM features (UI etc.).

I am sure everyone here is holding their breath for uBO news! 😋

(No pressure intended. UCyborg's version remains perfectly functional and helpful, and of course you know your resources best).

I actually support this opinion - I released version 3.9 with the intention of covering all the major and minor APIs, so that my modern fork would reach the 100% compatibility with all the userscripts out there, and I reached that milestone so early, because I wanted to be done with the development of the extension for some time (I personally do not enjoy the development process, I only enjoy the end-results).

I'm glad that the extension is completely stable and support all the userscripts out there, even the ones made, using the niche TM-exclusive APIs. I basically developed the extension to be usable, even if I decided to not update it for like 4-5 years to come by. The only things that are missing is some advanced configurations and maybe fine-tuning some corners in the UI of the extension, which I personally am not worried about, right now, but I'm willing to see any pull requests in my GitHub repo that may resolve something that either flew over my head or something that potentially would be better to see in the UI of the extension.

Oh, interesting, didn't realize that behavior with Options button not working for disabled scripts was inherited from the old version. Looks like it's been a long time since I tried using it on disabled script, otherwise, I might have remembered. But, my memory is not something to rely on...

It's because the previous Options page wasn't really that interesting to look at - It was basically reserved for a niche use. The one I'm offering is a lot more handy, you'd basically use it a lot more, which made you notice this particular mechanism. I guess that's a sign of me doing something so right, which I sometimes need to see these signs.

Off-topic:
As for the development of uBO, this is probably the most tedious and mundane thing I have ever engaged in my entire life. Dealing with an extension that has a total of 25.000+ lines of code, all by myself, is insane, not to mention that I have to deal with so many APIs that doesn't have an exact equivalent, forcing me into scenarios that is equivalent to performing a brain surgery, but instead of using a scalpel, I'll be using a butcher knife.

I'm still not certain about the timeframe of when to expect a usable version of the extension, since I'm still connecting every API of the extension to its XUL variant, (As of right now, I'm tackling with the dynamic element blocking and the URL redirection mechanism of the extension) I'm still predicting that it'll take months for it to be released in an alpha stage, and then another month of testing (I'll be making a thread, inviting everyone to contribute into the stabilization of the extension, through testing and PRs), and then I'll be updating it, everytime there's a new version that was officially released by Gorhill.

Patience is the most important trait that I'll be asking from everyone here. (Which I did notice that everyone here do have it, whether if it's voluntarily or involuntarily)