Mathwiz

Thanks! I'll be sure to download the next Serpent 55 update once you post it. Does this affect any other platforms, such as UXP? If so I'll download those too. I looked at the code you linked to, and it looked pretty straightforward. There's a hard-coded list of `bad' ports, and you can add more ports to the list with the network.security.ports.banned pref, and/or remove ports from the list with the network.security.ports.banned.override pref. So it was quite strange that it wouldn't work no matter how I set those prefs!

Thanks, but no dice. There's no network.security.ports.banned pref; yet it refuses to connect, even after I created string pref network.security.ports.banned.override and set it to 50100

Hopefully this will be an easy one for one of the Firefox experts. Trying to learn about the IceApe browser, Serpent (55) gave me this: Apparently Serpent (at least 55) blocks port 50100 for some strange reason, but that's where the IceApe changelog is. Is there a pref to control this? Searching for 50100 in about:config yields nothing....

Interestingly, the profiles are already isolated (I think by accident). 55's are in "%APPDATA%\Moonchild\Basilisk\Profiles", while 52's are in "%APPDATA%\Moonchild Productions\Basilisk\Profiles"! So I think your suggestion about renaming one of the .exe's (for those trying this at home, rename the one that isn't your default browser), is probably the way to pull off the trick. But for non-e10s operations, New Moon 28 suffices, and it gives me the chance to "go retro" with the older UI every so often. BTW, on the topic of FF browser UI's, I think it's mostly a matter of what you've gotten used to. I was a bit annoyed when Mozilla switched FF to the Australis UI, but I'd gotten used to it by the time I got into @roytam1's builds, so I chose Serpent so I could stick with it. Back in the day, I used to use one of Mozilla's very early post-Netscape browsers (I think v1.4!) and that UI lives on in SeaMonkey, BNavigator, etc.

Second that. Or at least a pointer to this forum (if possible)! The recent move of the browser threads from the XP forum to here makes some sense, but it really messes with me catching up on the latest XP news.

I think it depends on the "web dev" in question, what newer feature(s) they're using, and why. If a newer feature adds useful functionality, you can't blame devs for using it! But many of Micro$oft and Google's own sites seem to use as many "new features" as they can cram into a Web page, yet it doesn't make their Web pages better, AFAICS - just less compatible. So I think it's reasonable to infer they're mainly trying to force the use of Chrome/ChrEdge/modern FF and kill off any forks based on older versions. The name of the game is "Monopoly," and Google is clearly winning. As to why M$ is cooperating, here's one possible reason: Given the recent kerfuffle, I'm sure MCP would do the same thing if they had Google's market dominance.

