Working on a Greasemonkey fork for Pale Moon

[moonbat]

Especially given the current fashion of having a bazillion tabs open all the time.

[back2themoon]

Off-topic:

There are still A LOT of design choices of the extension that I have to decide on, including:
...just like it was intended and how the original developer wanted it to be...

Since the original developer wants absolutely nothing to do with any "Legacy" version, I think this should be the least of your worries. If anything, the more you distance your fork (name included) from the original developer, the happier he'd be (I assume). It is really a non-issue.

As for the rest, it certainly feels like you already know what the best path is: exploit THIS platform's strengths avoiding extra, unnecessary maintenance where possible i.e. don't make this more difficult than it already is.

Of course, if you can use good part of the work being done on the current uBO then it'd make sense not to ignore it.

[sinfulosd]

...I also can't help but think if you're already making a complicated extension, the difficulty of restartless aspect might be blown out of proportion.

In case if you don't know, uBlock Origin was not developed by the original developer (Gorhil) alone - even when he forked it to "uBlock Origin", he was still getting help from a team of developers and some contributors.

Secondly, developing uBlock Origin in a restartless fashion on Pale Moon/UXP platform would be a lot more complicated, since you'll be dealing with memory leaks, zombie compartments, race conditions, etc... Developing it on WebExtensions, on the other hand, it:

• Runs in a separate, sandboxed JavaScript environment with no direct access to browser chrome.

• Uses a declarative manifest (manifest.json) where the browser itself manages lifecycle, event registration, and resource cleanup.

• Has limited, well-defined APIs — it can’t overlay XUL, register XPCOM components, or touch internal objects.

• is automatically torn down by the browser when disabled/uninstalled, with no way for the extension to leave dangling references in the main process.

In other words, you'll be manually unhooking everything, when developing it in a restartless bootstrapped, but in WebExtension, the platform itself cleans up any memory leak and it actually encourage you with this development method.

If someone were to develop an extension as big as uBlock Origin on Pale Moon, they would be spending 3x the effort of what was spent on the upstream version, if they were to develop it in restartless fashion on UXP-based browsers.

In my opinion, it's much preferable to balance in making an extension complicated, but simple in installation, or have only one function, but offering the convenience of not having to restart the browser just to unlock this one function.

[sinfulosd]

Since the original developer wants absolutely nothing to do with any "Legacy" version, I think this should be the least of your worries. If anything, the more you distance your fork (name included) from the original developer, the happier he'd be (I assume). It is really a non-issue.

Yeah, it would not make any sense at all if someone were to develop an extension, called "uBlock Origin" when it's not from the original developer, nor did he even endorse it.

Yup, this adds more overhead in the development of the extension on Pale Moon. I'm starting to feel more pessimistic of the development of such complicated extension already.

[Falna]

Yeah, it would not make any sense at all if someone were to develop an extension, called "uBlock Origin" when it's not from the original developer, nor did he even endorse it.

Yup, this adds more overhead in the development of the extension on Pale Moon.

Maybe I've missed your point, but just give it another name? adBlock Moon / sBlock / BlockIt / etc...

[Nigaikaze]

but just give it another name? adBlock Moon / sBlock / BlockIt / etc...

MoonBlock.

[sinfulosd]

Maybe I've missed your point, but just give it another name? adBlock Moon / sBlock / BlockIt / etc...

I'd have to think of a name, come up with a extension logo, depending on how much I'll be diverging from the upstream version, I might have to come up with a wiki page for it, etc...

Too much hassle for dear old me. If it was up to me, I'd much rather handle the back-end of the extension, rather than dealing with the UI.

MoonBlock.

This is something you'd expect from a core Pale Moon developer deciding to create an exclusive content blocker for Pale Moon, not from some guy who wants a functional upstream version of an extension to work on another platform. Plus, I don't really like the name - what does it even mean, is the extension supposed to block moonlight?!

[back2themoon]

Off-topic:

