Which are your preferred prefs.js or user.js settings for KMeleon Goanna? What are they useful for? I think that it would be a good idea to create this list to share their environment and browsing benefits with the current users (and also with the future ones of course). Thanks in advance.

K-Meleon Pro has well-commented file browser\defaults\preferences\kmeleon.js

Quote
rodocop
K-Meleon Pro has well-commented file browser\defaults\preferences\kmeleon.js

Thank you very much @rodocop, very useful preferences!

It has bugged me since awhile that in newer KM-Versions the aboutconfig page does not open with the cursor already in the filterline anymore. Now learned this is just a toggle:

pref "browser.autofocus"
Default is TRUE, which kills the filterline-jump on aboutconfig (?? or not)
It starts working again if set to FALSE (or so it seemed)

(Edit: Sorry, not sure anymore, but now it suddenly works with both settings! Perhaps that had other reasons...)

https://support.mozilla.org/de/questions/1112217
Funnily, this pref shall make the cursor jump into the first INPUT Field automatically. But somehow this pref now conflicts with older focus-command-methods in the normal page code, while instead helping evil ad-scripts to hijack anchor-links.

-----------------
PS:
There are tons of Default Prefs found inside the K-Meleon folder, either in the file "greprefs.js" or "goanna.js". Some prefs have a description. The exact file location depends from the KM-version. Lately it's embedded inside omni.ja, but can easily be unzipped (only a prob on win98, needs newer kernelex for modern 7-zip app)
The current goanna.js contains over 1600 prefs! :O 👀

PROB @roytam + Dorian:
it also contains now the automatic useragent SITE exceptions from Palemoon. Please, if any possible write those into a separate file instead and place it into browser/defaults/preferences.
Those are very shortlived settings and should really not be hardcoded inside omni.ja. This will cause endless probs in the future and make it impossible for 99.99% of users to reset those domains to "default UA" in the future, and they will not even know what hits them



Edited 4 time(s). Last edit at 05/26/2018 05:15AM by siria.

Speaking of default prefs - if I'm not wrong, items related to datareporting can be cleaned up since they are relics of FF.

I unzipped omni.ja that's in KM76Goanna and WoW! I sure would like to have goanna.js in a separate file and placed in browser/defaults/preferences.

Does anyone perceive a problem(s) with doing this?
Not being a programmer myself but, just techie enought to tweak, I just thought
I'd ask.

I have been using the latest KM76Goanna and I've had fun using every KM
browser that's come along.

I truly believe (one day soon I hope) that K-M will be the most used browser
in the world.

Who knows, KM77 just might be that browser



Edited 1 time(s). Last edit at 05/24/2018 05:39AM by Happy.KM.User.

Quote
Happy.KM.User
I unzipped omni.ja that's in KM76Goanna and WoW! I sure would like to have goanna.js in a separate file and placed in browser/defaults/preferences.
Does anyone perceive a problem(s) with doing this?

Woah - but how would you find your own stuff in that mass??
Copying over the whole file is no prob. As far as I know, settings in defaults/preferences have priority, would just try. But it's much handier if this huge file remains in a separate location, with lesser priority.

Quote
Happy.KM.User
I truly believe (one day soon I hope) that K-M will be the most used browser in the world.

Siiiigh, yeah that would be a paradise world. Dream... Too bad reality is exactly the other way around. Just now the big powers are at it again full force, another round trying to get rid of as many small and humanfriendly projects as possible, who don't have enough resources and manpower to handle the exact same monster bureaucracy as the big monopolies. So personally I rather expect the opposite, would be shocked but not surprised if for example this forum vanishes from one day to the next :-(

Hi siria,
I agree it would be handier for goanna.js to have its own home.
I believe I would have to know a bit about programming in order to do the above?

I was looking at the preferences listed all neatly marked and I think just as
long as things stay neat, hopefully there won't be any problems.

Now having a positive attitude about KM being with us and how much longer it will be with us is a matter of the wonderful folks at KM who do the programming.

You've been with KM for a long time and you've seen lots of changes within the community.
I see that maybe it's probably going to always be touch 'n go with KM because there's only so much free time that folks can spare.
The point is that it would be a great loss if KM was no longer around or that no one updated it anymore.

