Mathwiz

Does it work if you roll back to last week's version?

Here's how I do a "clean" profile: Start Firefox. (First off, rename your original profile back) Type "about:profiles" in the address bar Click "Create a New Profile" Give it a name; e.g., "Clean Profile" and let the browser build it Under the newly created profile, click "Set as Default Profile" (do not click "Launch Profile in New Browser;" it won't be entirely "clean") At the top, click "Restart Normally" Do your testing To switch back, do steps 2, and 5 and 6 again with your usual default profile You can keep the "Clean Profile" for later tests of this sort. If it works with a clean profile, you can create yet another profile, then start adding back your add-ons, etc. until you find out what's causing the problem with Skype.com.

On a hunch I decided to check skype.com's TLS status at Qualys.com's server test site. This will take a few minutes. I'm sure skype.com will get an A; what I'm interested in is the handshake simulations. Maybe they've "upgraded" security in a way that FF 52.9 doesn't support. Edit: Well, it may have been a nice idea, but ... no banana. Simulation shows FF 49 on XP SP3 successfully connects to both skype.com and secure.skypeassets.com. So it doesn't seem to be a TLS issue. I guess that makes sense, because you can get to the logon screen, but it was worth a shot. BTW, the SSUAO for skypeassets.com doesn't seem to be necessary after all. I just tried without it and was still able to log in. Any chance you could test @roytam1's Serpent? If it works, we'll at least know it's something about the browser, not your PC or location.

I use identical Chrome 73 on Linux SSUAOs for three sites:

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?