Yup, this adds more overhead in the development of the extension on Pale Moon. I'm starting to feel more pessimistic of the development of such complicated extension already.

Maybe I've missed your point, but just give it another name? adBlock Moon / sBlock / BlockIt / etc...

Absolutely no reason for more overhead/pessimism here. It does look like you missed this point, which is... it doesn't matter whether you follow previous, original patterns... or not.

As for the name, I still prefer someone's older suggestion for JustBlock, as a tribute to JustOff. In any case, the name is totally up to you. You could always create a poll if you wish.

[UCyborg]

Please do, the fork we have currently is moving slow as molasses.

Off-topic:
It's...standing still.

I have these rare sort of manic periods when I'm able to stay focused on one particular thing for a while...but it wanes.

Working on uBO is incredibly time consuming, incredibly mundane, incredibly boring and incredibly frustrating.

And honestly, I'm very tired from just trying to keep myself afloat. As if reasons above weren't enough, being constantly tired from work, never truly able to re-charge doesn't help.

Consider current fork stopgap solution until something better arrives (if ever).

[andyprough]

Maybe I've missed your point, but just give it another name? adBlock Moon / sBlock / BlockIt / etc...

I'd have to think of a name, come up with a extension logo, depending on how much I'll be diverging from the upstream version, I might have to come up with a wiki page for it, etc...

Too much hassle for dear old me. If it was up to me, I'd much rather handle the back-end of the extension, rather than dealing with the UI.

Two thoughts:

1) gorhill has already put his stamp of approval on "uBlock-for-firefox-legacy", which others have forked without incident, not just UCyborg and JustOff. Could this simply be the most advanced of the uBlock-for-firefox-legacy forks? Seems like it could live in that space for a bit if it makes technical sense.
2) If not, you could still just handle the back-end of the extension, roll it out as a kind of basic beta with no particular new UI or naming or logo or wiki work, and then some of our creative users could possibly jump in with ideas for pull requests to fill in the gaps. Then it could be a team project, with different contributors focusing on their area of talent and creativity.

[athenian200]

2) If not, you could still just handle the back-end of the extension, roll it out as a kind of basic beta with no particular new UI or naming or logo or wiki work, and then some of our creative users could possibly jump in with ideas for pull requests to fill in the gaps. Then it could be a team project, with different contributors focusing on their area of talent and creativity.

This is a really good idea, and actually what I did for Epyrus. I didn't come up with the name, logo, or branding myself... other people in the community came up with those and gave them to me to use for my project. I'm sure the same could be done here.

[frostknight]

MoonBlock.

If Moonchild is okay with this, I am 100% for it.

[Gemmaugr]

Since we already have ηMatrix, what about ηBlock Origin?

[sinfulosd]

Off-topic:
I think I have decided on the design choices and what will happen with the project:

• The extension will remain restartless - it turns out that the extension has to be restartless, because it's too dynamic to be an overlay one - Filter lists reload, dynamic rules toggle, per-tab counters update constantly. The extension mutates every single second and the overlay method won't really make sense with it.

• The UI will resemble how it currently look like on Pale Moon ("legacy" look); I have tested the chrome-like look on Pale Moon and it didn't look in-place at all, especially with other extensions in use. However, it'll have the same QoL features that exist on the upstream version, i.e. Dark mode, "Uncloak canonical names", etc...

• The extension will keep using HTML files; It's not a secret that I would need contributors to help in the development of the extension, and redesigning the UI to be completely in XUL files would alienate anyone below the age of 35. Also, Having the UI made in XUL would give us some advantages, like native menulists/checkboxes, automatic theme inheritance, native scrollbars, slightly better keyboard nav, but the cost is enormous, especially with designing something like the logger and I also don't think that XUL has '<input type="text">' equivalent that supports CodeMirror and the filter editors need CodeMirror. So we'd end up with a hybrid XUL-shell-around-HTML-editor anyway. Maybe it'll be something we'd reconsider in the future, but for now, we just want the upstream to be ported to even have a working one in the first place.

