Mathwiz

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.

That sounds familiar....

Well, a clean profile didn't work on this machine either. But, perhaps a clue.... The first time I accessed the "Check Adobe Flash Version" page after switching to a clean profile, I got a pop-up saying something about "Tracking Protection Enabled." Remember, this was a clean profile - no add-ons! So it appears the latest Serpent build has some kind of "built-in" tracking protection, which, I suspect, is "protecting" me from Flash (a notorious privacy leak). I also noticed the 64-bit version was built (rebuilt?) three days later than the 32-bit one. I need to go back and take a look at what @roytam1 added. Edit: I may have figured it out! I just remembered that a "clean profile" isn't necessarily the same thing as "factory default" settings! You can change preferences outside the profile too, by, for example, installing the UOC Patch - and the only browser with the UOC Patch installed is the one that Flash doesn't work on! Of course, now I have to figure out which line of the UOC Patch is interfering with Flash.... Edit 2: This is turning out to be more complicated than I imagined, but I found part of the problem. The UOC Patch sets privacy.resistFingerprinting to true, which inexplicably interferes with the Flash animation. Removing that line from the UOC Patch lets the Flash animation play normally.

Very strange. The new version of Flash does appear to be correctly installed, and shows up on about:addons and about:plugins as installed and set to "Always Activate." Everything looks the same as the screen shots you posted above, except the "Check Adobe Flash Version" page, which shows blanks where the two Flash controls should be. Like you, I have Flash "protected mode" enabled. Closing the latest Serpent 55 build and launching the previous build allowed the "Check Adobe Flash Version" page to run normally. The Flash animation and the version detection both worked as expected. For the clean profile test, I was careful to make my clean profile the default and restart the browser. In the past I've noticed that the "Launch Profile in New Browser" button doesn't always do the job. Unfortunately, results were the same. I also tried the same tests on Windows 7 and got the same results. Maybe it only works under Vista? (jk) However, I am now home and about to try again. Be back soon.... Edit: I'm back. This is all on 64-bit Windows 7, BTW. 2019.08.18 32-bit: works. 2019.08.18 64-bit: works. 2019.10.22 32-bit: doesn't work (same as on my work machine and on the XP VM). But it works on @VistaLover's PC. 2019.10.25 64-bit: works! I haven't tried a clean profile on this machine yet; BRB....

The latest Flash (32.00.293) doesn't work with the latest Serpent 55 (2019.10.22). It does work with the previous Serpent 55 version (2019.08.18). I tried a clean profile; same result.

Chromium-based M$ Edge (on Win 7) started nagging about eventually not supporting Flash at least a month ago. I never really liked Flash all that much, but always keep it installed in case I run across a Web page that still needs it.

When I tried out FF 53, I discovered that some of my add-ons got disabled. The problem was with "unsigned" add-ons. Usually these were legacy add-ons that continued to be maintained after Mozilla banned pre-WebEx add-ons, and thus could no longer get Mozilla to sign them. The biggest example was the legacy version of uBlock Origin, which I use because it offers more privacy protections than the WebEx version does on FF 52 and 53. (A couple were add-ons that were originally signed, but from which I had removed the signature in order to implement some hack.) In FF 52 ESR, unsigned add-ons aren't much of a problem. You simply set the about:config preference xpinstall.signatures.required to false and you're good to go. The unsigned add-ons will produce warnings in the about:addons page, but they work. You can even hide the warnings with an add-on like Classic Theme Restorer. But FF 53 is a "stable" release, and xpinstall.signatures.required doesn't work in stable FF releases. Luckily, there is a workaround, but it's a bit more complex than just setting a preference. The workaround at the link can be combined with @VistaLover's fix for re-enabling SSUAOs in Firefox 52: First, follow the instructions there; then add this JavaScript to the config.js file you just created: try { Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {}) .eval("SIGNED_TYPES.clear()"); } catch(ex) {} (I put it after @VistaLover's code, but it will probably work before it too.) One last thing. Since FF 53 doesn't expect to have add-on signing disabled, it doesn't have the yellow "warning" text that FF 52 ESR does for an "unverified" add-on. Instead, you'll see a scarier, red "This has been disabled" message. However, it has not been disabled; you'll still see a "disable" button which wouldn't be there if the add-on were already disabled. Luckily, hiding warnings (with, e.g., the Classic Theme Restorer add-on) will hide these scarier messages just as it hides the yellow warnings in FF 52 ESR.

