Mathwiz

Personally, mine are all at the default, except I do set dom.serviceworkers.enabled to true. But I keep service workers on a tight leash with this uBO filter: *$csp=worker-src 'none',domain=~mediafire.com|~html5test.com|~routerlogin.net|~mega.nz|~boonchapman.com|~archive.org That filter keeps them blocked except at the listed sites. Some of the above sites (including my home network router!) require them to work at all; others have workarounds if service workers are disabled. Generally, if I try a new site and it doesn't work, I try adding the domain to the filter above first. If that fixes it, I leave it on the filter, otherwise I remove it and resort to 360EE, figuring it's just another "Googlized" site.

Thanks! Instagram is basically a black box to me - no idea how it does what it does - but that's a clue. I too have uBO (legacy version 1.16.4.30), which is likely why the videos work for me. My guess is, uBO blocks some useless tracking script (after all, that's what it's for), and the blocked script happens to break Instagram videos on St 55 but not 52. Probably because it uses some Javascript feature that 52 supports but 55 doesn't (perhaps modules). In any case, installing uBO is a pretty easy fix, and would probably work in vanilla FF 52.9 also. I think to install uBO in FF 52.9, you have to turn off signature verification: in about:config, set xpinstall.signatures.required to false if you haven't done so already. FF 52.9 will show a "nag" in about:addons about the "unverified" add-on, but uBO still works perfectly.

Go to about:config and try creating string pref general.useragent.override.olx.ua and setting it to Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:79.0) Gecko/20100101 Goanna/4.8 Firefox/79.0 Basilisk/52.9.2021.07.19 This tells olx.ua you're running Firefox 79 on Win 8.1. This is often all it takes to fix "too old browser" type messages.

Well, it gets weirder: seeing @msfntor's post, I just tried two of the Instagram videos he linked to in Serpent 55 - and they worked! So either Instagram fixed something (in which case, their videos probably started working again in FF 52.9 too) or @roytam1 did (before 17 Dec 2021, which is the date of the St55 version I tried). Now if only we could get St55 and FF Sync talking again....

I haven't used Sync in so long I wouldn't have realized that! Pretty certain it used to work, though - I wonder what broke it, and if it can be fixed? That is correct, making 52 useless for users of Firefox Sync. So, unless 55 can be repaired (and it appears that it needs two fixes now: one to fix Instagram videos and one to repair Firefox Sync), SeaMonkey 2.49.5 is your last hope.