• The extension can diverge from the upstream version a bit - the original developer himself have the Firefox version diverged a bit from Chrome, because Firefox simply offered a bit more features to use. Going with that logic, we could also utilize XPCOM's more permissive environment in the extension's good use. The divergence won't happen in the blocking engine at all, this is the main selling point of the extension. The divergence will happen in other corners of the extension, making it have cleaner code - I was thinking of adding some features that couldn't exist in the upstream version, like skipping compression to have faster startup, use native DNS to uncloak CNAME faster, use 'nsIChannelEventSink' directly to avoid rate-limiting mechanism that exist on the upstream version, etc...

After thinking of the names that can be used for the extension, I like @andyprough 's suggestion - I might just borrow the same naming scheme of my other extension and just call this one "uBlock for UXP" it signals the divergence from the upstream version, while keeping the main selling point of using uBlock Origin's engine, which everyone knows it's the best content blocker engine on the internet right now.

Now, depending on how much help am I gonna get, this extension might finish its development in 1-3 months or in a year - I'll be documenting everything that I can through the forum and through my GitHub repo of the extension. I encourage all the help and PRs that can be added into the extension - I don't assume this project to be all mine or I'll be the one taking all the credit for, if I'm gonna get all the help that I can get to accelerate the development.

I'm documenting the changes and design choices, so that atleast if someone were to ever take my place in the development of this extension, they wouldn't start from scratch and would be aligned with the original design choices or maybe think of superior choices to replace mine. I of course kindly ask to not be pressured into the development and the maintenance of the extension, since not only it's the biggest project that can ever be taken on this platform, but I also maintain another extremely important extension as well.

I figured I'd also post some sneak-peak into the development of the extension: The first screenshot, I just added a temporary placeholder name, until I settle with a main one. The second screenshot shows a total of 328,401 network filters ＋ 103,592 cosmetic filters, instead of the current data of 166,628 network filters ＋ 42,609 cosmetic filters from uCyborg's fork of 1.16.6.1

[Enobarbous]

Edit: Nevermind, I just decided to release 3.7.0 as a stable release instead of making a second edition of the beta release, since I haven't really made risky changes and the first beta access had no issues with anyone using it.

Let's hope that it is indeed stable and won't introduce any new bugs - fingers crossed

Well, now I kind of regret not having had a chance to test the beta version, because I have a few comments for 3.7.0 (tested on pm 34.2.2)

1) If PM is open in a window less than 1320px wide, part of the content on the add-ons page overflows - pic

1-less-1320px.png

This is due to the size of the greasemonkey-sort-bar panel after adding new elements.
It's worse if the localized version is used (and that's without translating new text; words in Russian and many other languages ​​are longer than in English) - pic

1-ru.png

I would suggest either making the panel two rows, or creating two panels: keep the sorting panel at the top, and move "new user script" and so on to a new panel at the bottom of the view-port.

2) There are a few issues with the new "Options" window:
- I saw in the code that you tried to fix the problem of content overflowing the window edges when lines are too long, but it doesn't seem to have worked - here's what I get for the test example - pics

2.png

3.png

- The "Pages" section should be renamed to "User pages" or something similar - to more clearly indicate that it's not part of the original script;
- The "disabled this script rules and only use..." checkbox should be moved from the "Script-declarated" section to the "Pages" section - this would make more sense from a UI perspective;
- In the "Script-declared" section, the lists of sites for which the script is enabled are too narrow - any domain longer than 5 characters is simply truncated, and you have to hover over each line to get information that should be available at a glance; - pic

4.png

3) If I understand the idea of ​​the new "Options" window correctly, it's designed to provide all the important information about a script without opening the code, right? If so, I'd suggest moving the "Page" section to a new tab, like "Value", since it's not part of the script's basic information, but rather extends or replaces it.

