Mathwiz

https://www.subaru.com/vehicles/outback/models.html/OBK-compare-wrapper-modal doesn't seem to render quite right in Serpent 55, or in an earlier NM version (2019-05-10) either (the details are shifted rightward wrt the headings, and the chart is too wide but there's no scroll bar). So it could be a problem common to all UXP-platform browsers. Or it may just be my specific setup. I have this particular PC zoomed up to 150%, and that's caused occasional problems of this kind before. I'll try it with my more "standard" work PC Monday.

I guess it depends on what it did. Did Panda install an add-on to Firefox? That could still be there. It could also have updated the hosts file (C:\WINDOWS\system32\drivers\etc\hosts) to block access to certain hosts; if it happened to block the host where the fonts come from, that would cause problems too. Edit: I doubt it would change any prefs, but just in case; go into about:config and make sure gfx.downloadable_fonts.enabled is set to true.

Many sites download their own fonts. I suspect Gmail is among them. Panda may be blocking the font download; I don't know anything about it but you might look for a setting related to downloading fonts.

Yes; M$ sort of added insult to injury. They weren't satisfied with just disabling future updates, thus rendering MSE useless; they also gave us a non-working uninstaller so we couldn't even get rid of the $#@$^ thing! Oh; forgot to mention that even after disabling the anti-malware service and killing the msseces.exe process, I still had to use Unlocker to completely delete the directories. I guess you wouldn't want it to be too easy for malware to do a rogue uninstall, so maybe this makes sense - but that's all the more reason the official uninstaller should work! Oh, well; at first blush I'm quite impressed with Avast. It did falsely trigger on ProxHTTPSProxyMII, but that's understandable; that is a MITM after all! I'm glad I'm one of the lucky ones Avast seems to run OK on. Probably should've ditched MSE for it years ago.

I agree that someone from MCP coming onto this thread and striking a disagreeable attitude, making threats, and generally being unpleasant, doesn't exactly predispose folks here to try to accommodate their wishes. And it's also true that to the extent there are "branding" issues with unofficial builds, they are the fault of MCP themselves, not @roytam1. So I can sort of understand having a spiteful attitude toward MCP and their demands. But I think we already decided we weren't undertaking a full rebranding of New Moon or Serpent anyhow. At this point, all we're talking about is getting rid of the "you've successfully upgraded" Web page and redirecting a few Web pages that come up when users of @roytam1's browsers use the Help menu. It's just not that big of a deal, and it's worth doing anyhow for the benefit of New Moon / Serpent users (not to mention msfn.org, which stands to gain a few more members). If it eases tensions with MCP a bit too, so much the better. (And if someone's really stubborn about it, they can switch all their prefs back in about:config anyhow.)

That's a good point. It would therefore be best not to have the browser point directly to specific pages at msfn.org, since the URLs could change. They could point to msfn.org indirectly, though, via a redirect. Yes, for New Moon that will work fine. Edit: In fact I see it's already up (although the page is blank for now). I'll make that change tonight. For Serpent, you would need two related pages: https://<something>/ and https://<something>/keyboard-shortcuts. Each of those two pages can bring up either a static page or a redirect. The first page will come up if the user goes to Help / <browser> Help. The second page will come up if they go to Help / Keyboard Shortcuts. Mozilla's pages are already arranged that way, so I just left the app.support.baseURL pref in Serpent pointing to Mozilla's site for now.

I think you can stop it from running by: Disabling the Microsoft Antimalware Service Removing the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MSC (export it to a .REG file first, in case you change your mind) But it looks like #2 must be done offline. The key is protected....

Well, it's done. Avast 18.8 Free is on my system and MSE is gone. Looks like I traded up (although Avast wants me to update FF 52.9.1 ).... Be Aware: getting MSE off my system was a nightmare! May have been a mistake to install Avast first; anyhow, the first time I tried to uninstall, it just locked up and I couldn't stop it. Had to power off & reboot. I gave it one more chance, and the second time it sort of half-worked. Said it uninstalled, was gone from Add / Remove Programs in the Control Panel, but the logo was still in the system tray in red. Had to kill the msseces.exe process, then delete "/Program Files/Microsoft Security Client/", "/Documents and Settings/All Users/Application Data/Microsoft/Microsoft Antimalware/", and "/Documents and Settings/All Users/Application Data/Microsoft/Microsoft Security Client/" all manually to completely get rid of it. There's probably still a registry entry or 12 floating around....

