siria

Only a little bit better as adding ten prefs one by one, would be your original first approach to this preflist project: add them as a little list at the end of the profile prefs.js, while the browser is closed, then restart. Or there's always user.js, which enforces prefs at every startup, but that my be too restrictive. What would be interesting, where do the 'automatic' values come from? By the way, would like to share a general idea for all people using their own pref lists. Would you sometimes like to see in about:config little comments, what some of the prefs and values are about? Since awhile I'm very happily adding self-written info-prefs :-) Just a few examples, not perfect: pref("security.tls.version.__INFO", "INFO: FF23+(KM7X) 0=SSL3, 1=TLS 1.0, 2=1.1, 3=1.2 since FF24, 4=1.3 beta"); pref("security.tls.version.__INFO2", "INFO: check available versions on about:support. TLS1.3 needs min NSS 3.3"); pref("toolkit.telemetry.__INFO", "INFO: Prefs NOT about collecting, only about SENDING! See profiler pref"); pref("profiler.enabled__INFO", "INFO: COLLECT data or not: Telemetry prefs only decide if they are SEND"); pref("dom.messageChannel.enabled__INFO", "INFO: for user identity / reCaptcha not clickable if false"); pref("dom.serviceWorkers.enabled__INFO", "INFO: MarioNET module for remote control (since FF44)"); pref("security.fileuri.strict_origin_policy__INFO","INFO: fileuri/checkloaduri: If websites can load resource-links. Check on browserleaks.com/Firefox");

KG76 on Win2000 sounds great! Just curious: your browser language is english, true? can you open other xul windows? For example the error console? about:config? about.addons? Or other entry pages of F2 preferences? example: chrome://kmprefs/content/pref-kmacros.xul chrome://kmprefs/content/pref.xul?kmacros chrome://kmprefs/content/pref-appearance.xul

It's always a dilemma trying to reorganise something after such a long time, already or almost too late, instead of considering future problems right from the beginning. Have no easy solution either, just wanna mention two little points: If I see it right, the single topics have no subforum key in their URL? That would mean externally stored links keep working, regardless if topics are later moved around to other subforums (RT browsers? Mozilla browsers? Whatever? Back and forth across forum?) The most important thing is just to have separate topics at all. And not breaking stored links is especially important for those Help-Support links of course. Not sure if you discovered already one can just open the forum with this very handy link, named "All Activity", and it shows all recent posts? https://msfn.org/board/discover/ RT is already posting in a variety of different topics across the forums, that looks like he's simply watching "all" too, not just "monitoring single topics" (which would be a pain of course)