4) I would like to ask you to move the text "gm-recover-orphans" to the DTD. Regardless of how rarely this link is likely to appear (I saw it three times during testing), leaving untranslatable text in the interface doesn't feel right.

Is that everything? I have a couple more feature requests, but those can wait.
Oh, one more quick question - are you planning any text updates in the extension anytime soon, or can I create a PR with the translation update?

And thank you so much for taking on greasemonkey support. Even though I made some changes to my local copy, every time I've had to make a major change, I've looked at this pile of disparate code and given up.

Off-topic:

Off-topic:
I think I have decided on the design choices and what will happen with the project:

• The UI will resemble how it currently look like on Pale Moon ("legacy" look); I have tested the chrome-like look on Pale Moon and it didn't look in-place at all, especially with other extensions in use. However, it'll have the same QoL features that exist on the upstream version, i.e. Dark mode, "Uncloak canonical names", etc...

Can I offer a few thoughts? I'm using a style to slightly change the ublock interface - pic

5.png

There are really only two changes:
- The window background isn’t pure white - it looks a little better with the default PM theme and much better with a dark theme;
- the icons are more contrasting - I don't know who decided that monotone gray-on-white/gray-on-gray icons are easy to read, but they were very, *very* wrong...
And yes, I realize it looks pretty similar to ublock in Chrome, but I really didn’t copy it

of course kindly ask to not be pressured into the development and the maintenance of the extension, since not only it's the biggest project that can ever be taken on this platform, but I also maintain another extremely important extension as well.

Just ignore us) Since the current version of ublock legacy can't be called completely broken, you have no reason to rush.

[sinfulosd]

Edit: Nevermind, I just decided to release 3.7.0 as a stable release instead of making a second edition of the beta release, since I haven't really made risky changes and the first beta access had no issues with anyone using it.

Let's hope that it is indeed stable and won't introduce any new bugs - fingers crossed

Well, now I kind of regret not having had a chance to test the beta version, because I have a few comments for 3.7.0 (tested on pm 34.2.2)

I would've definitely wanted to hear your feedback, before releasing 3.7.0 as a stable release, but it's okay - the issues you are mentioning I was already thinking of refining them anyways.

I was thinking of removing "Get user scripts" label that does nothing but taking you to a webpage, and maybe make the "New User Script" label behave like the one that exist on Violentmonkey, Giving you the choice of either going to Greasyfork or OpenUserJS, or create a userscript on your own - possibly shortening the label to just "New...". This will be one of the main steps that I will be taking onto the next stable release of the extension.

I will also see if there's something that can be done with the new search bar that I introduced that, despite it makes a big difference, but the UI could use a bit more refinement (I didn't bother much with the UI refinement as I was more busy in shipping the main feature anyways - I was tackling with the per-script option redesign, during that period anyways).

I would suggest either making the panel two rows, or creating two panels: keep the sorting panel at the top, and move "new user script" and so on to a new panel at the bottom of the view-port.

That is an option that I may experiment with it and see what would be more suitable to go with - Although I'm a bit skeptical on making the panel in two rows, possibly making the page look a bit...bulky.

2) There are a few issues with the new "Options" window:
- I saw in the code that you tried to fix the problem of content overflowing the window edges when lines are too long, but it doesn't seem to have worked - here's what I get for the test example

Honestly, that was the one mechanism where I was having a hard time the most in designing. I might just accept the defeat and just put a scroll-side at the bottom, in case if that issue were to happen.

- The "Pages" section should be renamed to "User pages" or something similar - to more clearly indicate that it's not part of the original script;
- The "disabled this script rules and only use..." checkbox should be moved from the "Script-declarated" section to the "Pages" section - this would make more sense from a UI perspective;
- In the "Script-declared" section, the lists of sites for which the script is enabled are too narrow - any domain longer than 5 characters is simply truncated, and you have to hover over each line to get information that should be available at a glance;