Here's a quick link to the installers for the last XP version: https://forum.avast.com/index.php?topic=223244.0 BTW, I think you have to use the online installers. The offline installer links are for the current post-XP versions.

Late to the party, but there are a large number of browsers forked from Firefox 52 ESR: Roytam1's New Moon 28 Roytam1's Serpent 52 Roytam1's K-Meleon 76 Roytam1's fork of BNavigator Feodor2's MyPal Seamonkey 24.9.5 There are also a few other Firefox forks that are still updated on a regular or irregular schedule: Roytam1's New Moon 27 Roytam1's Serpent 55 (forked from FF 53.0a1) Roytam1's FF 45 ESR (for pre-SSE2 CPUs) Chromium-based browsers are perhaps a bit shady, but some are still of recent enough vintage to use (perhaps with help from an SSL proxy like ProxHTTPSProxyMII): Chrome 360 (Chromium 69) Maxthon

Yes. This way I can get it changed right away, but it's not set in stone; as soon as there's a URL to link to, I can change palemoon.js again. I've been using direct URLs so no changes to @roytam1's web site will be required.

To keep things simple for now, let's just redirect browser.slowstartup.help.url to the above Mozilla page. Unlike Matt et al., Mozilla won't mind: Basilisk / Serpent already point to Mozilla pages for several purposes. Longer term, we can use this thread to host additional New Moon / Serpent support pages, including the one above. But the short-term goal is just to avoid inadvertently directing New Moon users to palemoon.org where they might expect support.

Well, I just put in a change to point "Submit Feedback" here (in both Serpent and New Moon). I could point "<browser> Help" to the same place, but in Serpent there's a problem: Serpent already points to Mozilla, so no change is needed there. New Moon doesn't have the "Keyboard Shortcuts" option, so we can change it. But I don't want to point two Help menu options to the same place. So how about this: I'll point "New Moon Help" to the first post of this thread, where @roytam1's FAQ is. I pointed "Submit Feedback" to the first new post (of course you have to be signed into MSFN for that to work), so the user can contribute to the discussion.

