Mathwiz

I realize you were asking another question, but if interested, instructions to get HTM5 video playback in SM 2.49.5 are here:

Well, SM 2.49.5 (last for XP) doesn't, anyway. You either have to install Adobe Primetime or copy some DLL's from one of @roytam1 browsers. We had a bit of an adventure trying to figure this out in the original (now closed) thread, but we eventually did figure it out, and we now have two ways to play HTML5 videos in SM 2.49.5. Note: That only applies to Windows XP. On newer Windows versions SM 2.49.5 can use WMF to play HTML5 videos, but XP lacks WMF.

Interesting; according to https://www.seamonkey-project.org/releases/legacy SM 2.48 seems to be on par with FF 51, whose JS engine can output SSE2 instructions, so some sites may crash it on your machine. Nevertheless, if you find out that tiled compositing works, let us know!

Which SeaMonkey version do you recommend? If it's 2.49, that would imply Mozilla did eventually fix tiled compositing in at least one UXP browser, so perhaps the fix(es) could be ported to Serpent 52/NM 28. Also, if it works in 2.49, does it work in BNavigator?

Well, there may be a bit of a problem: Gorhill upped the minimum required version to 55 in 1.18: It still runs OK on older versions, but to get it from AMO, you must spoof your FF version number to 55 in the URL (at extensions.update.url and extensions.update.background.url) and user agent (at general.useragent.override.addons.mozilla.org), or AMO won't offer anything past 1.17.4. Then you have to click "See all versions" and scroll down to 1.18.16 (newer versions won't run). It's probably simpler to get uBO from GitHub instead. Next, you need to edit the minimum version requirement down from 55 to the FF/Serpent version you're running. This will invalidate the signature, so you should remove that too, making it an unsigned extension. In FF 52 ESR, you then have to set xpinstall.signatures.required to false to install it. That's the default in @roytam1's builds, so you don't have to worry about that with his builds. (BTW, it's possible to install an unsigned extension in non-ESR FF builds too, but it's trickier: you have to set up some JavaScript to run at browser startup.) Edit: BNavigator is UXP-based too, so the uBO 1.18.16 should work there also, after the usual "surgery" required to install anything on that browser (including removing the signature). One more thing: Serpent 55 is different! Because it identifies as FF 55, you don't need to edit the minimum version, and AMO will offer 1.18.nn, but it will also offer newer versions that won't run! You can get around that by downloading and installing 1.18.16, then spoofing Serpent's version number as 53 so AMO won't keep offering incompatible "upgrades." Finally, after all that, you'll find that a few uBO options are greyed out. Are you really that determined to run 1.18.16? To avoid all this rigamarole, use the latest "legacy" version, 1.16.4.11, and install uBO Updater, which forces the browser to look for uBO updates at GitHub, and to only look for the latest 1.16.4.nn version. No options are greyed out in the legacy version.

You may be right; unlike @roytam1's browsers, stock FF 52 ESR requires something extra, like Adobe Primetime, to decode h.264 videos on XP. But the OP said the problem was only in Instagram. If Facebook/YouTube are working it sounds like he's over the h.264 hurdle already. So, IDK; we'll see what he says, I guess....