Will do these changes, since what you said do make sense. And yes, I am aware of the domains in the "Scriot-declared" section being too narrow, I decided to add a tooltip for them, but I guess this is not a clean-design approach and I should just try not to compact everything in one place and just make tabs for each.

4) I would like to ask you to move the text "gm-recover-orphans" to the DTD. Regardless of how rarely this link is likely to appear (I saw it three times during testing), leaving untranslatable text in the interface doesn't feel right.

I added this mechanism as a last-second-feature before releasing the extension, because it was an issue that I was facing and I figured that a lot of others might face it as well and they wouldn't know. Wait, you've seen it three times?! Whelp, I guess I have to do something about it now, since I never thought it would be this common - I only thought it'll appear like once every new version or something.

Is that everything? I have a couple more feature requests, but those can wait.
Oh, one more quick question - are you planning any text updates in the extension anytime soon, or can I create a PR with the translation update?

Feature requests are also welcome into the extension and I would much rather for every single point you'd have or anyone that have for me to just type them all to me - I'm not really fond of releasing a new version of the extension every week and would much rather fix as much as I can in one release and then release a new version, when necessary, every couple of weeks or something.

I am indeed planning some text updates. You are more than welcome to keep up with the updates on the GitHub repo and I'd be incredibly grateful for any contribution that would both make the extension better and give the contributor more comfortability in contributing more in the extension as time goes on.

And thank you so much for taking on greasemonkey support. Even though I made some changes to my local copy, every time I've had to make a major change, I've looked at this pile of disparate code and given up.

Every single person said that about this black-box of a source code (Myself included), and honestly, if it wasn't for my no-secret usage of Claude explaining to me the architecture of the source code, I would've also gave up or took a lot more time in developing my own fork of it. The good news is, now that I've changed the architecture of the extension, it should be MUCH easier to read, encouraging the people to contribute into the extension.


I'll finish my IRL tasks and then I'll continue working on a new version of Greasemonkey for UXP. I'll be adding your feedback on a notepad of mine and I'll tackle these features, once I'm free to do so. Again, make sure to write all of your feedback, either on this forum post or my GitHub "Issues" tab and I'll keep having them on a note to tackle them later.

[Enobarbous]

...and maybe make the "New User Script" label behave like the one that exist on Violentmonkey, Giving you the choice of either going to Greasyfork or OpenUserJS, or create a userscript on your own - possibly shortening the label to just "New..."

I also considered the drop-down menu option, but I think it adds an unnecessary step. In my opinion, it’s better to just remove the "get user script" button (and the corresponding items in the Greasemonkey button’s drop-down menu) and include a list of sites where scripts can be found in the readme. If we start listing every possible script source site in the UI, where will we stop?

Although I'm a bit skeptical on making the panel in two rows, possibly making the page look a bit...bulky.

This is just a quick prototype, so...
The 2-row panel really doesn't look very good. - pic

3.png

But the 2 panels don't look that bad. - pic

4.png

2) There are a few issues with the new "Options" window:
- I saw in the code that you tried to fix the problem of content overflowing the window edges when lines are too long, but it doesn't seem to have worked - here's what I get for the test example

Honestly, that was the one mechanism where I was having a hard time the most in designing. I might just accept the defeat and just put a scroll-side at the bottom, in case if that issue were to happen.

There's no need to make such sacrifices Just trust llm less - it's enough to change

Code: Select all

.prefs-meta-value {
  width: 0;
  min-width: 0;
}

on

Code: Select all

.prefs-meta-value {
  min-width: 1px;
}

pic

0.png

In xul, when attempting to set an element's size to 0/0px, the value resets to "auto". flex hacks rarely work correctly with -moz-box.
Alternatively, you can simply avoid setting "flex=1" for the <description> element - you have a hard-coded window size that cannot be changed, and manually calculating the width isn't that difficult.
Also, you don’t need to use <window> for #greasemonkey-script-preferences. You can use <dialog> and set the window size via css (as is done for #greasemonkey in install.css)

...and I should just try not to compact everything in one place and just make tabs for each.