I'm just tickled pink about the terrific job roytam1 is doing.
The first thing I do when I get on the computer on Saturdays is (update my AV)
and then I go to KM76Goanna index and check for the new vesion.

This browser is what I call, a fun browser. It's a pleasure surfing with KM.



Edited 1 time(s). Last edit at 05/26/2018 03:10AM by Happy.KM.User.

Quote
siria
PROB @roytam + Dorian:
it also contains now the automatic useragent SITE exceptions from Palemoon. Please, if any possible write those into a separate file instead and place it into browser/defaults/preferences.
Those are very shortlived settings and should really not be hardcoded inside omni.ja. This will cause endless probs in the future and make it impossible for 99.99% of users to reset those domains to "default UA" in the future, and they will not even know what hits them

it is not quite possible to make site UA overrides out of goanna.js since those entries needs preprocessing in build process.

Quote
roytam1
it is not quite possible to make site UA overrides out of goanna.js since those entries needs preprocessing in build process.

Have no clue about this strange preprocessing, always thought fake UAs are only some lines in a settings file (?), but in this case I'd much prefer a browser without them included.
Adding a single file manually is always a lot easier as trying to tear out something deep embedded, if possible at all. The endless probs in the future, especially for builds that don't get upated anymore like KM74 for Win2000, just aren't worth the minor prob today of adding a file manually. Especially for KM. We've struggled too many years without any chance to get engine stuff fixed, again and again, and your current builds could easily turn out to be the final ones forever...

Quote
siria

Have no clue about this strange preprocessing, always thought fake UAs are only some lines in a settings file (?), but in this case I'd much prefer a browser without them included.

Simply set "general.useragent.site_specific_overrides" to false.

If you want to add manually your site specific overrides leave the above pref active but delete the respective prefs in goanna.js. In this case you'll have to edit goanna.js within omni.ja at each update.



Edited 1 time(s). Last edit at 05/27/2018 01:59PM by Yogi.

Quote
Yogi
If you want to add manually your site specific overrides leave the above pref active but delete the respective prefs in goanna.js. In this case you'll have to edit goanna.js within omni.ja at each update.

This is exactly the crucial problem, that it's embedded and hidden inside omni.ja.
Tearing it out from there is difficult. Advanced users may have no major probs editing this - but provided they first learn about the reason and where to look. Even then I'm not sure if perhaps some manifest or MD5-checks will not interfere in the future. And even advanced users will have a 100x better chance to figure things out themselves if they can find those strings and domains in a normally accessible, separate file.

But normal users have almost no chance at all. Even if they are perseverant, google for the prob, and find this forum and a matching thread (if this forum still exists and is still google-indexed at that time). But now try to tell them here in this forum that they have to hack their omni.ja? Or replace it with a ready-made hacked file by us, hosted somewhere at an external file hoster? I'd say forget it.

But all those probs can simply be avoided by not embedding that file so deeply.

@siria

I'm not aware of problems caused by obsolete site-specific-overrides in goanna.js.
Assuming that such theoretical problems might occur in the future, it could be fixed easily by Roy.

The user could mitigate the problem without hacking omni.ja or even without knowing about the existence of goanna.js.
In "about:config" the string for the respective pref can be emptied or replaced with a new one.

Hi All
Someone embedded gonna.js and hid it in omni.ja so, why can't, say, roytam1 or another coder reverse the process?

Why does this file have to be embedded and hidden in omni.ja or embedded and hidden anywhere as far as that goes?

Can only guess, just as you. Probably for the same reason Mozilla has zipped up essential core functions since many, many years already, into a single jar or ja file. Perhaps it's safer there? Certainly harder to manipulate for unauthorized persons or kids. And zipped content saves diskspace. Perhaps also makes some things faster? And it avoids unnecessary confusion of normal users, confronted with incredible 1.600 settings. Then possibly inspiring some to mess around and -completely clueless- mess up the whole browser. Then crying 'Bug!' in the forums ;-) At any rate it makes the files look simpler and cleaner.

If more advanced users want to play with it, those can still do. Just copy the whole file into the defaults/preferences folder - voila.