Instead of this big melting pot it would be SO much handier to have single topics for single browsers, as others have already mentioned too 8-) Have also just posted something over at the K-Meleon forum, regarding KG74 crashes on 98SE and KernelEx (http://kmeleonbrowser.org/forum/read.php?19,146040,page=4), just because there is a dedicated KG74 topic. While here on MSFN it's shattered a bit everywhere, across several topics containing a multitude of different browsers, completely confusing. Although would have preferred here, far more dev experts around here.

Regarding addon archives, aside from CAA and legacycollector, this one is still important too: https://addons.thunderbird.net/en-US/seamonkey/ A clone of old AMO, but only thunderbird and seamonkey addons. At least those Firefox addons which were compatible with Seamonkey too are still preserved there. Sadly that was only a small minority, but still useful. When doing a search for "Firefox" over 1200 addons show up: https://addons.thunderbird.net/en-US/seamonkey/search/?q=firefox Have some doubts about the usability of that search function, so the art will be to FIND something, but anyway. The addons are still complete with screenshots, reviews, and it tells which old addon version works in which browser version. Just example: https://addons.thunderbird.net/en-US/seamonkey/addon/httpfox/

@Gansangriff Retrozilla is Firefox2 or 3.6 or similar old Seamonky - really extremely old. I understand K-Meleon is a bit too 'special' for most users, but you mentioned you've used it already in the past. Did you try already roytam's KM-Goanna76.2? Has same engine as NewMoon27, but due to the KM shell it's supposed to be lighter on resources. And I think he managed to make it also suitable for non-SEE machines... He also made a version KM-Goanna74, for Win2000, regarding engine age perhaps somewhere in the middle between Retrozilla and KG76.

Thinking about it, just in theory, another way of including addons out-of-box is probably in the template folder for brandnew profiles: installdir/browser/defaults/profile/extensions/... Then it should show a Remove/Uninstall button on aboutaddons, but haven't tested.

Can only speak from very limited experience with older browsers, but K-Meleon has an addon included out-of-7z-box: NewsFox, an rss-reader. Technically it looks quite easy to me, just place an xpi (with it's final name) in folder /browser/extensions. The killer catch is, users will get NO Remove-button on aboutaddons, as if that folder is considered part of the engine. Reminds me of android phones, where owners are only allowed to remove their self-installed apps too, others can only be disabled. Of course such engine addons can still be removed too, provided you have full access to the app's install folder and can manually delete the xpi - unless that has changed in more modern browsers. Not sure. At any rate including addons this way is rather un-friendly on users who do not want a specific heavy or intrusive addon. So I would not want to see something as NoScript hardcoded in a browser, it's not everyone's cup of tea. But would like some other, basic ones included, like ExExceptions. And in the special case of KM find it important that the old, traditional NewsFox addon comes already included. It's a very tiny and harmless addon which adds basic functions, but most of all it's a demonstration of a working xpi addon in a browser that's so confusing to newbie users, regarding the extensions chaos (macros, complex multi-file KM-extensions, native FF addons etc.) For example out of box KM still doesn't even have any menu entry to open about:addons! And other important about-pages, users must already know those pages exist and can be opened by manually typing the about-addy in the urlbar, which I find completely incredible today. Or users who know about it, can install my tiny KM-macro aboutabout, which just adds a bunch of about-links in a menu. Still looking very rough, because I haven't investigated yet the matching menu positions and names in FF&Co, which is the final goal of course. That KM-GUI prob has historical reasons of course, xpi-addons were completely impossible prior to first KM74 versions, and at first very tricky to install (editing install.rdf and fiddling with prefs). Then slowly getting better with every new KM7x-version. And since KM76RC2 most Firefox-addons install quite fine, but still lack any xpi-created menus and toolbar buttons, rendering most of them useless again. The only chance is if the xpi comes with an own options page, as long as that's enough to handle it. Or if the user can get an additional KM-macro to create menu or buttons, but their interaction with addons is still quite limited too. How to call a native xpi-function by macro? All they can do so far is toggle some pref, or open a xul-url (Like ExExceptions). I've realized only lately they may be able to do a bit more too. Anway, it's a major pity that due to chronical lack of devs K-Meleon's GUI is meanwhile lagging some ten years behind the engine. But what I find very important in general, for all browsers which can only run 'legacy' XUL-addons, is to give clueless newbie users a hint about ClassicAddonsArchive! This addon I'd absolutely include out-of-box, except that it's impossible because this one is far too heavy, over 40MB. No go. Still, to help unexperienced users, I'm currently working at a K-Meleon macro that modifies the original aboutaddons page and injects a button opening CAA (and other buttons to KM macro ressources, and a little buttonmenu). Realized only lately that's even possible, just by macro with JS and for non-devs like me, still quite excited. When that macro is installed, it will inject those buttons at every page load, and clicking it will open "caa:list" or "caa:about", and if not yet installed the button will offer to download the addon from github. Of course, for other browsers too, with some dev-power and omni.ja-access, such modifications could be included in the source-code of aboutaddons page directly. If anyone is curious about how that might look, here's a little preview screenshot of my almost-finished macro: http://s000.tinyupload.com/?file_id=20610227332941181284

Your mistake is to use the 9x version (=no unicode), which is extremely old and outdated. Just use the modern one in all systems.

It hurts a bit that some usually very great people here have such extremely onesided black&white views, and don't even consider for a second that things might possibly have other angles too. In this case there's just clearly an elephant in the living room (or rather a duck, it looks like a duck, it walks like it, it has 'duck' written all over it, etc). But it won't go away just by insisting it wouldn't exist. And neither by calling everyone who sees it a moron. And even consider them super morons just because the first person who complained about the elephant-duck was a horrible person, and insist yet harder that there's absolutely NO elephant in the living room. And if people continue to mention it, to accuse them of blind obedience to that horrible guy. But the elephant is there, and as long as problems are denied they will only grow worse.

Yep, of course they should go into an own new file. Like newmoon.js or whatever, name can be freely chosen. @Mcinwwl: I'm all for automation too if possible. Sorry that I mentioned exchanging the file in the final zip, that was misleading and rather meant to just show how harmless those files are. Or even if done that way, that copy process could certainly be automaticed too by skilled people. But what I originally meant was just to add that new file in the same place where the other sibling files are coming from too. Those sure are included automatically too. The only thing that makes me not 100% sure is if possibly any checksums or whatever may have to match, no clue about such stuff.

If overriding omni prefs with external pref files doesn't work, there's something wrong. Perhaps the folder path?? Try both locations, the ancient and the new one? Many years ago in Firefox the path for defaults was changed from "Firefox/defaults/pref" to "Firefox/browser/defaults/preferences". By the way the same structure as just seen inside omni.ja Yet here in the forum it keeps me riddling that still the old path gets recommended over and over, but then again, who knows. And meanwhile saw that actually Palemoon builds etc. still do come with the old path in the zip. And quite obviously, so many experienced people here who know 100x more than myself would long since have noticed if the old path wouldn't work anymore! But since now you're saying the external overrides don't work, here's a quick theory: What if perhaps, who knows, the browser still considers both paths as valid, but if there's conflicting content, the values in the newer default path get priority? Regardless if inside omni.ja or outside?

No not before every delivery. Just once. Putting the new file into the secret hiding place ;-) where the other independant non-compiled files in prefs folder are coming from too. Those are surely not manually copied every single time either. If the original code gets changed, it will probably get exchanged in the forks too. Then all own fixes are lost if they were embedded deep in the source, and the issue must be investigated again and the fix applied again, or rather gets just forgotten. To me looks like more work not less. Provided of course the fixes are as harmless as exchanging the support URLs in a prefs file. Of course I'm mighty glad of roytams immense work too, it blows my mind, my own browsing depends on him, and basically a single person has to 'save the world' (xp world) in his spare time ;-) No idea how he manages that, but sad enough for the state of the world today. Still just saying that I find it so extremely out of proportion, that a workload of 1000:1 for two people to reach the same goal is today considered as normal. And even as desirable. The prob is that other people are usually not bored to death either, what everyone seems to assume, and have to struggle for their own little spare time. So comparing a minute for a one-time action of copying a file, with the act of learning github, setting up an account, copying a giant mass of files, learning howt to edit and etc. from scratch, it's just so extremely... oh well, not my prob :) (It's just that I'm too forced again and again to waste endless struggling time with stuff that experts could do with a fingersnip, but just don't care, in all areas of life)

Hmm... but what makes this so hard to understand, seen from the outside (zero clue of confusing source/dev/compiling/github stuff): in the final product there are some pref files hidden inside omni.ja, which has internally the same folder structure, but there are also some pref files freely accessible outside, in the defaults/pref or browser/defaults/preferences folder. Those I can't find inside the omni's, no duplicates. Especially K-Meleon has several files, but NewMoon at least one. They must come from somewhere too? And especially, not being embedded anywhere, and their content not refering any dll's or exe's etc, they look like they don't have much to do with 'compiling', and it would be very easy to just add those in some simpler way - like just drag-drop them there in the final zip? And in that defaults folder they override any hidden prefs in the omni's, so wouldn't matter if those still contain other pref values.

For such stuff I simply unzip the 2 omnis and do a text search inside. Instant hit: palemoon.js in browser/omni.ja/defaults/preferences. But wouldn't it be a lot easier to just create a separate little prefs file in browser/defaults/preferences, as was already suggested? But perhaps I'm getting something wrong...

Github: Ouf, you scared me there, but just tried and relieved to have still reading access. With any of roytam's builds, tried KG74 and retrozilla/FF2 with faking IE7. Just need to block styles. Of course that's just for reading plain stuff, other actions may be broken.

No idea if UA is the culprit or the browser version, but the page loads elements from various sites, not just facebook.com. The video itself comes from "fbcdn.net", but then again, the scripts which load it probably matter more. Not sure where those are located in that endless code jungle, but lots of stuff is also loaded from "akamaihd.net". And of course a list of some 20 other domains, which look like ad providers. Sometimes a general UA override instead of single sites makes testing easier. But the few FF-addons I've looked at closer didn't allow this, and they overrule the native engine's UA handling.

Just for fun, this page also opens in ancient KM1.6 (Firefox3.5), which has max TLS1.0 (as was reported already) When killing CSS-stylesheets or blocking before load (either site setting, or global pref permissions.default.stylesheet = INT = 2) it even becomes very well readable ;-)