Again, here's a quick prototype - pic's

1.png

2.png

I think it looks pretty good, and we can add other features to the "User Preferences" tab if desired.

Feature requests are also welcome into the extension and I would much rather for every single point you'd have or anyone that have for me to just type them all to me - I'm not really fond of releasing a new version of the extension every week and would much rather fix as much as I can in one release and then release a new version, when necessary, every couple of weeks or something.

Alright, I'll try to gather my thoughts and my edits together into a coherent proposal in a couple of days ))

[sinfulosd]

I also considered the drop-down menu option, but I think it adds an unnecessary step. In my opinion, it’s better to just remove the "get user script" button (and the corresponding items in the Greasemonkey button’s drop-down menu) and include a list of sites where scripts can be found in the readme.

It won't really be an unnecessary step, it would actually be a lot more convenient for people to just browse through the about:addons page to click at the drop-down menu to access any of the 3 websites to install any script they want (Gist/GitHub, Greasyfork, and OpenUserJS). If someone just want to jump straight ahead into creating their own userscript, they could just do it through the extension toolbar's drop-down menu and click "New User Script..." right away, just like how it is designed on Violentmonkey and Tampermonkey.

If we start listing every possible script source site in the UI, where will we stop?

The "every possible script source site" are only 2, right now. (GitHub doesn't really count - it just hosts many projects, including userscripts) being the most popular one is Greasyfork. I don't see anyone creating an entire website to host userscript database that would rival Greasyfork anytime soon.

But the 2 panels don't look that bad.

They both do not sit well with me, to be honest. I don't know if it's because I'm not used to that UI or because my browser window is bigger than 1320px wide, but the majority of the userscript manager audience do not have to compromise, if their window is able to fit that many labels. However, I do agree that the current page looks to be a bit crowded and I am hoping that the changes that I've mentioned would free up some space. I'll still look for some more alternatives that I could introduce into the extension - I'm thinking of adding some preferences that would enable/disable some functions that the users may or may not need, maybe you could utilize that in decluttering the page UI. I could also make the page behave differently, depending on how few the pixels are (which in this case could be lower than 1320px) - I'll see what I can do and which one looks more pleasant in the eyes.

There's no need to make such sacrifices Just trust llm less.
...In xul, when attempting to set an element's size to 0/0px, the value resets to "auto". flex hacks rarely work correctly with -moz-box.
Alternatively, you can simply avoid setting "flex=1" for the <description> element - you have a hard-coded window size that cannot be changed, and manually calculating the width isn't that difficult.
Also, you don’t need to use <window> for #greasemonkey-script-preferences. You can use <dialog> and set the window size via css (as is done for #greasemonkey in install.css)

Wow...It was that simple. I legit had to get the AI's help, since XUL development is my weakest point, turns out to be the AI's weak point as well. 😅
I do wanna thank you so much for helping me in the UI development of them - Would love to see further contributions from you as well.

I think it looks pretty good, and we can add other features to the "User Preferences" tab if desired.

It does look very good and functional. Will use that interface.

Alright, I'll try to gather my thoughts and my edits together into a coherent proposal in a couple of days ))

Absolutely, I already love the ones you've suggested. My GitHub repo is already easily reachable through the extension's Homepage, and I would love to hear the features that you are about to write to me (Bonus point if you'll be able to do pull requests to some of them to insure their implementation - the source code is much easier to read now that I've changed the architecture a bit). I'll be working on some other features that I originally wanted to add into the extension, in the meantime.

[sinfulosd]

Decided to show you guys a sneak peak of 3.8.0 that has some features introduced in it, including a reorganized per-script option page, adding userscript-hosting websites for navigating to them right away, and more

Screenshot 2026-06-05 014747.png

A video of the sneak peak can be seen here

I can't wait to show you guys what I've been working on, especially with the install dialog showing more information than what the old fork was showing.

[andyprough]

A video of the sneak peak can be seen here

Looks awesome!!