Proposed patches/features for Pale Moon

[dinosaur]

Greetings,

Here are a few patches I'm using for my custom builds of Pale Moon and that, I think, could benefit others...

• palemoon-25.0.0-oss.patch.gz

  Native OSS v4 support for Linux. This patch adds native support for OSS sound devices, in excess of ALSA & Co.

  (2.54 KiB) Downloaded 59 times

• palemoon-25.0.0-torification.patch.gz

  TOR-browser alike features (use the attached custom button to toggle TOR on/off). Based off the TOR-browser v24 ESR code.

  (54.48 KiB) Downloaded 65 times

• TORtoggle_url.txt

  This is the button URL for use with the Custom Button extension in order to toggle the TOR mode on/off

  (50.73 KiB) Downloaded 65 times

• palemoon-24.6.2-clear_buttons.patch.gz

  Adds clear buttons to the Search input and Find input lines, under Linux only.

  (1.5 KiB) Downloaded 47 times

Notes:

• I made the TORification patch out of the last Firefox 24 ESR based version of the TOR browser. The idea behind this patch is *not* to make Pale Moon into a true TOR browser (in particular, the functions that prevent letting traces of your browsing on your hard drive are either not implemented or not enabled), but to empower Pale Moon with the same ability to anonymize your browsing (via TOR) and prevent finger-printing and tracking (especially when the TOR mode is on) from the website you visit. When the TOR mode is off (which is the default mode), the patch lets Pale Moon behave as usual (with a few exceptions, such as an added canvas permission drop-down when sites try to use canvas for tracking you). The TOR mode toggling relies on the toggling of many different settings, which the TORtoggle Custom Button takes care about. That button toggles TOR on, TOR on with plugins disabled and TOR off, the three modes being toggled in sequence (at each click on the button).
• I am not the author of the OSS patch (I adapted it from a patch for Firefox that I found on the OSS support forum, itself being borrowed from a Firefox mailing list or such, but it's MPL anyway).
• The clear buttons patch only affects Linux builds (it won't change a thing for other OSes builds), but it's a life savior for genuine UNIXers who love using the "primary selection" (mouse-select text to copy and middle mouse button to paste) copy/paste function.
• The three patches apply cleanly (without rejects) to the current Pale Moon sources (v25.3.1), even though they were "diffed" from older versions.

[squarefractal]

I would like to see (1) applied to upstream.

The others... they're interesting. (4) could be done as an extension, though.

[dark_moon]

I didn't use TOR nor Linux but i like to see that a user make patches to improve Pale Moon.
Good work!

[Moonchild]

Unfortunately I can't apply the patches - please make sure you supply patches as git-style patches, or do a git checkout yourself and create a pull request?

The 1st patch is a no-brainer, I'd like that. the clear buttons under Linux would be something to consider as well, although if actually UI-intrusive it would need to be behind a pref -- as I do not want to favor the use of "primary" clipboard operation without an easy way to switch off the extra UI elements that are pointless otherwise.

The torification patch however is problematic: it's too specific to your own desires and workflow to be generally applicable -- mostly because it combines several things, some of which are potentially desired but others are not. The canvas control switch is a good addition and interesting to consider, but linking it to TOR operation is certainly not wanted. The canvas stuff would be something for me to look at but is currently not easy to separate from the other things done in the patch.

[dinosaur]

Unfortunately I can't apply the patches

It's dead easy. From inside the sources (or a working copy of the sources tree of you git repository), type:

Code: Select all

zcat path_to_patch/whatever_patch.gz | patch -p1 -s

Then commit the patched sources tree back to your online repository.

please make sure you supply patches as git-style patches

I supply patches like I always supplied all my contributions, for decades, in dozens of Open Source projects... It never was an issue so far. This is also how patches are submitted to the Linux kernel, for example... or in any Open Source software mailing list...

the clear buttons under Linux would be something to consider as well, although if actually UI-intrusive it would need to be behind a pref -- as I do not want to favor the use of "primary" clipboard operation without an easy way to switch off the extra UI elements that are pointless otherwise.

It's not pointless, even if you don't use the primary selection (which would be surprising for a genuine UNIXer not to use, since its' way faster than Copy/Paste). But it's up to you.

The torification patch however is problematic: it's too specific to your own desires and workflow to be generally applicable -- mostly because it combines several things, some of which are potentially desired but others are not. The canvas control switch is a good addition and interesting to consider, but linking it to TOR operation is certainly not wanted.

The canvas drop-down is not "linked" to the TOR mode (it works without any need for enabling the "TOR mode"). If you look at the code for the TORtoggle custom button, it will also show you that all features are actually switched on and off via settings (the TOR route itself being setup via the proxy settings). But, again, it's up to you... Just keep in mind that the changes do not modify the way Pale Moon currently works until toggled on (by TORtoggle or via about:config).

The canvas stuff would be something for me to look at but is currently not easy to separate from the other things done in the patch.

Just a matter of searching for "canvas" in the patch file, and you'll quickly find out what files need to be changed and how.

[squarefractal]

Code: Select all

zcat path_to_patch/whatever_patch.gz | patch -p1 -s

That won't work for Moonchild, since mozilla-build doesn't have zcat. Instead use:

Code: Select all

gzip -dc path/to/patch.gz | patch -p1 -s

[Moonchild]

I supply patches like I always supplied all my contributions, for decades, in dozens of Open Source projects... It never was an issue so far.

Well, I guess I work a little different than most OS projects you've contributed to thus far, then.
I'll figure it out, though. I think the difference is that I tend not to patch from the command line unless I HAVE to (and in this case I HAVE to ;P ) but rather from GUI Git tools who don't seem to like your patch output.

which would be surprising for a genuine UNIXer not to use

You're probably right, but there aren't many "genuine UNIXers" using Pale Moon.
A lot of people on Linux these days are coming from Windows, who are used to copy/paste.
I think people likely don't need a control to clear the field, because selecting the field contents with a focus click is default behavior, and any way of pasting text (either middle-mouse or keyboard paste or context menu) would automatically overwrite the selected text. It would therefore be a specific user preference to have these controls or not, and as such should be behind a pref.

As an aside: I myself would certainly be slower using primary than using the clipboard copy/paste, if for nothing else than that clicking the mousewheel without inadvertently scrolling it is difficult and requires a lot of dexterity and motion accuracy if most of the mice marketed are too small for your hands...

Just a matter of searching for "canvas" in the patch file, and you'll quickly find out what files need to be changed and how.

If I had nothing better to do than to actually having to search through patch files and mentally separating out what is one and what is the other, I'd be fine with it -- but for someone who did not write the patches, this requires going through all code and understanding what is done to which file, and what is needed and what is not if only one half of the functionality is desired. Your patch is 228KB of text -- I am NOT going to plow through all of that, sorry. Please separate the TOR stuff from the non-TOR stuff.

patch -p1 -s

I'll skip the -s, thanks. I prefer to see what is done.

EDIT: OSS patch applied and committed now. Thanks.

[dinosaur]

which would be surprising for a genuine UNIXer not to use

You're probably right, but there aren't many "genuine UNIXers" using Pale Moon.
A lot of people on Linux these days are coming from Windows, who are used to copy/paste.

Come on... There are more genuine UNIXers using Linux than there are Windows-exiled-users... Beside, it's a good thing to educate the latter with the "right way" (and more efficient way) of using Linux.

I think people likely don't need a control to clear the field, because selecting the field contents with a focus click is default behavior,

Which is a shame (see below why)... and yes, I also got a patch to revert that bogus default setting to what it originally was in Firefox and older Pale Moon releases...

and any way of pasting text (either middle-mouse or keyboard paste or context menu) would automatically overwrite the selected text.

That's where you are mistaken... With your bogus setting, as soon as you click into the box, the text in there gets selected, which clears the previous "primary selection" and replaces it with the text that is already in the box... I.e., you loose the primary selection you wanted to paste with the middle button.

I really don't understand why you insist on trying to make non-Windows users using Pale Moon under their OS as if it was used under Windows... Linux (and UNICES), MacOS-X, etc, all got specificities, which make up their own strengths and weaknesses, the former being why a specific user will choose an OS over the other... Diversity is a plus, uniformity is boring...

It would therefore be a specific user preference to have these controls or not, and as such should be behind a pref.

Up to you... but don't count on me, sorry.

As an aside: I myself would certainly be slower using primary than using the clipboard copy/paste, if for nothing else than that clicking the mousewheel without inadvertently scrolling it is difficult and requires a lot of dexterity and motion accuracy if most of the mice marketed are too small for your hands...

All my mice got a "stepping" (sorry, not sure what English word to use to say it) wheel, i.e., you can't accidentally turn the wheel while pressing on it, you need to apply enough up/down strength to get past the next "step".

Just a matter of searching for "canvas" in the patch file, and you'll quickly find out what files need to be changed and how.

If I had nothing better to do .../... I am NOT going to plow through all of that, sorry. Please separate the TOR stuff from the non-TOR stuff.

Sorry, I don't have time/motivation to do this either. I published the patches here so that they could be reused by whoever would find them useful, but I'm myself maintaining quite a few large pieces of software (professionally for some and as a hobby for others), and don't have time to dedicate to Pale Moon development (I simply patched it to meet my needs and requirements for my custom builds and I'm now sharing the resulting work: take it or leave it, it's your choice ).

[Antonius32]

PM4Linux users who prefer to use Primary Selection can simply set the preference browser.urlbar.clickSelectsAll to "false", and install one of the following (lightweight) extensions to add "Clear" buttons to the main text fields:

https://addons.mozilla.org/firefox/addon/xclear/

https://addons.mozilla.org/firefox/addon/clear-fields/

Alternatively, the following extension can be installed to clear any text field by rolling the mousewheel over it:

https://addons.mozilla.org/firefox/addon/wheelclear/

Pale Moon. Your browser, Your way

[Moonchild]

@Dinosaur: I appreciate your willingness to share your patches and offer changes, but I don't think we're on the same page as far as what we think should be in the browser. Also, I don't think your opinion about "genuine UNIXers" is shared with the majority - in fact, as the previous poll about this very thing showed, most people preferred Windows-equivalent behavior. Also, I am willing to bet that most Linux users have never seen a mainframe or actually used a UNIX operating system.
Calling automatic text selection "bogus behavior" and your preference "the right way that other should be educated into using" I think is a bit too opinionated and very much trying to further your own workflow preference. Please don't do this. You are obviously capable of tuning it exactly the way you want it and patching the source to make private builds to do exactly what you prefer it to do -- more power to you! I'd even be willing to offer these as a 3rd party contributed build for the "UNIXers out there" if you otherwise not reconfigure the browser, but as-is, these patches will simply not be considered for the main-line, because they do not stroke with the majority of Pale Moon users, even the relatively small Linux user segment, and if you're not willing to make these options configurable in your patches, then it would be enforcing your preference on other users who may likely not share it.

@Antonius: Nice finds! Indeed a good alternative for those who want specific behavior and want the choice to have it work that way, without needing an alternate build.

[dinosaur]

Calling automatic text selection "bogus behavior" and your preference "the right way that other should be educated into using" I think is a bit too opinionated and very much trying to further your own workflow preference.

Like I wrote, several times, in this very thread: "take it or leave it", it's your call, and I personally don't really care (I have my own builds with my own requirements built-in).

So, please, do not put intentions in my contributions that I didn't have in the first place... I'm just sharing my work, and hoping for a better Pale Moon for everyone. But the latter is up to you and your own choice for your own software.

PS: about installing extensions to plug flaws in Pale Moon, it's out of question for me... The very reason I migrated to Pale Moon from Firefox is because, with the latter, half of the extensions I had to install (half of which went unmaintained with time) were to plug flaws and undesirable changes... I don't want to reproduce, with Pale Moon, the nightmare I experienced with Firefox... Thus the patching approach.

[Moonchild]

At the very least leave expressions like one approach being "bogus" out of your "take it or leave it" posts in the future, then.

Even your last post here talks about "plugging flaws in Pale Moon" while they are not flaws, merely not a perfect match to your personal workflow - and you MUST understand that anyone's personal workflow is not necessarily (and likely never will be) the common workflow presented in a public product. You are the one putting intentions in the patches by presenting them the way you do, calling out the browser's current state as flawed and presenting them as ways to "fix" those. Calling them flaws, bogus, "in need of fixing" etc. is something I do take personal and do feel the need to correct you on - because they are not flaws, they are not bogus, and they do not require "fixing". Your personal patches convert one way of working in another -- without making this a user choice (which is what Pale Moon is all about), and it will not better or improve Pale Moon without that choice, exchanging one way of working with another (which on the whole seems to be less desirable for most users).

I will leave it. Thanks again for sharing; maybe some of it can be molded into something useful in the future when there is time to do so.