FONTS with special characters for win98se: a must have are SYMBOLA and UNIDINGS from here: http://users.teilar.gr/~g1951d/ Tons of additional characters, incl. emojis in Symbola, yet bearable filesize. Frankly their latin looks horrible, but doesn't matter because they are not used as main font. The browser only uses their special characters if no other font contains them :-) Have read this pref matters for exotic stuff, someone used it to get rid of "colored emojis" by declaring a simpler font: font.name-list.serif.x-unicode (mine is set to "Microsoft Sans Serif, Segoe UI Emoji, Symbola, OpenSansEmoji" - only as syntax example) Have struggled a lot with that exotic font stuff every once in a while, and last year with emojis due to instagram, but meanwhile forgotten details. The few other emoji-fonts I found had nicer looking icons, but just too many characters missing. Working in 98 are also "Source Sans Pro" (but no cyrillic) and "Source Code Pro", from github "adobe-fonts". Others I installed too were "Segoe UI Emoji" and "OpenSansEmoji" But another huge prob is simply file SIZE! IIRC Arial Unicode was the most perfect and most complete package, just FAR TOO HUGE for old machines with tiny RAM. And a MUST HAVE TOOL for looking up missing characters and compare different font looks: BABELMAP :) Just great. My version on 98se is older, 8.0.0.2, because at the time the newer version 9 didn't work anymore on 98. But when I checked again last year even the NEWEST version was working again! Just sticking to my old one because it fits all my needs and must save space.