A site-specific user agent override should fix that specific issue, letting you at least download add-ons from ATN (though you'll still need to patch them after downloading as @TechnoRelic explained). Go into about:config and create a new string preference general.useragent.override.addons.thunderbird.net and set it to Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5.

Serpent, at least, should have very few problems with legacycollector.org. Improving support for AMO would require porting more WebEx APIs from FF 54+; I'm gonna go out on a limb and say that wouldn't be easy. As for ATN.... BNavigator / MailNews are unique since MAT restarted their version numbering. Most extensions are compatible but don't realize they're compatible, so they refuse to install. BNav probably needs a "Seamonkey compatibility" mode in which it pretends to be SM 2.49.6 or something for purposes of installing add-ons.

It was imported into the UXP platform, which is shared by Serpent, NM, BNavigator, and MailNews. But it probably only affects MailNews, not the others. Sort of a weird situation: it works on XP (because it doesn't have WMF at all), and also on Win 7, but not on Vista (unless you disable WMF, a cure generally worse than the disease).

In that case see here: (I'm starting to think the linked thread should be pinned, as often as this question seems to come up!)

No apology necessary! I was just exercising "due diligence." If changing the user agent always fixes the issue, that means there's no reason to retain Adobe Primetime support in Serpent 52 - the built-in ffvpx is adequate. And that's one less thing for @roytam1 to have to worry about reverting.

Sorry; I should have said "extensions," not "add-ons." Themes don't rely on WebEx APIs, AFAIK. Examples: Serpent 55 runs the "Multi-Account Containers" extension; Serpent 52 does not. Serpent 55 supports somewhat newer versions of "Empty Cache Button" and "uBlock Origin" than Serpent 52.

As long as the distorted audio can always be fixed with a simple user agent change, I see no reason to retain Adobe Primetime support in Serpent. (I'll add the above user agent to myuseragents.js.) Does anyone know of a site with distorted audio that can't be fixed with a different user agent? (If so, that would be a reason to restore Primetime support.)

It's covered in more detail at @roytam1's original (now locked) thread, but basically: MCP forked Basilisk 55 from an early alpha version of Firefox 53, then applied some commits from FF 54 and 55; hence the "55." At that point, MCP gave up development but @roytam1 picked it back up as Serpent 55. He occasionally posts a new version with updated security and other fixes. MCP forked Basilisk 52 from FF 52.9 ESR and still maintains it. @roytam1 picked it up as Serpent 52 and typically applies their updates weekly. It has diverged slightly from MCP's Basilisk (mostly to retain features removed by MCP but still used by some folks here) but is still very similar to Basilisk. Serpent 55 has slightly better compatibility with new "WebEx" add-ons than Serpent 52, because 55 was forked from a newer FF version. OTOH Serpent 52 has slightly better support for modern .CSS and .JS due to continuing work by MCP. But their "look and feel" is very similar.

I was referring to the official Oracle installers. If you can confirm a 3rd-party installer for newer Java versions working on XP, by all means let us know! It would make staying up-to-date a lot simpler. But be aware that "System Requirements" pages don't always get updated when support for an older OS gets dropped. IOW, don't be surprised if it turns out not to install on XP after all.

IIRC, the last Java version with an installer that runs on XP was 8u151/8u152. But any Java version prior to the latest (8u231 as noted above) will trigger Mozilla's security warning. To get the latest version installed on XP, see these posts: BTW if you put those commands into a .bat or .cmd file don't forget to double all the % characters in the for command. You may also want to use a capital F vs. a lowercase f.

That was from ReactOS 0.4.3 and it didn't work, so I deleted it. I'll upload a newer version soon; when I do, let us know if it works for you.

IMO yes; it's safe. Older, "weaker" encryption is used between the browser (IE or Chrome) and the so-called "front" server, and data is unencrypted between the "front" and "back" servers; but all this takes place within your own PC. No unencrypted or weakly-encrypted data ever leaves the PC. Thus, the connection between your PC and the Web server you're using will be as secure as the Web server is configured to make it. It's conceivable that malware could be written to exploit ProxHTTPSProxy, but the number of folks using it is pretty tiny, so I doubt anyone would bother.

Let's get this out of the way right off: I didn't touch the functionality of either AM! All I did was revert the Bugzilla "fix" in Serpent 52, restoring version numbers to its about:addons page. I didn't (and really, can't) turn Tycho into WebEx or vice versa. Serpent will continue to support the same limited WebEx add-ons; NM still will not. Nothing has changed except that one bit of information on about:addons. This is cosmetic surgery, not brain surgery But it did take me a while to figure out how UXP separates the two browsers. The UXP repo is a bit of a mess, since it has to support PM/NM, Serpent/Basilisk, and XULRunner (used by KM). Turns out under folder toolkit/mozapps there are two subfolders, extensions and webextensions. Each of those folders has a subfolder named "content," which in turn has a file named "extensions.xml." Under "extensions," that file matches the "before" code in Bugzilla, but under "webextensions," it matches the "after" code (the version number has been moved to a tooltip). Clearly, Serpent uses the code in "webextensions," so I just added back the code that the Bugzilla "fix" stripped out, essentially reverting it. This is the same thing the Waterfox folks did to restore version numbers to that browser (yes, I checked that commit too), except in the Mozilla repo there is only an "extensions" folder, not a "webextensions" one. Finally, I also added the one-line change from Waterfox that lets you turn the version numbers back off if you don't like them. I did that in both "webextensions" and "extensions," so that's the only change that will affect NM. Well, I'm a stickler for consistency, and implementing that pref required only a one-line change, so I implemented it in both browsers. The only thing the new pref does is suppress version numbers if it's created in about:config and set to false. IOW, NM 28 will continue to work exactly as it does now, unless you decide you don't want it to! Was that actually carefully examined? Well, I was as careful as I could manage to be in merging the code in. I'm confident I got the one-line change to check the new pref (in both NM and Serpent) right, but there were quite a lot of code that needed to be put back into Serpent's extensions.xml to revert the Bugzilla "fix." And I've done enough coding to know how easy it is to slip up and break something no matter how careful you are. Unfortunately, I don't have a system capable of building these browsers myself. So I wrote that comment in the hope that @roytam1 will do a test build of both browsers, and revert my changes if there are any problems. I don't see it that way. IMO something is broken in FF 40+, and in Serpent; it's just that, as a user of the CTR add-on, I never realized it because the add-on patches the bug! MCP and Waterfox both seem to agree with that assessment, as they both implemented the same fix. Unfortunately, in MCP's case, it was bundled with a much larger "fix" - removing all WE support - that actually did violate your adage, so the "cure" was worse than the disease. (Waterfox fixed it correctly, but of course it requires 64-bit Win 7; otherwise we'd all be using it and @roytam1 would have a lot less work to do every week!) As for CTR, I think you're blowing the Tycho vs. WebEx thing way out of proportion. Like my own changes, CTR is cosmetic surgery, not brain surgery. Neither of us care what's going on deep inside the browser; we're both just changing how things look to the user. The engine underneath doesn't really matter, because it's not interfacing at that level. If it did, how could you expect CTR to work with browsers as different as Basilisk (Tycho AM) and Waterfox (modified WebEx AM) and yet not work with Serpent 52 (WebEx AM with UI modified as in Waterfox)? I think this is your best point. As it happens, I did look for add-ons besides CTR that would put the version numbers back. After all, not everyone wants to install CTR just to fix that one issue. I didn't have much luck, but then, I didn't look very hard, since it seemed fairly simple and more sensible to just fix the problem at its source. At the end of the day, though, this is the same argument we've seen over other features that Mozilla or MCP have removed (container tabs come to mind): is it better to have the feature in the browser itself, or as an add-on of some sort? Usually, we've come down on the side of leaving the feature in the browser, and that's what I'm trying to do here. I'm not sure how I feel about removing Primetime support. On one hand, @roytam1 already builds in support for playing .mp4 files, so you would think Primetime isn't really needed any more. But OTOH, there have been reports of badly distorted audio when playing some .mp4 videos. Disabling the built-in support and installing Primetime fixes this issue, but that won't be possible with Primetime support removed. The distorted audio issue seems to be rare, but it does still seem to exist. Has anyone encountered it lately? If so, could you post a link to a video exhibiting the problem?

Totally agree. We could have a whole separate thread on setting up browsers for privacy. The topic goes far beyond those two prefs. Remember, this topic came up because the UOC Patch sets privacy.resistFingerprinting for performance reasons, but it comes at the cost of compatibility with Flash. Anyone concerned with privacy is probably very reluctant to use Flash to start with, so that incompatibility may not bother them. But if they're installing the UOC Patch for performance, they may still want to use Flash, and need to know about the incompatibility. I don't know if it helps performance, but canvas.poisondata doesn't cause Flash compatibility issues. I only mentioned it because it does one of the many things that privacy.resistFingerprinting does. So, I finally got around to looking at this, with an eye toward bringing Serpent's AM display back in line with official Basilisk (without disabling WE compatibility). Shouldn't be hard (as long as I don't make any mistakes!), but I have to say Mozilla really made a mess of this. The screen shot at the link tells the story: Mozilla redesigned the AM display after FF 38, I guess as part of the whole Australis thing. They chose a more attractive color scheme but also a layout that wastes lots more space on the screen! I guess the devs didn't understand that the PC universe hadn't moved entirely to big 24-inch (61-cm) monitors back in 2014! (Devs are so spoiled sometimes.) Of course they decided the problem couldn't be with their new layout; instead, it must be that the user was just getting too much information, so they moved the version number to a "tooltip;" with the "fix" above, the version appears when you "hover" over the add-on's name with the mouse pointer (as well as on the "More" page). Then, to compound the error, rather than simply conditioning the version number display on a new pref, they ripped out most of the code needed to display it, meaning you couldn't bring it back without an extension like CTR. BTW, CTR has several options to help the version number fit on a smaller screen: there's "alternative appearance," which brings back the pre-Australis look (unfortunately it also brings back the old color scheme, but nothing's perfect, I guess); there's "replace button labels with icons," which makes the right-side buttons less enormous, and there's "compact view," which makes everything smaller, although that one's a mixed bag (looks pretty good on extensions, but on the plug-ins page, where the version numbers are typically short but the names and descriptions are long, you really need to stick with a 2-line format). Anyway, the point is there were plenty of ways to fix this without taking info off the display!

Did I not say I've twice (Edit: now three times) posted that the UOC Patch is where the problem lies.

Wow - it turns out that privacy.resistFingerprinting does a lot more besides what canvas.poisondata does! The full list of what it's supposed to do is in the spoiler. Most of this was not implemented in Serpent 55, and I'm unsure which of these functions interferes with Flash, but something does:

Warning to users of Adobe's "Flash" plug-in: I have discovered that the 52 ESR version of the UOC Patch sets two preferences that interfere with Flash: privacy.resistFingerprinting dom.ipc.plugins.asyncdrawing.enabled #1 is more serious. For some reason, it prevents Flash from working at all. Luckily, it also has the easiest workaround: set it back to false, or remove the line enabling it from the UOC_Patch_52.js file; instead, use an extension (I use "Canvas Defender" but there are several others) to resist canvas fingerprinting. #2 may, or may not, affect your system. To test, first disable the above preference, then go to https://get.adobe.com/flashplayer/about/. If both the Flash animation and your currently installed Flash version appear, you're fine and can leave this preference set to true. If the page doesn't work properly, you'll have to set this preference to false also. Unfortunately I know of no workaround to retain its function if you have to turn it off. Edit: It turns out that privacy.resistFingerprinting implicitly does lots of things "behind the scenes". Some of these changes, such as user agent overrides, could cause Web sites to malfunction or otherwise affect usability. Luckily, most of the changes didn't land until FF 55 (which won't run on XP) or later FF versions (but Serpent 55 may include some of them). Still, I think it would be best to remove this preference from the UOC Patch. Edit 2: The troublesome privacy.resistFingerprinting also appears in the FF 45 version of the UOC Patch, but that preference doesn't do as much in that version, so it may not cause trouble with Flash there. I haven't tested FF 45 with the UOC Patch and Flash. Edit 3: Found one more. This one's more obscure, but I'm posting it anyway, just in case anyone runs across it. The UOC Patch sets pref apz.allow_zooming, which conflicts with the Multi-Account Containers add-on. That add-on is the main reason I switched to Serpent 55, so my own customized version of the UOC Patch now omits privacy.resistFingerprinting and apz.allow_zooming, and sets dom.ipc.plugins.asyncdrawing.enabled to false to ensure Flash always works. Hopefully I now have everything working again!

Give the users a choice between Chrome and Chrome, and they'll pick Chrome every time!

Sure; it's "Canvas Defender," v1.1.0. The 32-bit version is dated 2019.10.22. The 64-bit version is dated 2019.10.25. @roytam1 must have had to fix something in the 64-bit version; hence the later date. You won't have any trouble with Flash unless you've installed @looking4awayout's UOC Patch for FF 52-based browsers. A couple of the preferences he sets interfere with Flash. I've identified one as privacy.resistFingerprinting; if you remove that line from UOC_Patch_52.js, Flash partially works. Edit: The other problematic preference is dom.ipc.plugins.asyncdrawing.enabled. Flash doesn't seem to work correctly on Windows 7 with that preference set to true. The "Check Adobe Flash Version" Web page won't show the Flash version. Edit 2: In my XP VM, it's a YMMV situation. Sometimes it works if I leave it set to true; sometimes it doesn't. Making things even more confusing, if the UOC Patch is not installed, the default is true in Serpent 52 and false in Serpent 55. For consistency, I customized my copy of the UOC Patch by removing the privacy.resistFingerprinting pref and by setting dom.ipc.plugins.asyncdrawing.enabled to false. With those changes, Flash always works when the UOC Patch is installed.