Quote
Yogi
I'm not aware of problems caused by obsolete site-specific-overrides in goanna.js

The problem is those sites, usually big and important ones, will break again soon. If they needed UA-fiddling before, chances are high they will need it again, each time with different details.
The second problem is, normal users cannot figure out why those sites don't work anymore. Even if they are aware about useragent tricks and try to fake their global one (as everyone keeps telling them to do), it will not affect those exception-sites. And in KM users will generally not even be aware that a site has an exception, unless they now get that site-properties sheet like Firefox - do they in KM?

Quote
Yogi
Assuming that such theoretical problems might occur in the future, it could be fixed easily by Roy.

No, not in the future. Only today, and probably awhile longer, but it's only a matter of time when he'll vanish too, like Dorian and everyone else. Real Life interferes in countless ways. And additionally, unlike Dorian, K-Meleon is only one of a whole bunch of browser forks for him, not a main priority.
And without a dev, the users are stuck again for years with the last KM version (like myself)
Am not even sure, in case another dev would like to continue, would he even have the last sources to fork?? Dorian had not checked in his latest bugfixes for 76RC when the disk crash and then Windows destroyed them.

Quote
Yogi
The user could mitigate the problem without hacking omni.ja or even without knowing about the existence of goanna.js.
In "about:config" the string for the respective pref can be emptied or replaced with a new one.

Replaced yes, but only with another fake one. Not sure what you mean exactly with "empty it"? If you define a blank space as UA, the web servers will receive just a blank space in the headers too.
What remains impossible is to "reset to default", to delete a pref which is defined inside omni.ja, without editing omni.ja itself.

Quote
siria
Not sure what you mean exactly with "empty it"? If you define a blank space as UA, the web servers will receive just a blank space in the headers too.

Nope. With a blank string the override doesn't work anymore and the server will receive the UA set by the user.



Edited 1 time(s). Last edit at 06/02/2018 01:22PM by Yogi.

Quote
Yogi
@siria

I'm not aware of problems caused by obsolete site-specific-overrides in goanna.js.
Assuming that such theoretical problems might occur in the future, it could be fixed easily by Roy.

The user could mitigate the problem without hacking omni.ja or even without knowing about the existence of goanna.js.
In "about:config" the string for the respective pref can be emptied or replaced with a new one.

but if internal suao fails, reverting to engine's default ua just make situation worse.

Quote
roytam1

but if internal suao fails, reverting to engine's default ua just make situation worse.

Sorry, I don't undesrand the exact meaning of the statement.
Do you mean that if the original site-specific override pref fails, the default UA is worse?
If the original site-specific override pref fails, one can try with custom UserAgents.
As long as the original site-specific override pref is active it overrides at first call (as it should) the UA set by the user.

I have tested several times with custom UA (and also sniffed the outgoing headers) to make sure that it works. It did for me during my tests - at least.
After testing I reverted the override pref to its default. This worked as well.

Quote
Yogi
Nope. With a blank string the override doesn't work anymore and the server will receive the UA set by the user.

You're right - fortunately. That really removes the worst part of the future prob.

Obviously for empty strings the Site-UA behavior is contrary to that of the Global-UA:
"general.useragent.override" = ""
This empty global pref makes that really nothing gets send in the headers.
That pref must be deleted completely, not just emptied, in order to send the native default UA.



Edited 1 time(s). Last edit at 06/02/2018 06:07PM by siria.

Quote
siria

That pref must be deleted completely, not just emptied, in order to send the native default UA.

Can't confirm.

The upper part shows the headers sent to deviantart.com by KM with the default site-specific UA.
The lower part shows the headers sent to deviantart.com by KM after I emptied the original string for that pref.
As you can see KM is sending now its native UA.

(This part of the replay was cut out by the forum software, so I'm adding it now.)

Quote
Yogi
The lower part shows the headers sent to deviantart.com by KM after I emptied the original string for that pref.
As you can see KM is sending now its native UA.

Yes, that's what I confirmed in my previous post.
This is how empty strings work for *site* exceptions.

It's the *global* pref which sends nothing if it has an empty string.



Edited 1 time(s). Last edit at 06/02/2018 08:41PM by siria.