Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Days Won


siria last won the day on June 6

siria had the most liked content!

Community Reputation

56 Excellent

About siria

Profile Information

  • OS
    none specified
  • Country

Recent Profile Visitors

736 profile views
  1. 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/
  2. @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.
  3. 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.
  4. 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
  5. Your mistake is to use the 9x version (=no unicode), which is extremely old and outdated. Just use the modern one in all systems.
  6. 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.
  7. 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.
  8. 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?
  9. 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)
  10. 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.
  11. 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...
  12. 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.
  13. 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.
  14. 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 ;-)
  15. 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,, 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.
  • Create New...