Firefox 24 - 52 for ME and 98

[siria]

schwups said:

I already tried different skins and I also disabled individual and all macro extensions and KM plugins month ago.

Ah pity, that was my best hope

schwups said:

The KM reader gave an "? in rhombus", WordPad shows a square instead of c on ME, but Notepad++ a c. Perhaps something like that could cause the converting problem.

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
.

Edited October 26, 2020 by siria

[schwups]

8 hours ago, siria said:

And those 2 other errors in your screen about "undefined macro" also mean something wrong with main.kmm

The rectangles are in lines 226, 348, 456, 550, 663 and 796. The main.kmm of 75.0 isn't affected.

[siria]

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

[schwups]

KM76: I still haven't caught the culprit or have a workaround to make the sub menus and context menus readable. Siria, I have to deal with the language change again, basically I had the same or very similar results.

I tested OMTC (offmainthreadcomposition) disabled on FF 45 and 48. It solved the UI glitch, that the window is not completely displayed or not at all in the case FF48 and these versions seem to run stable in contrast to FF35. The downside is that some web pages are not displaying correctly or are blank. FF 48 doesn't have the boolean "layers.offmainthreadcomposition.enabled" anymore. I created a new "layers.offmainthreadcomposition.force-disabled;true".

Edited November 1, 2020 by schwups

[schwups]

The old bool "layers.offmainthreadcomposition.force-basic" = true is better than "layers.offmainthreadcomposition.force-disabled" = false. Thereby it's possible to start and run Firefox 48 with a slightly reduced window size without this UI glitch. Besides that all pages are usually displayed correctly and there aren't any blank ones.

[schwups]

FF48: I dared to go one step further. I set "layers.acceleration.force-enabled" to true, "layers.offmainthreadcomposition.force-basic" to false and "layers.offmainthreadcomposition.enabled" to true. It completely solved the main UI glitch now, and surprisingly FF seems to run stable. Now the troubleshooting page "about:support" gives "Compositing = Direct3D 9" instead of Basic. What remains are common icon glitches and here and there slightly shifted or coloured edges. But that was already the case before.

[schwups]

