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. 


siria

Member
  • Content Count

    450
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    9

siria last won the day on July 5

siria had the most liked content!

Community Reputation

225 Excellent

1 Follower

About siria

Profile Information

  • OS
    none specified
  • Country

Flags

  • Country Flag

Recent Profile Visitors

2,357 profile views
  1. > Bummer, that's what I was afraid of - I was hoping there was some sort of "conditional child" CSS selector :} Yeah, often run into that prob too, mighty annoying :( But no chance in Mozilla browsers by CSS alone, not even in FF60, as I've read awhile back. While younger Chrome browsers can select parents now by css. But some day I needed it enough to finally help myself with a bit javascript in a KM-macro. IIRC it just adds classNames to certain tr table rows (probably to parent-parent of matching links, collected by document.querySelectorAll(..css..), then css can finally style them. But would rather avoid onload-JS if possible. > Opted for just keeping all rows then elevating z-index to "hide" last-modified and size cell text for ia32, sse, and win64 rows instead. How?
  2. Yeah, mighty impressed too and slightly envious, but without any clue how to repair manually if anything goes wrong, cannot risk such experiments before making a full backup again. Sigh. Some day... tyukok said: > I edited prefs.js to have them enabled by default Just as general hint for everyone since most people are not aware: Changing or adding user prefs on about:config has exactly the same effect as editing file prefs.js manually, but it's much easier, a little bit safer (less syntax-typos), and in most cases a lot faster. Because pref changes on about:config require no restart, except for some prefs which are only read at startup. And changing prefs on aboutconfig will just as well store those in prefs.js When adding a value to file prefs.js manually, with notepad, it will work too, but if it's the same as the default value, don't be surprised if that line has vanished again after closing the browser => same result as directly editing on aboutconfig. No advantage, only more complicated. On the other hand, editing prefs.js manually can be handy for mass-import, to just quickly toss a bunch of own prefs into it, at the end, before starting the browser. As always, the file will be cleaned up automatically (sorted alphabetically, duplicates removed, lines with default values deleted) And if those copied lines are written manually, still containing default-values too, that's even useful before upgrading to a new engine version. Which may contain different default values in omni.ja, which are otherwise silently inherited if previously the user value was the same as "default" (=not stored anywhere) Alternatives are file user.js (prefs can be changed during session, but are restored at next startup, keeps lines with default-values, can contain handy comment lines) Or creating own "browser defaults". Howto: by adding them in a personal file in "(browser)/defaults/preferences/***.js", which overrules default values in omni.ja. Note, those alternative methods use a slightly different syntax in the files, just compare what's already there.
  3. j7n said: > Is there a way, via extension or filter, to stop loading any videos at all? > I want to browse and see comments, but watch > exclusively with SMPlayer Try if that old global blocking pref works for you, for html5 audio+video? permissions.default.media = 1/2/3 (1=allow, 2=block, 3=only same domain) Must be created manually on aboutconfig. And may not work in all browsers, perhaps abolished in youngest engines, but not sure. Site-exceptions are possible, same handling as for images, internally stored in permissions.sqlite (except if changed meanwhile, no idea) There exist a bunch more global blocking prefs "permissions.default.xxxx prefs" since old times (incl. very handy "subdocument" for iframes), but Mozilla kept hiding those, and it's hard to find anything on the web about it. In the past the "object" pref was also handy to block globally all Flash-videos, but not just this, it also blocks (or blocked?) plugin-stuff of all other sorts too, incl pdf etc: permissions.default.object= 1/2/3 But overall media/video/plugin prefs have grown into a vast jungle, and all influencing each other too, it's rather a lottery now. .
  4. Goodmaneuver said: > If you use WinME straight out of the box there is a 32GB limit on USB without updating the USB drivers. > The internal native drivers had this limit that is why I said the SYS files need to be updated in earlier post > but I wanted to change wording a bit on the particular post you have shown as it is not that good. > I tried the early pure ME build and I know that 32GB was the limit but it is not an important issue. I'm on 98SE, and installed a few updates over the years, but not sure anymore which exactly, and no clue what those mean especially for such potentially deadly HDD-size or partition-size limits. Fixed or not? No clue, an abolute killer prob for backups :( My old internal HDDs were partitioned ages ago to 80GB, and those work fine. But I keep reading USB is independent, that special drivers matter. Either drivers on system, or independant drivers in current usb-device firmware... As additional killer prob have read about some deadly BUG when the HDD was partitioned on XP (?) and later used on Vista/Win7 (? not sure anymore about details, would need to look it up again), and guess depending on used tools... I could live with max130GB per partition on one of those giant brandnew USB-HDDs (500mb-2TB), partitioned on a newer system and then used for backups on 98SE, but 32gb is almost nothing. Main riddles: => What happens when writing "too much" to a huge USB-disk?? Which was partitioned with some tool on a NOT updated XP-SP3 or early Vista or Win7? Perhaps data on this complete partition lost? Or possibly even complete HDD with all partitions lost?? => Would I even notice data are lost after writing "too much"? Any error message? Before or only after too late? Or just silently messed, and some data still work, but all 'overflow' will be lost? => Mainly: is there any chance to check *beforehand* if USB-HDD partitions are "too big"?? .
  5. roytam's previous free domains have all expired after a year, now all links are moved to this 5y domain: o.rthost.win @Mods: wonder if perhaps there's a chance for an automatic replacement in forum software, as in KM-forum?
  6. Crashing sites with NM 2020-10-31: In the K-Meleon-Forum a user reported simply changing the useragent fixes the crashes on youtube and facebook: http://kmeleonbrowser.org/forum/read.php?19,153118,153677#msg-153677 (KG76 = engine = NM27) Which makes me wonder if perhaps they boycott certain old systems again...? Unrelated, just in general, wonder if toggling this pref may change anything, perhaps at least no crashes? There were reports in the past it sometimes fixes empty pages (who didn't seem to notice their script didn't fully work since console produced no error, or something like that) javascript.options.strict = true
  7. ATTENTION, next Mozilla Apokalypse already this December - in 4 weeks! Example, such important pages: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Code_snippets https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/ and thousands more. Everything about HOWTO code for pre-FF57 gets now DELETED :-((( I tried to check if Wayback has backups, using a few example pages, but for most found nothing at all. Then tried to guess original version URLs by removing "/Archive/" in URL, but that didn't work either: When Mozilla moved pages to that /Archive/ link, they also changed the rest of the path structure completely :( For example this current page: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Code_snippets contains still an original old link to https://developer.mozilla.org/en-US/docs/Code_snippets/StringView BUT it gets now redirected to: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Code_snippets/StringView_library old URL: docs/Code_snippets/StringView curr URL: docs/Archive/Add-ons/Code_snippets/StringView redirected: docs/Archive/Add-ons/Code_snippets/StringView_library example-2: old URL: docs/Mozilla/Tech/XUL/Attribute/ curr URL: docs/Archive/Mozilla/XUL/Attribute/ Then did a mass check and was first glad to see thousands of archived pages, with or without /Archive/, but at second look most are stoneage, 2009, 2014... And if not knowing the exact URL, that's an almost lost case too. Best would be if anyone gets the wayback team to store https://developer.mozilla.org/en-US/docs/Archive/**** as a complete project again... (Disclaimer: researched this a few weeks ago, after the quoted post above, no idea if perhaps meanwhile things have improved or not) .
  8. K-Meleon Goanna74: Got a bit sidetracked after wanting to do a "quick check" if translation files (utf8) work in KG74 or not.... Found it partly works, though only for the config pages (shortcut F2, translated in *.properties and *.dtd files), not for normal menus (translated in simple *.kml files). But when changing the language and then hitting F2 (config) the first page is already a broken XML page, oh great... All others are fine. No idea if perhaps I've messed it myself when fiddling too deep inside and always copying lots of stuff between versions...? Then just for curiosity, and knowing that KM shell got lots of bugfixes since 2014 and hardly any real additions, had the 'brilliant' idea to look what happens when simply copying over the "de.jar" translation file from latest KMG76. And - it seems to work... at least that XML error on first page is gone... Well possible there's a catch somewhere, lots of files and deep stuff in that jar, but would need more testing (some day...) Also worth trying to copy over more files, but I deeply distrust compatibility of dll-files, so didn't touch. The kml-files would be harmless, but already obvious they don't work :-( Then wanted to switch back to ENGLISH and - CRASH. Aargh.... After restart, browser still keeps the other language. Again, no clue if that's normal or my fiddlings (?), but anyway, closed browser and then manually added this pref in prefs.js: user_pref("general.useragent.locale", "en-US"); Now it started again in english. But hate crashes and don't feel like fiddling every time to repair, so tried to come up with workarounds... Considered adding that pref also in user.js, that enforces EN at every session start. Not sure though if I want that always. Then started struggling with the script in that config page for GUI language (pref-appearance.xul), if there wasn't any way to prevent accidental crashes at least, and finally realized: even just simply setting that EN pref causes already a CRASH! Even when setting it manually on aboutconfig too! Crazy.... Next thought, started drafting a quick macro with a menu toggle, which only sets a marker pref if NEXT session shall start in EN. But when forgetting it and accidentally using F2 again to reset to EN, KM would crash again, grmpf. But hey, why not modify the native SCRIPT to set this macro marker too instead of toggling the real pref? Okay, done, tested - works. But still somehow stupid... aargh.... Isn't here any better way, for getting back to EN during a session?! Best would be to have a english-to-english dummy translation package, to put into a locale folder with some fantasy language, then choosing this one instead of en-US... Oh... actually that exists, as template for translators! Tried the first I found, which was for KM76 again, but who cares, it's just a quick test... and: WORKS! At least no crash anymore when switching to xx language instead of EN Of course, very well possible that causes other grave bugs again, being for KM76, but requires more testing. Later found also a template package for KM74, probably safer. Although on the other hand more OLD bugs in it yet. Oh well, but that was just for curiosity and experimenting, otherwise I use only english GUI anyway. if anyone is bored and feeling adventurous, you can try yourself some day. The locale templates can be downloaded here: http://kmeleonbrowser.org/wiki/Localization
  9. Ah pity, that was my best hope Oh true - WordPad shows it! But ONLY WordPad, weird.... Even MS notepad shows a normal "c". And all of my other editors. Also weird in WordPad, the FONT changes at this point! When zooming the page bigger with CTRL+wheel it's very easy to find. WEIRD x 2: I cannot get rid of it! Impossible to fix with other editors. Can even DELETE the whole line and above and below, save the file, open in WordPad again - and that rectangle is still there, just now moved a bit further down?! WEIRD x 3: Checked main.kmm from other builds: Some show it too, some others not! Also ONLY in WordPad. But even weirder: in different places!? Especially evil: the old original files are OK, but my modified ones all (#), grmpf... Finally figured out: - those which do have that wandering (#), have it all after 8182/8184 letters! - those which do have that wandering (#), are all UTF8, while the OK ones are ANSI!! What a ****.... Current guess: probably just an old-age bug in WordPad? But alarming if your KM complains about it, that means it expects ANSI everywhere...? Definitely shouldn't be. My KM1.6 has zero probs with UTF8, it's the default format for the engine. KG74 seems to work too, mostly, only the title bar messed - much like your menus.... Perhaps some KernelEx setting...? And those 2 other errors in your screen about "undefined macro" also mean something wrong with main.kmm .
  10. ?? When I look inside newest KG76 that line looks perfectly normal: $kLayersOnly=$kLayers*getpref(BOOL,"kmeleon.plugins.layers.catchOpen"); Aside from layers being useless anyway, a relic from the far past before real tabs were possible. And there's no /kplugin/layers.dll contained anymore anyway (but was before my time with KM, know it only from hearsay so not 100% sure if that var can be dropped completely or not.) What I find curious is that you seem to have a different line in main.kmm? And the 2 errors in your screenshot (call to undefined macro) indicate that your main.kmm is either off now, or badly broken, or not loaded as FIRST macro as it should? Perhaps better to do a fresh unzip...? But those little bits sure don't kill the menus so completely. Have slightly higher hopes for the other suggestions in my 3-4 posts above (trying Klassic skin, disabling macros PLUGIN etc)
  11. It's amazing how far you got already with KM76 on 9x/ME! Yeah all I know is KM and especially macros of course, with a bit skin-stuff, but you're the experts for the whole fundamental rest of which I in turn have almost zero clue. So only trying to contribute what little I can from this small knowledge section, although chances are probably low in this case. But who knows? Forgot to mention, may be important: Not even XP SP2 can run K-Meleon76 without deep Kernel tricks, by default it needs min SP3! Unfortunately roytam sees not much hope this could be even fixable :-( Contrary to much advanced engine browsers like MyPal (also some Mozilla type engine), which only needs SP2! What I find amazing/frustrating. Although KM was always praised as special for old systems, this makes me wonder if possibly MyPal may be much easier to get working on 9x as KM. And even with a much younger engine. But no idea. Did anyone try MyPal on 9x/ME already....? schwups said: > After a few weeks it seemed to get stuck in offline mode--maybe a iphlpapi issue...". > At that time I tried to find something in the kmm files that was somehow > noticeable or strange, but without success Yeah that's difficult, if no idea yet where to even start. In such cases first and easiest test would be to just disable one or several macros completely and see if it helps. For debugging the error console is invaluable. There's actually a hidden pref which enables more error info. This is so hidden, it must even be created manually: kmeleon.plugins.macros.debug = true But catch is, IIRC, in KM7x it seems to conflict with the compat75 macro, which it automatically disables. So am not sure which is better or worse.
  12. Next thought: perhaps translated macroinfo lines are a prob now? But can't be: the "MIME Types" macro shows up OK, although it has a translated macroinfo line too: mtypes{ macroinfo=_("Change file type settings"); opennew("chrome://kmprefs/content/pref.xul?filetypes"); - setmenu(Preferences,macro,"MIME T&ypes",mtypes); Weird... weirder... 2x tooltips as menulines?!? And that's in a block of 8-10 almost identic Toggle macros, yet only those 2 look similar? Then noticed something in main.kmm, again almost surely harmless, but for lack of other clues: the parent menu of that whole Toggles-block is defined by $__m=_Privacy_Settings; There should be quotes around the menu name. A little typo, existing since decades without harm. But who knows? Fix anyway, like this: $__m="_Privacy_Settings"; Must be changed in 2 places, same line exists 2x in main.kmm Any change after restart, perhaps at least not using tooltips anymore? ----- What else to possibly test.... though not much hope... Backup file /macros/main.kmm, open original in N++ and "CONVERT" it to UTF8 withOUT BOM Afterwards check what happens if converting that file to ANSI (then convert back to UTF8, as it should normally be) Now running out of ideas... but already far too long and complicated, no one reading anymore.... And wondering: are there more users/testers with Win9x around and able to run KM76...? .
  13. Perhaps later menu-replacements by macro are touchy, I remember early KM7X versions had bad bugs related to such stuff. And would guess extra unstable if single commands get replaced by same-name popup menus... The second menu in photo also has 2 suspicious lines, same mess-name for a popup and a single command... but no clue what this is, probably completely unrelated, as in first menu the identic lines. But do check this: how are looks with Klassic skin? (F2 > GUI) That's the oldest one, and still using old skin configuration. Aside from buttons the skins also define the icons in menus. Yeah I see the icons are correct, but this whole prob isn't logical at all ;-) And check looks after disabling the MACROS plugin completely? (aside from half the menu lines vanishing into nirwana) Perhaps crashes, no idea, since there are now too many macro-commands used everywhere and taken for granted. Looking inside menus.cfg... yep, 3 younger macro-lines don't check anymore if the plugin is enabled or not: Line307: View &History=macros(Places_History) Line596: &Paste And Go=macros(Go_Paste) Line597: &Copy URL=macros(Go_Copy) For testing just put a # at beginning, after making a backup copy of original. ------ Staring riddling at your photo again.... In Privacy menu (last popup in photo): Toggle Images = MESSED Toggle Image Animation = "Togg" is messed, rest of line OK!? That just makes no sense. Hmm.... especially no sense that my KM1.6 menu says: "Block Image Animation" but yours: "????le image animation" Huh? "Toggle" instead of "Block"? And lowercase...? There's something extra fishy... Checking KM76 main.kmm => identic with KM1.6 => setmenu sets visible name as "Block"... Only the tooltip line (macroinfo) reads "Toggle image animation" - huh?! pref_ToggleAnimation{ macroinfo=_("Toggle image animation"); - $__m=_Privacy_Settings; setmenu($__m,macro,"Block Image Ani&mation",pref_ToggleAnimation); SAME effect also at bottom in menu, for "Block Page Co&lors" In your screen-shot reading "????le page colors", that's the tooltip too .
  14. Just as overview: ========== CREATION of "Compact Menu" as in photo: (all lines except 2 macros are created in menus.cfg / ANSI) MESSED: L179 New &Tab=tabNew L181 &New Window=windowNew L208 &Save Page As...=saveAs L149 &Print...=filePrint L151 Page Set&up=filePrintSetup L243 &Edit L288 &View L327 &Tools L125 &Sessions OK: L56 Fu&ll Screen=fullscreen() (KPLUGIN) MESSED: L200 Work O&ffline=navOffline OK: L237 &Manage Profiles...=openManageProfiles L238 Pr&eferences=openPrefs MESSED (2 macros, UTF8B+ANSI): popup menu "C&onfiguration": by main.kmm: setmenu(Preferences,macro,"C&onfiguration",moz_AboutConfig); Then modified by macro cfg.kmm: (replacing command with a same-name popup menu, this might be a bit shaky?) $_cfg="C&onfiguration"; setmenu(Preferences,popup,$_cfg,moz_AboutConfig); setmenu(Preferences,macro,"",moz_AboutConfig); OK (macro ANSI): "MIME T&ypes" created by mtypes.kmm (ANSI): setmenu(Preferences,macro,"MIME T&ypes",mtypes); MESSED: L355 &Help L185 &Close Window=windowClose L186 Exit &K-Meleon=appExit
  15. Cool "screen shot" :D It looks as if the browser thinks those were chinese letters, or letters meant to be displayed with a dingbats fonts or such?! But funnily not all, only 90%. Strange... But that photo gives me a lot of hope! All is visible fine (black font, not transparent), and some lines are FULLY OK! And for the rest only the encoding (ANSI? UTF8? BOM?) is displayed wrong. That hopefully means there's just some setting missing somewhere, or some locale files may need to be converted, or internal files (that could get complicated) or perhaps has to do with your system font, or whatever.... Your browser is set to english, right? Just curious how the same menus would look in DE, if perhaps more lines are messed or less? First thought: Up to KM74 menus were created with "ID-" commands, since KM75 with "modern" names... Both versions should still work. To my huge surprise, just discovered my old KM1.6 can use the "modern" ones too - never would have guessed! So not much hope, but just experimental test anyway: Backup file /browser/defaults/settings/menus.cfg and replace it with version from KM74 (last version with ID-commands) Second idea, although probably useless too: Perhaps try another system default font. Have read that in Win98 native MS Sans Serif can be buggy sometimes with modern apps, Tahoma is supposedly better. Don't know, but a short test can't harm and doesn't even need system restarts (Right-click on Desktop > Properties > Display (Darstellung), SAVE AS... to backup current config, then drop down Elements to "Menu", choose Tahoma, OK, restart browser) Next thought: Tried to figure out some CLUE by your screenshot, if perhaps only macro created lines are messed? Or only native commands? Or only certain macros created by ANSI-files, vs UTF8-files? UTF with/without BOM? But sadly, nothing fits :( Some native commands look OK, others messed, even if both are created in same file (menus.cfg) Likewise, some macro lines messed, others okay, although ANSI (K-Meleon expects UTF-8 for macros) Yeah I know, as long as only latin letters inside it shouldn't matter anyway. It makes especially NO SENSE to me that even extremely simple popup menus like "&Edit" or "&Tools" are messed too :( The "&" at begin can't be culprit, or "&Manage Profiles" would be messed too.... And even simply the length of the names is completely different: "&Sessions" gets about 30 messed letters...?! "&Edit" and "&View" and "&Help" get each about 15 messed letters... AND their 3 lines are even IDENTIC...?! Same amazing effect in the second menu in photo: 2 lines with completely identic mess-names, the upper one a popup menu, and below it a direct command? On the other hand "Set Offline" gets only 4 messed letters, far too short, and "New Window" and "Print..." get both just "????" Most amazing: despite that mess those lines and popup menus still FUNCTION! :O
×
×
  • Create New...