Mathwiz

No, the installer requires Win 7. You have to download the .zip and install manually.

Still lets me log in with Serpent 55 using the "Chrome 73 on Linux" user agent I stole from that add-on a few months ago. Does the problem occur later, after you've already logged in?

Definitely one of the weirdest (not to mention most frustrating) things I've had happen in a long time. My working theory is that some sort of power surge or interference "stunned" them all overnight, then when I found the problem and unplugged and re-plugged several of them, they woke up and eventually found each other, even though nothing seemed to happen at first. Although that does make me wonder if they're quite a bit smarter than they're letting on

For several years I've been using a set of four TP-Link TL-PA2010 powerline adapters to network various devices throughout my house. Came home today and they were all disconnected from each other. The center LED is off on all four. Normally when this happens to one, I just unplug it and plug it back in, and it reconnects to the other three. At worst I may need to "pair" it with one of the others. But today all four were disconnected, unplugging/plugging back in does nothing, and none of them will "pair" to any of the others. Right now my PC and Roku are limping along on WiFi but I still have two devices completely disconnected from the network. Anyone have any idea what could possibly be going on? Edit: OK, this is getting spooky. Everything just came back on! I did nothing. Do I have a poltergeist?

Thanks for your question, but could you provide just a few more details please? Which browser are you using? Which version? Which youtube video are you trying to play?

Another small advantage of multiprocess mode: if you experience a crash, it won't normally take the whole browser down. Instead it will just take down the tab with the problem, and give you the option to try to reload it; much less disruptive than having to restart the browser and reload all open tabs.

Couple of things: If ABP is too resource-intensive have a look at uBlock Origin. It's purported to be much less resource-intensive. As posted elsewhere I prefer the "legacy" version (currently 1.16.4.11) to the WE version because some privacy features don't work on FF 52 with the WE version. The companion add-on "uBlock Origin Updater" will keep you up-to-date on the latest legacy version of uBO. Feel free to experiment with dom.ipc.processCount. The best setting probably depends not only on available RAM but also on your browsing habits, so the "best" setting will likely vary quite a bit from person to person.

Yes, that's the same problem @Sampei.Nihira was having. Cloudflare seems to have some sort of routing problem between much of Europe (but not all; Greece reportedly is fine) and Roytam's server. @Sampei.Nihira found a free Web proxy that let him work around the problem. Look a couple of pages back and you should be able to find his post.

Well, you're right - but so was I. There are two update mechanisms in FF and its offshoots: manual and automatic. And believe it or not (I certainly didn't believe it until I confirmed it myself) on Serpent 55, they yield different results! As you found, the manual process (where you ask the browser to check for updates) stops at 1.17.4. But the automatic process will eventually offer 1.21.2 (which is broken on St 55, as you noted). What the heck is going on here anyway? I think I found the answer in these two prefs: extensions.update.background.url;https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% You'll have to scroll to the right to see the relevant difference (it's subtle). The "appVersion=" query string passed to the server is the variable %APP_VERSION% in the extensions.update.background.url pref, but it's hard-coded as 53.0 in the extensions.update.url pref! As it happens, uBO version 1.17.4 is the latest version claiming to run on FF versions 52.0 through 54.0. All later versions claim 55.0 or later is required. So when you manually check for updates, AMO only offers uBO version 1.17.4. but when the browser does it automatically, %APP_VERSION% gets replaced with 55.0, so AMO offers the latest version (1.21.2). This discrepancy goes back at least as far as the 3/10/2018 version of Serpent 55. I'm surprised no one has stumbled across it before now. I'm guessing the hard-coded 53.0 was meant to fix incompatible updates being offered (Serpent 55 was forked from FF 53, with only a few changes back-ported from FF 54 and FF 55, so many add-ons targeted at FF 54 or 55 won't run, now including uBO 1.21.2), but whoever put it in (MCP?) forgot to make the same fix to the background pref. It would make more sense to hard-code 53.0 in both update prefs and eliminate this oddity. Side note: if you go to about:addons, click Get Add-Ons, then click Find More Add-Ons, what AMO offers depends on your user agent. By default, it won't offer anything except a download of Firefox (even in FF compatibility mode), but if you use, say, a SSUAO to provide a "pure" FF user agent, it will offer either 1.17.4 or 1.21.2, depending on which FF version you pretend to be. If you want to "live on the edge," you could put 55.0 in a SSUAO for AMO. If you also fix the background update pref, you wouldn't be offered any uBO updates past 1.17.4, but could still manually browse AMO and try later versions to see if they work (as mentioned, 1.18.4 will and 1.21.2 won't, but I haven't tried versions in between to find out where the "cutoff" is).