Yeah on this old computer I always set JS off anyway, except if absolutely needed. Mostly for security, but it's also near impossible, freezing very quickly. Yeah have tried Fx36-TLS and it runs, but my prob is it's Firefox not KM, that means no macros, can do almost no tweaking with it. ExExceptions is a great and tiny addon for editing permissions.sqlite, for managing domain exceptions for elements, like JS-files, css-files, images, objects etc. It's just important to know that those domain exceptions work bottom-up (element src domain matters) not top-down (urlbar-domain). Oh well. An old version from 2013 is already contained in KG74, in menu Tools>ExExPermission (other name due to a slight modification for KM, but still called ExExceptions in extensions folder and prefs). Personally am using a slightly updated version, but just verified now the original one. First it didn't start at all, then added in .../k-meleon/chrome.manifest this line: manifest extensions/extensions.manifest Now it starts but seems to behave like my usual version too, the window opens (xul page), but then seems like frozen, no edits possible. Oops... and now it suddenly started working!! After exchanging it again with my newer version (xpi in subfolder /browser/extensions), just in another unzipped folder. Guess the prob was on my end, sorry!

KG76 doesn't even run on XP SP2 without OS tweaks, if you got even this far on 98SE that's really sensational!

@ABCDEF: verify that you really have set KernelEx compat to Win2000? The settings get lost after renaming a file or folder path. Not that bad here (P3, 256mb). Depending on quality needs of course. My occasional little youtube videos in 320p size work fine in MPClassic, no stuttering at all. Just of course more or less fuzzy, but so far okay for my needs. Haven't tried bigger sizes yet because the worse issue is download traffic and disk space. But KG74 (Win2k browser) is far from being a main browser for 98SE too yet, far too buggy GUI. Aside from crashing all the time with old KernelEx16, even stuff like the ExExceptions GUI has some strange prob: the xul page opens and looks fine first, but then isn't usable somehow. Similar happened with the errorconsole, but now works again. Probably also due to some system prob here. Anyway, hope this will be better one day with a newer KernelEx. But for NOW I'm really in need of a K-Meleon 1.6 or 1.7 (FF3.5/3.6) with TLS1.2, it's an extreme pain having to open second browsers for half the web pages just because they don't want the ciphers! :(