Drifting a bit further off-topic, but he piqued my curiosity: I followed @VistaLover's instructions and the troublesome page now works on 360EE v13.0, along with the promised nag: So JS is clearly the problem (and NoScript is looking like the probable reason for @luweitest's success) but 360EE v13.0 is based on Chromium 86, which I'm quite sure is newer than the oldest version of that particular page, archived on Aug. 2017! So I tried the page again, in honest-to-goodness M$ Edge on honest-to-goodness Win 7, and it's broken there too! Well, at least it isn't specific to XP/Vista, but what the heck are they doing (or trying to do) anyway? I still suspect M$ sneaked some JS onto their pages that they knew would cause them to break on the Wayback Machine. (Gees, wouldn't it have been easier to have just used robots.txt?) Luckily only 19 scripts blocked on the oldest version, so time to start searching for the "bad" one.... ... and the winning uBO filter is: ||web.archive.org/web/*js_/https://support.microsoft.com/app/content/bundles/application$script,domain=web.archive.org (I changed the date stamp to an * so that - hopefully - this uBO filter will work on other M$ KB pages with this issue.)

Yes; that's even better. That link works without having to time hitting "Stop," and even the links within the page are active! M$ probably added some JavaScript and/or CSS to the "new" KB articles that (intentionally?) blocks them on the Wayback Machine, and the latter never adapted. As it happens, I already had the files that this update supposedly installs, and from what I read, it looks like if I hadn't had them, I would've had problems installing updates long ago. So I'm good. But for some reason the update doesn't show up in my update history, so I wasn't sure until I could read the KB page and see what files were involved. Only thing I'm still curious about is how @luweitest was able to view the (new) KB page well enough both to quote it and include a link, apparently unaware that the link wouldn't work for the rest of us! Maybe using NoScript?

Agree with all the above. 360Chrome does everything except the Firefox Sync part. As far as 1) viewing Instagram videos and 2) using Firefox Sync, SeaMonkey 2.49.5 seems to be the only XP browser that does the trick. But there are other Web pages that SM fails on too, like Facebook. So whatever XP browser we choose, we have to give up something. Way back on page 3 of this thread, I figured out (I think) the UXP fixes that let Instagram videos work on browsers like Serpent 52: It'd be nice if that set of fixes could be merged into Serpent 55, which AIUI still uses Firefox Sync. Or, for that matter, into "straight" FF 52.9!

Well, it's better than nothing. I just can't believe how frustrating Web browsing on XP has gotten, even with Chrome!

Well, this is a thread I didn't think I'd ever see bumped again! But I guess folks occasionally reinstall WinXP, and sometimes things go wrong with the updates. First I want to show you what the above link looks like on Serpent 52: Useless. What about 360Chrome? Well, I briefly see the correct page - but it quickly reverts to the same useless crap above. Even with Chrome, the Wayback Machine lets me down! Attempting to go back to an earlier version, August & Sept. 2019 just return captured 404 pages, and May 19-28 just lock up the browser - and now I've lost the cursor here on MSFN! I never realized the Wayback Machine could screw up a Web browser so badly. The harder I try the worse it gets! I lost all my opened tabs on the last browser restart! Could someone please explain the magical secret to actually viewing this archived Web page?

Sorry, I misread your posts. Instagram videos do seem to work in Serpent 52, so maybe it is the same old problem after all. (I confirmed it also works in SeaMonkey and IceApe, so it will probably work in New Moon 28 too.) Many moons ago I opined that, since there are still FF 52.9 users, they needed a more permanent fix than updating UserContent.css every time this happens. The UXP browsers are great, but folks may not be willing or able to move to Pale Moon's browser syncing infrastructure. SeaMonkey 2.49.5 works, and still uses the Mozilla browser sync infrastructure. The UI is somewhat different, but you might try it. (To play videos, you'll need to transplant the same two .dll files as you did for FF 52.9.)

Uh-oh; I think the video issue is a different problem this time than before. Last time, it broke in FF 52.9 (and Serpent 55), but worked in UXP browsers (Serpent 52 & New Moon 28) and in SeaMonkey 2.49.5 (the final "official" Mozilla browser for XP): ... but I think you mentioned trying Serpent 52 on the @roytam1 browser thread, and said Instagram videos now don't work there either. So for the moment, it looks like 360Chrome is XP's only Instagram option. Oops; see below. I misread @Dave-H's posts on the other thread.

If you mean restore site-specific user-agent overrides to FF 52.9.1, this old post explains the trick:

It's bug 1737470. From Mozilla: Emphasis in original. MailNews and IceDove (and Navigator and IceApe, which include them) are likely to be affected, but not pure Web browsers like Mozilla's Firefox, MCP's Basilisk and Pale Moon, or @roytam1's builds of them. Serpent 52 runs fine on Win 7, so I expect it would run fine on Win 8 also. It's basically Basilisk with support for Win XP/Vista, WebExtension add-ons, multiprocess mode, and container tabs retained. MCP is canceling Basilisk but I don't think they're canceling UXP, so Serpent 52 should continue to benefit from UXP improvements. I expect addons.basilisk-browser.org to go away though, so that site might be worth archiving while we can.

The fact that the ArcticFox always-on status bar disappeared at the same time that Serpent 55 slowed down is pure coincidence! There is no "common denominator" between Serpent 55 and ArcticFox. They are based on completely different Firefox forks and are getting different updates. Ah, whatta team; here are the Serpent 55 changes between the 202010130 and 20210327 builds, according to @roytam1 himself: (Snipped from "My browser builds, part 2" since MSFN won't let me multi-quote a post from a closed thread, even to reply in an open one) I doubt updating the Twemoji font had any effect, and the first change would only affect the about:support page. The third is the "security" update, but it looks to me like all that was updated was: time zones, top level domains, "pinned" public keys for a few Web sites, and a preloaded list of sites with HTTP strict transport security (which converts http: requests to https: requests on those sites). Checking github.com, I also see a couple of minor changes: one affects WebRTC, which I doubt you're using; the other appears to affect how the "stop loading" button works. Unless I'm missing something, I don't see how any of those changes would affect the browser's performance noticeably.

Interesting. The user agent from (obviously 32-bit) Serpent 55 running on 32-bit Windows XP contains no "Win32:" Mozilla/5.0 (Windows NT 5.1; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/20210125 I'm a bit surprised that specifying Win32 in the OS slice has any effect on how a Web site interprets the user agent. A Web site should assume Windows running Firefox (or a variant like Basilisk or Serpent) is 32-bit unless explicitly told otherwise! But I'm sure a lot of Javascript parsing code is written improperly, so it may be worth putting in "Win32" even if you already are running a 32-bit version of Windows, particularly if you're spoofing a fairly recent Windows or Firefox version. The Javascript developer may be substituting their own assumptions about Firefox UAs for what Firefox actually does. Most sites probably won't check the Javascript functions navigator.oscpu or navigator.platform. Mozilla's currently preferred functions simply parse the user agent, so changing the UA "should be" all you need to do; however, many folks know how to override a user agent, but not as many know about those other two overrides, so it's probably best to override them too, "just in case" some Web site doesn't trust the user agent. WOW64 is for 32-bit browsers running on 64-bit OSes. (The usual reason for doing this is to run 32-bit plug-ins.) If you have a 64-bit OS, you can see the WOW64 by running, say, a 32-bit version of Serpent without an override and checking the user agent with a site like https://www.whatismybrowser.com/detect/what-is-my-user-agent.

Thanks for the explanation. NirSoft to the rescue: I set this command to run daily in Task Scheduler: nircmd setfiletime Config.xml now now It worked! Until last weekend, that is. Then it unexpectedly froze again, looking like this: The only thing that changes now is the background gets lighter during daytime and darker at night. I tried resetting my location, but it remains stuck on last week's forecast no matter where in the US I set it to.

Well, if any web sites are doing that, it's pretty stupid! The "bitness" of your OS doesn't say anything about your CPU speed, or number of cores, or how much RAM you have (only that you might have 4GB or more). But it wouldn't surprise me either - you could probably infer that "on average" a 64-bit OS runs on a "better" PC than a 32-bit one, and web sites do lots of stupid things, it seems.... Anyhow, depending on what you want to spoof, here's what general.oscpu.override should contain: Windows 64-bit (64-bit browser): Windows NT x.y; Win64; x64 Windows 64-bit (32-bit browser): Windows NT x.y; WOW64 Windows 32-bit: Windows NT x.y And the OS slice of your user agent should match. Here's what general.platform.override should contain: Windows 64-bit: Win64 Windows 32-bit: Win32 This came from developer.mozilla.com. As I mentioned elsewhere, in the particular case of spoofing "official" Basilisk, you should spoof a 64-bit browser on a 64-bit OS (option 1 above), because it's only available as a 64-bit build. And the Windows version should be at least 6.1, because that's the oldest Windows version "official" Basilisk will run on. (Serpent, in contrast, is available in both flavors, and will run on anything from XP forward.) Edit: As pointed out recently in this thread, the struck words are no longer true. "Official" Basilisk is no longer developed by MCP, and the new developer does release 32-bit builds.

Very late reply, I know; but if you want to be consistent, general.oscpu.override should be the full OS slice of your user agent; i.e., Windows NT 10.0; Win64; x64. And general.platform.override should be Win64. My understanding is that the Javascript functions they affect have been deprecated, but Serpent still supports them and some Web sites may still use them. If they're not consistent with each other, the site may realize something's up and refuse to work. Also, weird discovery (at least with Serpent): while SSUAOs take immediate effect, the global general.useragent.override pref requires a browser restart after changing it! Apparently it's read into memory at startup and not checked again.

I was never able to get the polyfill add-on to work quite right on Serpent 55. Latest version works on 52 (except not in multiprocess mode). The kludge I've been using is a "classic" add-on called "Open With" that lets you open links with other browsers. I set up a command to open links in St 52 using a profile set to single-process mode. It's not ideal - I have to right-click and select the single-process mode command manually - but it's still way better than keeping two browser windows open and copying links between them! I barely know any Javascript and add-on programming; certainly not enough to reprogram the add-on to parse the link and select the correct command automatically. I do wish we could get some UXP enhancements ported to 55. Perhaps some talented programmers could pick up that project! 52 supports container tabs, but not the container tab add-on that automatically opens sites in the desired container. It's a WebExtension add-on that requires at least FF 53.

The above were instructions for spoofing an "official" Basilisk version, which is a 64-bit app. As you can see I also spoofed Windows 8.1 (NT 6.3) as is my custom, although MCP should be OK with any Windows version from 7 (NT 6.1) on. It occurred to me, though, that MCP might try adding some JavaScript to their add-ons sites in order to foil XPers like most of us. If that happens, you may need to set a couple more prefs: general.oscpu.override;Windows 6.3; Win64; x64 general.platform.override;Win64 These spoof the same Windows version in a couple of old JavaScript functions. (The functions have been deprecated but Basilisk / Serpent still support them, so MCP might well use them.) Replace "6.3" with the Windows version of your choice (but at least 6.1) in both the user-agent and "OSCPU" overrides.

There may be a bit of a language barrier here. I don't think NHTPG was asking about changing user agents randomly; but rather, has anyone tried specific user agents with the specific Web site (nitter.net AIUI) you're having problems with? Some Web sites require very particular user agents; perhaps nitter.net is one. If it is, then a random user agent would just ensure that it usually won't work!

Yes, of course, but technically, doesn't everything fall under the "etc." category? I'm joking, of course; but seriously, I don't think @roytam1 intended that as a criticism of your post. Rather, I think he just thought those MCP actions deserved particular criticism. Section 12 of the DMCA is bad law that invites abuse; nevertheless, filing DMCA claims against forks of open-source software is one of the most blatant abuses of the DMCA I've seen. MCP may have a defensible claim of trademark infringement against Male Poon, but AIUI the DMCA covers copyright, not trademark, infringement. (That said, IANAL and may be completely wrong.) And AFAICS @feodor2 followed all of MCP's trademark rules with his MyPal browser, and still got taken down, which IMO reveals the "branding" issue that MAT often raised against Roytam to be a red herring. I agree. (Neither do Mozilla or Google owe XP anything, for that matter.) But I think what should be objected to is MCP's quite open hostility toward those who distribute forks of their browsers that do run on Windows XP and Vista. Mozilla and Google don't care; why should MCP? MCP should just do their own thing. If others want to fork their software, well, that's the price of forking Mozilla's software in the first place! But they're so egotistical that they consider a fork with any alteration, no matter how minor, to be an implicit criticism of their decisions. MAT never liked Roytam's forks, but he really started blowing his stack when Roytam decided to revert MCP's decision to remove WebExtension add-on support from Serpent. "What? How dare you do something differently than I? Don't you realize I am perfect?"

Probably nothing particularly special about Basilisk except the Australis UI, but Serpent is the only UXP browser that supports (at least some) WebExtension add-ons, multiprocess mode, and container tabs. Maybe a few other things I've forgotten or am unaware of. Regarding the Australis UI, I do use Classic Theme Restorer to "tone it down" and make it a bit more PM-like; yet Australis lets me customize the UI in ways I can't easily do in NM or BNav. That said, you can do 90% of everything Basilisk can do in other UXP browsers, so it's largely a matter of personal choice. Anyhow, as long as the UXP platform evolves, there's no reason Serpent can't evolve along with it, Basilisk or no Basilisk.

I'm not the one installing phpBB on my Web server - you are! So I'd say it's up to you to tell phpBB off! Tell them "the latest version of phpBB breaks compatibility with Chrome 78 (or whatever browser), but doesn't offer an improved user experience; why did you do that?" (And if phpBB claims that forcing users to update is for their own good, because of "security," feel free to reply that no one made phpBB your users' parents.) If they get enough complaints, they may back off the "Googleisms for Google's sake" a bit. Come on, let's have a little rage against the machine here!