Aside from what @win32 mentioned, Vista can still get updates. Not directly, but Server 2008 updates can be installed on Vista, and they'll keep coming for at least a while longer. But software support is about the same. Pretty much everyone who's dropped XP support has dropped Vista support too :(

Without uBlock Origin Updater, Serpent 55 (Moebius) will self-update to 1.18.4 (or possibly later); Serpent 52 (and FF 52.9) will self-update to 1.17.4*. Surprisingly, the new versions mostly work with Serpent (& FF), but there are a few features that don't, presumably due to WE APIs missing in versions before FF 55. For example, in the Dashboard / Settings / Privacy, the "Prevent WebRTC from leaking local IP addresses" setting is greyed out. So I stick with the so-called legacy version (1.16.4.11), use uBlock Origin Updater to keep me there, and am able to check that privacy setting. *Digression: it is possible to run uBO 1.18.4 with Serpent 52/FF 52.9, but several hoops must be jumped through (more on FF than Serpent), and since 1.16.4.11 works better anyhow, I don't feel it's worth the effort.

Well, any difference needs to be tested. Like you I get 104.27.137.100. So, I used my hosts file to force my browser to access 104.27.136.100 instead when I enter o.rths.cf in the address bar. Perhaps the .136. one was down? But both IP addresses work, so both server IPs are on-line. The issue is neither with the DNS, nor the server; it must be with CloudFlare's routing. So I say again: In the meantime I'm afraid @Sampei.Nihira will just have to use the Web proxy he found.

Your PC is going to use the primary DNS first; the secondary DNS only if it doesn't get a response from the primary one. Does your smart phone also use the AdGuard DNS? And I ask again:

(Forum software wouldn't let me insert the above quote into my previous post) Maybe Wine could be adapted to XP, but it would take a lot of work, and wouldn't really get you as far as you might wish to go. ReactOS is probably a better bet.

Well, it's not a completely crazy idea - and you're not the first to ask: Right now you can start a VM from XP, boot Linux, and use Wine to run programs that can't run on XP itself. Your idea is to "cut out the middleman" - Linux - and have Wine run directly on XP. But....

Probably need to contact CloudFlare. Sounds like their network is fouled up somewhere between Rome and wherever o.rths.cf is (Wikipedia says .cf is Central African Republic, but that seems unlikely. More likely, the CAR is letting CloudFlare use their TLD for a fee.)

@Sampei.Nihira, did you try a ping? Did you get the same results as @VistaLover? If you did then your DNS is OK. Unfortunately those IPs apparently host several websites, not just o.rths.cf; a frustrating but increasingly common practice. Therefore you must specify the host name, o.rths.cf, to access it. So if your DNS is not OK, your only recourse is to override the bad IP address in your hosts file.

That's probably not it; the browser itself detects that condition and produces a different message ("no cipher overlap," as I discovered with Mediafire). Besides o.rths.cf supports a couple of "strong" ciphers (forward secrecy, SHA256, no CBC) that I know NM also supports. Try pinging o.rths.cf at a command line. IP address should be 104.27.136.100 or 104.27.137.100. If not try downloading directly from one of those IP addresses (replace o.rths.cf with an IP address in your browser's address bar) and see if that works.

Here's the post with a link to the patch: As noted you must download and install it manually; it was never offered by Windows/Microsoft Update.

OK. Reason I asked is that I often notice trouble scrolling in Serpent when multiple tabs are opened. Multiprocess mode (not possible in NM anyhow) helps but doesn't eliminate the issue completely. This sounds like something different though, since it occurs even with only one tab open.

@looking4awayout, do you have other tabs open? Or does the scrolling stutter with just a single tab open?

One little correction: the UOC Patch for FF 38-based browsers also applies to the K-Meleon browser, but you have to extract it into a different folder. Instead of <browser folder>\defaults\pref, for K-Meleon you should extract the patch into <browser folder>\browser\defaults\preferences. Also, a note for those who have "hardened" their browser by disabling ciphers that don't offer "forward secrecy:" If you've done this, you won't be able to download the UOC Patch (or any files) from Mediafire, as their server doesn't provide any ciphers with forward secrecy. You'll get "no cipher overlap" message from your browser if you try. If this happens to you, I recommend you reset pref security.ssl3.rsa_aes_256_gcm_sha384 to true. It doesn't provide forward secrecy but is otherwise a very strong cipher and is supported by Mediafire. I posted this many moons ago; Mediafire has since updated their server to provide some TLS 1.3 and TLS 1.2 ciphers with forward secrecy, so it should no longer be necessary to enable an older cipher.

I do have Firefox 60.8 ESR on my home Win 7 machine; I'll try SSUAOs with it and confirm that they work once again. Edit: It works! The whole thing seems odd to me; usually with these browsers, it's MCP removing some useful feature (like WebExtensions or container tabs), and we're begging @roytam1 to revert the change; but in this case it was Mozilla disabling a useful feature, and it was MCP (and roytam) who reverted the change!

Wanted to revisit this issue briefly, but only to point out that the above rigamarole isn't needed with @roytam1's builds of FF 45 ESR (for SSE-only CPUs); SSUAOs work right out of the box (or out of the .7z). Not certain if that's also true of "stock" FF 45 ESR, if roytam incorporated a fix at some point that re-enabled SSUAOs, or if they're only enabled in "Nightly" builds (roytam's builds are based on nightly builds; the Firefox button even reads "Nightly" vs. "Firefox"); but I suspect the latter. According to info gleaned from @Sampei.Nihira's link above, SSUAOs were disabled way back in FF 25 (!) for performance reasons, yet they work in FF 37 beta 4, but not in FF 54 (or 52.9, of course). So I suspect they're enabled in beta and nightly builds, but not in regular release or ESR builds since FF 25. (Info at the link above did hint that they were originally intended for testing.) SSUAOs work in all of roytam's browser builds; the code above is only needed to enable them in "stock" Firefox versions.

This may help. I finally buckled down and updated my browser downloader .bat to handle Roytam's FF 45 ESR SSE-only builds. It turned out to be quite a challenge: the file list can't be downloaded the same way as the others (downloading the root directory containing the files only returns a bunch of JavaScript, no file names); the "correct" file list URL had to be parsed differently; and last but not least, there was an issue with version numbers: Edit: Batch file is now included in the .7z downloadable at http://i430vx.net/files/mathwiz/Browser Installer.7z