Detailed explanations are always my preference; thanks! Of course I also understand why you might not have wanted to go into such detail the first time around. (It's too bad MSFN doesn't support a "spoiler" tag - that would have been a perfect use for it.) (Note: henceforth I will use "AM" as my abbreviation for "Add-on Manager," so I can reserve "AOM" for "Alliance for Open Media" and its AV codec.) So from the above, one can infer that NM 27, NM 28, as well as "official" PM and Basilisk, none of which support WebEx add-ons, all use the Tycho AM, which displays add-on version numbers without the assistance of an add-on like CTR. OTOH, any browser supporting WebEx add-ons (Serpent 52/55, Firefox 52/53) by necessity must use the WebEx AM, which does not display add-on version numbers unless "coerced" to do so via an add-on such as CTR. However, that little wrinkle aside, nothing seems to stop anyone from running the newer CTR versions on Serpent 52. At present I'm not aware of any "killer" features that would make this worth doing, but at least we can experiment! Waterfox (Win 7 and 64-bit CPU required) would seem to be the oddball here, as it does support WebEx add-ons (as well as classic ones), so one would think it too would use the WebEx AM, and therefore wouldn't display add-on version numbers without CTR's "help." I must therefore conclude that the Waterfox folks developed their own fix for this issue. (Since it appears to be merely a .css issue, I suspect it was a rather simple fix.)

Actually I did read that; I merely chose to ignore it!

Mozilla's decision to remove support for all pre-WE APIs, of course, broke CTR for FF 57+. Then their decision to remove all pre-WE add-ons from AMO meant that only "legacy" / classic add-on repositories would have a link to CTR. I checked legacycollector and addons.basilisk-browser.org first with no luck, then found it in the CAA database and thought my search was done, unaware that development is continuing for Basilisk / Waterfox at GitHub. So now, I've updated Serpent 55 to v1.7.8, and Serpent 52 (which should be on par with "official" Basilisk) to v1.7.8.2019.10.7! I'll update my old FF 52.9 (and XomPie-patched FF 53) next. CTR has so many options, though, I can't readily tell what was added between 1.7.7.2 and 1.7.8 et seq. One weird thing I did discover, though was that v1.7.8.2019.01.21 removed the option to display the version number in the Add-On Manager screen so by updating Serpent 52 to the "latest" version, I lost that bit of info. The author explained, "Basilisk 2019 and Waterfox don't need this option, because version number is active by default." If so, that would be a question for @roytam1: What is the difference between Serpent 52 and "official" Basilisk that accounts for this slight UI change? Inquiring minds want to know.... Maybe I'll roll it back to 1.7.8 so I can tick that option back on; I like having my add-on version numbers visible at a glance. Serpent 55 still searches AMO for updates. Serpent 52 searches, um - what should we call it? ABBO, I guess. But I haven't found ABBO particularly useful (as mentioned it doesn't even include CTR), so I switched the prefs in about:config back to AMO (you have to change %APP% to firefox). That way, at least my WE add-ons stay updated. Surprisingly, quite a few are still compatible with FF 52/53 and Serpent 52/55.

That's good; your last post had me worried! My yellow shield was there this AM with the three Office 2010 updates. Since manual installation still works, here are links to their support pages: https://support.microsoft.com/kb/4484164 https://support.microsoft.com/kb/4484127 https://support.microsoft.com/kb/4484160 You can go to each support page, scroll down to "Option 3: Microsoft Download Center," and find links to the standalone installers for both 32- and 64-bit versions of Office 2010. (I would assume the vast majority of folks have 32-bit systems, but just in case....)

That isn't a problem only for users of older OSes; it's a problem for anyone who prefers a platform other than Google's Chromium! Opera switched to Chromium long ago. Micro$oft switched from IE to Edge a little less long ago, but the "new" M$ Edge for Win 7/8.1? It's Chromium-based. It's gotten to where Chromium is the new IE monopoly! (But at least M$ wasn't using IE to spy on me or to dragoon me into helping train their AI.) I sometimes wonder if I should have a SSUAO for Google sites, claiming to be Chrome, just so Google's reCaptchas don't bug me quite so much, but then I remember I'd have to update the SSUAO almost as often as @looking4awayout updates the UOC Patch! No, he means New Moon, as the Pale Moon folks will angrily tell you if you ever make that innocent mistake on one of their forums. "Pale Moon" is only one of the browsers officially released by Moonchild Productions. Pale Moon does not run on OSes considered "obsolete," like XP or Vista, and woe to the poor soul that mentions XP or Vista on a Pale Moon forum. Anyone else's build is "New Moon" unless they develop their own branding (e.g., MyPal, Arctic Fox) for their own fork of Pale Moon. Edit: Doggone it, @VistaLover beat me to it again! Foiled by a page break....