Thanks @VistaLover. PM has a "slow startup" help page? (FF and Serpent don't seem to.) Do you have a suggested replacement URL? (For app.support.baseURL I was just going to point to Mozilla.) Yeah, I tried both. Actually I tried <install dir>/defaults/pref first, since that path already existed; when it didn't work I created defaults/preferences/ under browser/ but had the same result: it added new prefs but didn't override the built-in ones. It probably depends on the order the .js files are run at startup, with the last file to set a pref "winning." Now I didn't try it with Firefox, so maybe it works there, but we're not changing FF! I tried with both Serpent and New Moon and got that result. In the omni.ja I extracted, there are several subdirectories under defaults/: autoconfig/, pref/, and preferences/. I haven't done extensive testing but at this point it appears the contents of preferences/ are run last; hence, can't be overridden (except by user prefs). It's certainly possible MCP changed the order these run at startup. Or maybe even palemoon-branding.js, which is the one I changed (unofficial branch only, of course).

It won't be a problem for every release. It'll only be a problem if MCP someday changes the same files I changed, and even then, I think only if MCP changes the same lines of code (otherwise I think Github can easily merge MCP's changes with mine into the final source files). Pretty sure that's why @roytam1 wanted this done by a pull request in the first place. If MCP does happen to change those same lines of code someday, @roytam1 will need to decide which of the two conflicting prefs to use in the final build, but that shouldn't be hard and is a one-time decision anyway.

Thanks. I'll make the necessary fix and create another pull request, probably tonight. Tried that; surprisingly, it didn't work! Apparently these particular prefs override whatever is in that folder. (Same goes for SSUAOs BTW; any built-in SSUAOs override whatever is in browser/defaults/preferences, although that's not as critical, since the built-in SSUAOs are supposedly correct for the NM/Serpent version being used. Adding myuseragents.js to that folder still adds the SSUAOs that aren't built in.) Besides, we want to change the build so that everyone gets these changes, and the easiest way to do that (at least, the easiest way for me) was to fix the built-in prefs in the first place, rather than adding another file to the build to override them. I think you're talking about the channel-prefs.js file, which sets app.update.channel to "default" for @roytam1's builds (presumably sets it to "release" or "ESR" in official builds). Yes, if a .js in that folder worked (which, unfortunately, it doesn't), I could've added the prefs to that file instead, although the name "channel-prefs.js" would then be a bit misleading

Good advice; although that too let me down when I was troubleshooting.... If I went to about:profiles, created a new clean profile, and clicked "Launch profile in a new browser," it would indeed open a new browser window sans add-ons - but all the old profile's preferences were still in effect! To get a truly "clean" profile I have to instead click "set as default profile," then restart the browser (and then reverse the process when going back to "normal"). That silliness kept me from realizing it was a preference issue, until I tried your suggested SSUAOs and discovered it stlll didn't work

Yes, the mods are complete. Let me know if it causes any problems and you have to revert any of the changes. I did not modify the app.support.baseURL pref because I couldn't find that one. Serpent doesn't need that one changed anyway; only New Moon. If / when I find it, I'll create another pull request to fix that pref.

I was afraid this might happen: But I figured we'd at least have until July, when M$ Update goes away. I guess our only hope now is to try to satisfy the missing dependencies with something like Dibya's extended kernel....

I was going to run that experiment myself, in the hopes of finding a "universal" Github SSUAO to incorporate into myuseragents.js; thanks for doing that for me! But here's what I'm really wondering. If you use St 52 (or FF 52), and a FF 60.9 user agent, Github serves up code that is compatible with FF/St 52, and works. But if you use a FF 60.9 agent with St 55, it doesn't work; even though Github is seeing the same user agent, and thus presumably serving the same code, as with FF/St 52. Now I realize that St 55 was forked from FF 53, while St 52 was forked from FF 52 ESR, so there are bound to be differences in how javascript, CSS, etc. are handled. But the question I still have is, what kind of code works on FF 52, and on St 52, but doesn't work on St 55; and why? Sounds to me like there's a regression somewhere in either FF 53 or St 55, but my troubleshooting skills aren't up to the task of finding it. And although I can't test it myself, probably doesn't work on FF 53 either, although it might have been fixed again between the fork point and the release build of FF 53. Edit: Folks, I'm afraid further apologies on my part are necessary. It turns out that Github works just fine with both St 52 and St 55 (as well as FF 52, PM/NM 28, etc.) using a FF 60.9 user agent! This whole discussion has been a huge waste of time. Well, maybe not a complete waste of time, because I did learn something. The culprit, it turned out, wasn't the user agent, or differences between St 52 and St 55, after all: it was a couple of user prefs I'd set to true: dom.webcomponents.enabled and dom.webcomponents.customelements.enabled. I had only set those to improve the score on html5test.com, but it turns out that if either of those is set, Github won't work!

I agree; I never liked those "you've successfully upgraded" pages anyhow. I think simply blanking out the pref would prevent any such page from opening in the first place - not even a blank page. (Setting the pref to "about:blank" would presumably open a blank page, but that would be confusing.) I looked over the UXP source tree and think I found where that pref is stored, as well as a couple of others mentioned above. So I cloned the tree, made the changes, and created a "pull request" as @roytam1 requested; but please keep in mind I'm a total noob at Github, so even though this was just a few simple changes, I'm not sure I did it right

Great! I'll put that right into effect; I hate having to use two different browsers. I'd love to know why St 55 requires a different SSUAO than St 52, but as long as it works, that may just have to remain an unsolved mystery.

Well, I came back to say,I discovered it works fine in St 52 (spoofing FF 60.9 as usual), but not in St 55. St 55 always acts the way FF/St 52 act if you spoof to any other version; e.g., pressing the branch button just shows a thin horizontal line and won't list your branches. I'm really confused as to why, but anyway, I can use St 52 unless/until I find a workaround for St 55. Sorry to press the panic button prematurely.

Well, this is bad news: Github no longer works with FF 52, no matter what spoof I try. I even tried IE (no longer supported - says to update to Edge, which is a bit tough if you're on Win 7) and Chrome spoofs. Nothing worked. BTW, spoofing anything older than FF 60.0 results in the "old version" banner. 60.0 and up don't produce the banner, but no version, old or new, works.

Just updated the myuseragents.js on page 8: For the benefit of our Polish readers, this update adds the user agent @VistaLover discovered for the player.pl site.