Well, after several weeks of reading, I finally reached the (current) end of "My Browser Builds (Part 3)!" No thanks to the forum software, which reset my "last visited" page to back to page 1 when the thread was moved this week (need an emoji for "mildly irritated" here - "angry" doesn't quite fit). Still rocking Serpent 55 as my main browser, even though it's showing its age. Using New Moon 28 + JustOff's add-ons for GitHub/GitLab (I'd use Serpent 52, but I can't run 52 and 55 at once). Of course very disappointed with some of what I read: MCP bullying @feodor2 into axing MyPal/Centuary and taking the UXP source repo private (now releasing source only with release builds; probably the bare minimum they can get away with under MPL). It does show that all MAT's bluster about "proper branding" was nothing more than an excuse to harass @roytam1, since MyPal followed all his branding rules and still got targeted! (Although if I were to suggest a new name for New Moon at this point, I'd probably go with Uranus, for reasons that should be obvious ) Even though I don't expect to use it much, I grabbed and installed the last MyPal build (thanks, Wayback Machine) out of spite. Also disappointed, but not surprised, with Google playing "Monopoly" and forcing their "Web Components," or whatever their nonsense is called, down all our throats. Why use simple HTML when you can make the Web so complicated it'll bring a quad-core CPU to its knees instead? Main reason Serpent is looking so old these days. Reminds me of Micro$oft's reindeer games from a quarter century or so ago! Haven't started reading the 360EE threads yet, but that'll probably have to be my next task. (Now angry fits ) OTOH, very pleased that @mixit spent so much time finally tracking down and fixing that nettlesome 23-minute (or thereabouts, depending on audio sampling rate, of all things) video playback bug! Even got the fix into the Mozilla code base, even though it's a moot point nowadays. I like that idea - sort of an XP version of Waterfox (yes, I know Waterfox was forked from FF 56) - but I rather doubt it'd help much with the modern Web. I also vaguely recall this being discussed once before, and I think it was said that FF 53 is pretty much the end of the line for XP, which basically gives you Serpent 55. If it could be done, though, it would be compatible with more WebEx add-ons, which is something, at least.

Just read the thread and realized no one answered your question! Firefox was the last major browser to drop Windows XP support. By that time, the last official versions of IE and Chrome for XP were hopelessly outdated, so FF 52.9ESR became the default choice of WinXP users for Web browsing. Then, Moonchild Productions forked a very recent version of FF, 52.6ESR, for their Basilisk browser, and used its UXP engine for the next version of their Pale Moon browser (28). MCP disabled Windows XP support in their forks, but @feodor2 and @roytam1 were able to build XP-compatible versions of both of MCP's browsers. With these, XP users were able to continue browsing the modern Web. For several more years, those browsers were indeed the best choice for Windows XP. Unfortunately, Google is playing "Monopoly" these days, developing new Web "standards" almost daily, that are first supported by new versions of their Chrome browser. Even Micro$oft (no stranger to the game of Monopoly itself) has jumped on the Chrome bandwagon, abandoning both IE and their original Edge browser in favor of a Chromium-based version of Edge. Firefox is the only major browser still using a different engine, but even it looks and feels a lot like a clone of Chrome these days. So today, the UXP-based browsers are starting to show their age. These days, the browser best able to handle the modern Web for Windows XP users is probably 360EE, an XP-compatible Chromium browser developed in China. But the XP-compatible forks of MCP's browsers are still popular, especially with those still trying to resist assimilation into the Goog Apologies for the number of USA-based pop-culture references....

@VistaLover was actually answering a question of mine about a different matter. On Win 7, I noticed one more process than on Win XP, and that was his explanation. That "extra" process will only appear on St 55 on Win 7+. Setting browser.tabs.remote.separateFileUriProcess to true does apply to St 52 as well as 55 and Win XP as well as 7+; it creates an additional process when using file:// URLs to browse HTML on your local PC or network. Probably not a big deal for most folks.

(The following applies to St 55. May be true of St 52 too, but I haven't tested.) I don't know if this was ever answered in this thread, but it seems to work with pref dom.max_script_run_time (default 20). Basically if a script runs for over 20 (or whatever other value you set) seconds, a yellow banner pops up at the top of the window, giving you the option to cancel the script. There's also an option to dismiss the banner, but it'll come back in another 20 seconds if the script still isn't finished. The banner will go away on its own anyway, if the script finishes. If dom.ipc.processHangMonitor is set to false, a dialog box pops up instead of the yellow banner, with the same options. There's also a "don't show this again" checkbox on the dialog box, but it doesn't seem to do anything; the dialog will come back even if you check the box. Doesn't seem to make sense, but that's been my experience. I find both true and false settings annoying, so instead I set dom.max_script_run_time to 0. This seems to be the only way to fully disable it and let long-running scripts finish without interruption. You could instead set it to a larger value, such as 120, instead of 0, depending on your patience for letting long-running scripts finish. Edit: Tried this with Serpent 52, and I had to set both dom.ipc.processHangMonitor to false and dom.max_script_run_time to 0 to let long-running scripts finish. Apparently the latter time limit only applies to the dialog box that comes up if the former is set to false, at least on Serpent 52.

Oh, that's good! Maybe it was just some kind of temporary glitch 7 months ago. I probably should have noticed the amount of time that had passed before making my first post. But at least you got better h.264 video support for FF out of the deal - thanks @grey_rat!

That's an old version of K-Meleon, but I don't think it would hurt to try. Follow the instructions I posted here: If you have any problems just remove the extracted files and you'll be back to normal. If you're using an older browser, I'd guess you have an older PC. Personally, the only thing I've noticed that may be a problem with older PCs is that the patch sets the browser to a frame rate of 120 fps, which may overload slower CPUs on sites with lots of animation. If you have CPU-related issues, try removing layers.offmainthreadcomposition.frame-rate and layout.frame_rate from the .js files with a text editor.

So which videos aren't working now? Oh, now I see 7 months elapsed between those posts, so maybe I should ask, are any videos not working now?

Just download, extract to a drive or folder of your choice, and create a shortcut to palemoon.exe. A couple of suggestions for running it portably: For maximum compatibility with modern web sites, 360EE might be a better choice. Google keeps re-inventing the Internet, Moonchild Productions has had trouble keeping up, and @roytam1's browsers are based on MCP's....

With the Covid-19 pandemic still smoldering, and occasionally flaring up, many of you may be working from home, and using Microsoft's Remote Desktop or something similar to access your work PC. I've been doing that for a year and a half now, although since getting vaccinated I do occasionally go to the office. One major nuisance I kept running into was that, when using any Firefox-derived browser (I generally use @roytam1's Serpent but they were all affected), certain Web sites would freeze Remote Desktop up. The only thing I could do was click to hide the browser window, disconnect, reconnect, and hope that it wouldn't lock back up again as soon as I brought the window back. A very frustrating way to work, and forcing me back to the office more than I'd like. The other day I found a solution. I was in the office, and experimenting with the setting layout.frame_rate in the about:config page. It had somehow gotten set to 240 on my Serpent browser, I think as a result of the "UOC Patch". I reduced that to 60, my monitor's actual refresh rate, and got a noticeable performance improvement at work (where I was not running Remote Desktop, of course). But once back home, I still had problems with Remote Desktop. Apparently too high a setting overloads the Internet connection, causing the desktop to slow down or even stop for long periods. And Remote Desktop has no way to "dump the queue" other than disconnecting and reconnecting. So I decided to try reducing it further. When I went down to about 12, my Remote Desktop problems went away! Animations started looking pretty jerky, though, so I did some more experimentation: in my case, 20 was still too high, but 15 was just right, giving animations that didn't look too jerky without Remote Desktop freezing up. I'm guessing the ideal setting depends on many factors, with the speed of your Internet connection probably being the most important. So if you're in the same situation, you'll need to experiment to find the best setting of layout.frame_rate for your environment.

Github-wc-polyfill seems to work with Serpent 55, at least, although as mentioned in the "Multiprocess Mode" thread, only in single-process mode. (I have a single-process mode profile for just this sort of situation.) And again, you need to modify install.rdf to allow version 52.9 through 55.* to be installed. Edit: Spoke too soon. With GitHub, some things work but several are still broken with Serpent 55. GitLab doesn't really work at all. Same goes for FF 52.9.1 and FF 53.

Yes, I've experienced that myself. I have one tab open that has JavaScript to auto-refresh every 5 minutes; when the auto-refresh happens, certain other tabs will freeze until the refresh completes (on both XP and Win 7!) I guess I just need to stuff in more RAM and bump the process count. BTW (and slightly OT), I found unrelated preferences whose setting can be changed for improved performance: layout.frame_rate and layers.offmainthreadcomposition.frame-rate. The defaults are -1, which AIUI means refresh the screen as fast and often as possible; clearly a waste of CPU if yours can refresh the screen faster than your monitor refreshes! I had mine set to 240; probably a holdover from the "UOC Patch," which wasn't much better for performance than -1! I changed them to my monitor's refresh rate, 60, and got noticeably improved performance on a website that's particularly heavy on "cute" animations (like fading windows in/out, rotating "Please wait" wheels, and the like). I see; the "XP" in the macro is merely a coincidence. I'm sure there's no Mac OS XP or LinuXP! (Probably stands for eXecution Platform or some such nonsense.) It would have made sense to condition the code not just to Windows but to the specific version, since there's no need for the test at all, if the code can only run on Vista+ anyway (think FF 53+); so naturally I thought XP_WIN meant Windows XP; oh, well, you can't win them all.... Luckily, it's irrelevant to the point I was making two years ago, which is that there was code (at least in FF 49) that checked the app.update.channel pref at run time, and disabled e10s if it was set to "release." We were searching for alternative ways to enable e10s, and if for some reason you happen to be running FF 49, changing the update channel pref may work. (I never tried.) But by the time of FF 52 (the basis for all UXP browsers, including St 52, and of course the basis for FF 53, which in turn was the basis for St 55), the app.update.channel pref had no effects other than those which @VistaLover noted in the post I replied to.

I would probably phrase it as, a developer un-crippling newer versions of Flash. It's still Adobe releasing them, but they're region-restricted to only run in China, and of course they have all the China-mandated spyware. Darktohka is stripping all that out so the rest of the world can use the updated (and presumably more secure, although who really knows) versions. But it's still Adobe's copyrighted product, and legally, they have the right to say "no" to what darktohka is doing. You'd think they wouldn't care - if folks are that determined to keep using their free product, why not let them - but maybe they made an agreement with the other members of the "Anti-Flash" consortium (chiefly Google, I suspect) to do everything they can to keep this old, not particularly secure, but popular browser plug-in dead & buried outside of China.

Now that the two of you mention it, that makes sense. Flash v34 is targeted at China, and 360EE is a Chinese browser, so it's reasonable that it allows Flash to run without nags! And of course it's the only remotely recent Chromium-based browser that runs on XP. As some of you are aware, I also use Win 7, which can run "straight" Chromium 87 (but which unfortunately contains the aforementioned nags). I'll check the Win 7 forum for answers, but for some reason, it's not as well-populated with experts as the XP forum.

Thanks @VistaLover. I was out of the loop for a while and just saw that Adobe filed a DMCA take-down against Darktohka. I suspect (s)he will have to find a non-US host to escape the DMCA and keep this project available long-term. Evidently Adobe really doesn't want users outside of China running Flash any more! (cf. my rant at the end of this post): Get 34.0.0.192 from the Wayback Machine while you can; it may become the last Flash version you can get! Link for github-wc-polyfill: https://github.com/JustOff/github-wc-polyfill/releases. Important notes: Version 1.2.8 is now required to access GitLab! Heed @VistaLover's mention of UXP. This is only compatible with modern UXP-based browsers: Pale Moon/New Moon/MyPal 28, Basilisk/Serpent/IceApe 52.9, and SeaMonkey 2.53 (which doesn't work on Win XP). I'm unsure if it can be modified to work on FF 52.9 or Serpent 55, but it doesn't work OOTB. Pretty sure it won't work on other FF-based browsers (e.g. PM/NM 27; FF 45). For New Moon or IceApe, you need to go into the .xpi archive with 7-Zip and modify install.rdf. For New Moon you can just change the existing <em:minVersion> for Pale Moon from 28.14 to 28.10. It will then look like the first code snippet below. For IceApe you can just insert the second code snippet below in its entirety: <!-- New Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.10.0</em:minVersion> <em:maxVersion>29.*</em:maxVersion> </Description> </em:targetApplication> <!-- Iceape-UXP --> <em:targetApplication> <Description> <em:id>{9184b6fe-4a5c-484d-8b4b-efbfccbfb514}</em:id> <em:minVersion>52.0</em:minVersion> <em:maxVersion>52.*</em:maxVersion> </Description> </em:targetApplication> I tried Flash with the last compatible version of Chromium (87, on Win 7). It works, but Chromium really doesn't want you running it! You have to manually enable the extension (and it won't save your preference if you exit the browser), then click the icon of each Flash component on the Web page, then again tell it you're sure you want to run that Flash component! Luckily, the Chromium-based 360EE browser runs Flash without excessive nags, as noted below. Makes sense, as both Flash 34 and 360EE target users in China. I'm unsure of the latest (vanilla) Chromium version that allows "hassle-free" Flash, nor do I know if that version is new enough to be usable on the modern Web. If anyone knows, please educate the rest of us!

Are @mixit still around? They always seemed to come up with fixes for these sorts of issues....

I wonder if Instagram is using a new video codec now (perhaps h.265/hevc/av1)

Yes, that's what he'd have to do: create a new key pair, publish his new public key, and start signing his builds with his new key. Probably not practical to recover the old private key from a crashed SSD; data recovery services are expensive, and there'd be no guarantee of getting it back anyway. And I'm not sure how HK's new government would react to one of its citizens publishing a public key, since it could be used to send him encrypted messages. May not be worth the potential trouble.

Thanks for that! That annoying warning banner comes up almost every time I visit my bank's (Chase) web site, and I've long wanted to get rid of it! Clicking "wait" makes it go away for a few seconds, but it usually comes back before the script is finished. You don't actually have to click on "wait;" once their Javascript finishes downloading whatever info I asked for (e.g., checking account transactions), the banner goes away on its own. It's just annoying to have it pop up every time! Edit: Unfortunately, it didn't work! After a restart, the banner no longer comes up; but a dialog box pops up with the same options. There's a "don't show this again" checkbox, but it doesn't work either. However, I believe I discovered the correct pref to get rid of it for good: set dom.max_script_run_time to 0. That seems to have banished the dialog box for good.

A couple of years ago, I wrote a batch file to download & install @roytam1's browser builds. Surprisingly, it still works - the only thing I had to change was the set domain= line because he had to change his hosting domain name again. One of its features was to verify the signature of the downloaded file using gpg. Needless to say, this throws a big monkey wrench into that feature - there's a lot more to do after verifying the signature than just pausing so you can see the results! I'll give the cmd /c trick a try. Hopefully it will crash just the second invocation of cmd.exe, allowing the first (the one running the batch file) to continue. Might look a bit ugly, but as long as it works.... Edit: Well, looks like it's a moot point anyway; Roytam1 stopped uploading gpg signatures about a year ago. Edit 2: Here's what happened: His SSD crashed.