Additional requirements for FF 42 - 48 and KM 76: Dll's from XPSP2 or SP3 (or ReactOS) (Activeds.dll, adsldpc.dll, apphelp.dll, authz.dll, dbghlp.dll, dnsapi.dll, mprapi.dll, netrap.dll, netui0.dll, netui1.dll, ntdsapi.dll, ntlanman.dll, rasdlg.dll, rasman.dll, regapi.dll, rtutils.dll, samlib.dll, utildll.dll, w32topl.dll, winscard.dll, winsta.dll), MDAC2.8SP1 (Odbc32.dll, Odbcbcp.dll), GDIPlus.dll (for KM76) and Kext (latest Kstub823, ini file here). The names of all missing files were found with the DependencyWalker (DW). To do this open the Xul.dll with the DW. Missing modules are marked with a question mark in yellow circle. To get all names you must refresh or restart DW after adding files. New (missing) files will appear. The new files bring up new dependencies. You have to repeat the procedure several times. I have these files, XPSP2/SP3 and some from ReactOS 0.4.0, in the system folder. You also can try to paste them in the KernelEx folder, or KernelEx Subfolders like ROS, as KernelEx-KnownDll's. In this case (KernelEx-KnownDll's) is the registry entry in the Key [HKEY_LOCAL_MACHINE\SOFTWARE\KernelEx\KnownDLLs] necessary. Or paste them into the program folder, when you're afraid.

To bear in mind pdh.dll, psapi.dll, userenv.dll, uxtheme.dll and wtsapi32.dll are already supported by KernelEX (KernelEX-KnownDll's).

Don't merge LZDLL_ME.reg or LZDLL.reg for Win98 of KernelEx update18 into the registry! Firefox will crash immediately on start .

The portable Installer requires the apphelp.dll. It make sense to install the WindowsInstaller 12.0.2600.2, but I haven't testet it as requirement.

 Direct3D9 (OMTC):

1. Install DirectX 9c

2. "layers.acceleration.force-enabled" => true  -  OMTC requires hardware acceleration!

3. "layers.offmainthreadcomposition.enabled" => true (default value)

I did all the tests with the portable versions and I only testet with NV7800GT and NV7900GS cards and drivers 82.16 and 82.69 on WinME This may not work with other hardware.

Edited June 14, 2021 by schwups

[schwups]

Note: I can't enable hardware acceleration for KM76. That is possible with FF only.

[tyukok]

On 11/12/2020 at 7:29 PM, schwups said:

Additional requirements for FF 42 - 48 and KM 76: Dll's from XPSP2 or SP3 (or ReactOS) (Activeds.dll, adsldpc.dll, apphlp.dll, authz.dll, dbghlp.dll, dnsapi.dll, mprapi.dll, netrap.dll, netui0.dll, netui1.dll, ntdsapi.dll, ntlanman.dll, rasdlg.dll, rasman.dll, regapi.dll, rtutils.dll, samlib.dll, utildll.dll, w32topl.dll, winscard.dll, winsta.dll), MDAC2.8SP1 (Odbc32.dll, Odbcbcp.dll), GDIPlus.dll (for KM76) and Kext (ini file here). The names of all missing files were found with the DependencyWalker (DW). To do this open the Xul.dll with the DW. Missing modules are marked with a question mark in yellow circle. To get all names you must start DW several times. I have these files, XPSP2/SP3 and some from ReactOS 0.4.0, in the system folder. You also can try to paste them in the KernelEx folder, or KernelEx Subfolders like ROS, as KernelEx-KnownDll's. In this case (KernelEx-KnownDll's) is the registry entry in the Key [HKEY_LOCAL_MACHINE\SOFTWARE\KernelEx\KnownDLLs] necessary. Or paste them into the program folder, when you're afraid.

To bear in mind pdh.dll, psapi.dll, userenv.dll, uxtheme.dll and wtsapi32.dll are already supported by KernelEX (KernelEX-KnownDll's).

The portable Installer requires the apphlp.dll. It make sense to install the WindowsInstaller 12.0.2600.2, but I haven't testet it as requirement.

 Direct3D9 (OMTC):

1. Install DirectX 9c

2. "layers.acceleration.force-enabled" => true  -  OMTC requires hardware acceleration!

3. "layers.offmainthreadcomposition.enabled" => true

I did all the tests with the portable versions and I only testet with NV7800GT and NV7900GS cards and drivers 82.16 and 82.69 on WinME This may not work with other hardware.

I took all these DLLs from XP SP3, put them in System folder, put Kexstubs.ini in KernelEx folder (and changed Kstub822 to Kexstubs in core.ini, along with renaming Kstub822.dll to Kexstubs.dll). Installed FF48 portable, set firefox.exe and xul.dll to XP SP2 compatibility mode, but it doesn't start when I try to run it. No crash report, nothing.

What am I doing wrong?

[schwups]

1. Make sure you have latest KernelEx Core Updates (24) installed.

2. Verify Kexstubs with jumpers Ktree. Latest is Kstub823.dll The Kexstubs entry must be in the core.ini:

--- No OS override ---

[BASE]
contents=Kexstubs,std,kexbasen,kexbases
Kstub824
desc=Base enhancements (api fixes + extensions)

--- Legacy modes for older registry settings and Ktree9 ---

[DCFG1]
inherit=BASE
contents=Kexstubs,std,kexbasen,kexbases
desc=Legacy Base enhancements

 

3. Does FF 35 work on your machine?

4. Try FF 45.9 or 47.02. FF48 starts without UI first. Can you see it in the taskbar?

5. Check with the DependencyWalker, if you caught all dll's.

 

Edited November 23, 2020 by schwups

[tyukok]

50 minutes ago, schwups said:

Verify Kexstubs with jumpers Ktree. Latest is Kstub823.dll

Looks like that was the culprit - I was using Kstub822.dll. Replaced it, now FF48 runs fine. Thanks!

[schwups]

Congratulations! Thanks for testing. Do you have hardware acceleration and OMTC enabled? What's your hardware and OS??

Edited November 23, 2020 by schwups

[tyukok]

52 minutes ago, schwups said:

Congratulations! Thanks for testing. Do you have hardware acceleration and OMTC enabled? What's your hardware and OS??

Yes, hardware acceleration and OMTC are enabled. I edited prefs.js to have them enabled by default and the UI glitch was gone.

I'm using Windows 98 SE and the graphics card is GeForce 6200LE PCIe with official 81.98 drivers.

[cc333]

I haven't been super active here for awhile, but I have been following, and I must say that I'm impressed that Firefox 4x runs now!

This would therefore allow roytam1's New Moon 27 (based on Palemoon 27, which I believe is in turn loosely based on Firefox 3x.x) and Nightly Firefox 45 with SSE1 support, both of which are actively maintained and much more up to date than any other browser KernelEx is capable of running.

New Moon 28 (based on FF 52, I think) is probably a step too far, but it's a lot closer to being possible than it ever has before!

c

[siria]

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.