I love his builds too, and am very glad and grateful for them, but to tell the truth: it really is very misleading to use the very same browser name for the forks and even identic version numbers as the original ('upstream') browsers. In the download filename, the unzipped folder name, the exe name, the profile folders, and if even everywhere inside the browser too... Same browser name and identic version numbers - no chance to NOT confuse. Nearly every normal user will have no chance to realize those are completely different builds. In the case of PM the main prob is the identical browser name, frankly not surprising that the (still very active) original devs don't like it at all, regardless any disputable other aspects. And all file- and foldernames still ARE identic. But it's actually a similar prob with K-Meleon. Here not the name, only the old version number. Nearly all KM-fans incl. the original dev do welcome roytam's updated builds very much, considering the original development is almost dead (again). His forks are happily adopted as 'almost-official' successors, with their engine years ahead of the original branch. Great! So when can it finally be announced as official stable new KM-build?... is what most of us keep wishing, incl. me, considering so many people seem to even look only at 'official stable' builds. (Well okay, the old GUI is in dire need of updates and fixes too, but no matter how easy it's not going to happen, so everyone just ignores that) Anyway, for KM the prob is only the identic version number as the much older original builds, KM76 and 74. Even the ori dev had once suggested KM77 for the goanna-fork, before vanishing again. But no chance, it was still kept "76.0" for plenty of new updates, just like the old gecko builds from 2016. Very misleading, worlds apart. Although no one except me has ever expressed any concern about that, quite the opposite, although everyone to this day is still riddling which build new forum users may mean when saying they use "KM76". 2016 or 2019?? Doesn't matter, no one cares, as long as at least the engine gets direly needed updates... I've even been kicked and called 'highly unfair' or such for requesting a different version number. But the builds must be distinguished somehow anyway, so there were always half-hearted attempts to call the forks "K-Meleon-Goanna", short KM-Goanna or KMG or KG, and Goanna is even part of the download name too. But not of the exe name, not the folder names, not inside etc, and that suffix gets overlooked and forgotten so easily, not to mention lazyness and cluelessness. So am very glad that meanwhile at least the main version, KM76, has evolved from 76.0 to 76.2. Finally it can be distinguished again by version number! And doesn't need that bothersome name suffix anymore. Although this much newer engine and the switch from gecko to goanna would have deserved at least 77.0 from the beginning. Retrozilla too: same prob with confusable builds. There are now 2 versions "2.2" out there, and no one knows what another poster is really talking about when mentioning "retrozilla 2.2". Funnily in this case roytam's unofficial build had the advanced number first, and the ori dev published his own "2.2" build much later. No wonder users are now completely confused - and the original dev was quite surprised too when being told there's already another "2.2" out there... (although it was posted and discussed in his main thread here, just awhile earlier). And the previous version, what has been considered roytam's "retrozilla 2.1" here on msfn (download name "rzbrowser"), is actually just a firefox, not the seamonkey suite of original retrozilla - which exists as a 2.1 version too (I think... but am really floating too, not following non-KM browsers too closely)

Great! Such a file is exactly what I had in mind. Very handy for users. And also how I'd like roytam1 to include the out-of-box UA's, instead of hidden away deep inside omni.ja, where almost no one can find them, let alone figure out how to delete one. (and in newer browsers hidden even deeper as earlier versions, as I learned in this topic). As additional suggestion, if you like, to include your description above, along with a link to here.

Thanks Mathwiz, have updated above. Am not quite up-to-date with newest builds, usually just focussing on KM-Goanna, with KG76 having the PM27 engine inside. Now downloaded NM28 too and unzipped it. So they have hidden those site-prefs yet deeper inside, sigh. And other newer browsers don't contain them at all anymore? Good to know.