Mathwiz

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!

@soggi's post gives me a lot to think about. I certainly don't advocate "dumbing down" Web sites to the point that IE8 or Opera 12 can be again used! We have to find a middle ground somewhere. Generally, when a software developer (including Web site software) releases a new version, there are several kinds of changes that may be included: Security fixes and enhancements New functionality that makes the product (Web site in our specific case) noticeably better to the end user (e.g., much of HTML5) New functionality that's invisible to the end user. It's only the third category that's problematic. These improvements are the kind that can break compatibility with older browsers, OSes, etc. without any offsetting benefit to the users. For Web site software, improvements may offer benefits to the folks running the Web site, such as "improved" tracking that may increase ad revenue; or they may benefit Javascript programmers by providing features to simplify coding, or they may just be in there for "forced obsolescence" purposes. But in any case, they don't deliver a better experience to the end user; they only force potentially unwanted updates on him/her. Lately, my experience has been that most changes to Web pages are of the third kind. If you're using "modern" Chrome or Firefox, everything looks the same; but if you're using older browsers, one day things just break for no apparent reason. Those are the kinds of changes I'm saying developers should resist.

Well said! (BTW, one might point out that the (actual) left wing has plenty of problems with Google too.) But let me take (slight) issue with the following, as I think it leads to some interesting discussion: I think the problem there is the implication that a Webmaster must take special effort to keep their Web site compatible with older browsers. But that's not correct. Browsers are computer software, not mechanical devices; they don't just "wear out" and stop working without maintenance! All you have to do to keep a Web site compatible with older browsers is nothing! And the best part is, newer browsers will still work with the site too! That's exactly what I'd expect a "lazy" Webmaster to do! Instead, someone has to take special effort to change a Web site in order to make it incompatible with older browsers. But why would a Webmaster do such a thing, even if the "cost" is only a few dozen users out of thousands? (Seriously, I doubt BitChute gets millions, but the point remains.) I think that usually, they don't! Instead, they lease time/storage from a server farm (at AWS?) that just installs all the latest "upgrades" for them as they come out. Of course those "upgrades" intentionally break compatibility with older browsers, forcing their visitors to either upgrade too (possibly to a new Windows version) or stop visiting - but like the old Grecian Formula 16 hair dye, it's so gradual the Webmasters don't even notice it! Right! Except it's not really a conspiracy - a secret agreement to do something illegal - so much as companies each acting in their own self-interest; i.e., to make as much money as possible. But even without any explicit agreements, it has the same result: the whole industry keeps us on the update treadmill, buying new, more powerful computers not to do more, but merely to run the latest bloatware that spends the majority of our PC's CPU cycles trying to convince us to part with our hard-earned dollars.

Oops, I did it again! I tossed out an off-hand comment that I didn't like the content at BitChute.com, and derailed the whole thread! My apologies, but one statement made above deserves a rebuttal, as it seems to have started a bit of a panic here, and sounds suspiciously like it came from EMFScientist.org: Uh, no. Some scientists (at EMFScientist.org) are pretty concerned about 5G (as they were earlier about WiFi, Bluetooth, cell phones, microwave ovens, overhead power lines - shall I go on?), but the consensus of "most leading scientists" is that 5G, like all those other technologies, poses a minimal, if any, hazard to our health. Those interested can read a good article (from 2019, when 5G technology was first emerging) about the controversy here: https://sciencebasedmedicine.org/5g-is-coming/ (Emphasis added.) You're free to disagree, of course; but this will be my final word on this topic. If you try to troll me, I'll just plonk you. Hopefully most of you will relax a little bit about your new 5G phones now, and remove your tinfoil hats. Neither do I (and thanks for suggesting PMPlayer)! The problem wasn't modifying install.rdf - that was easy - it was getting the PMPlayer.xpi file in the first place, since you must get it from one of two Web sites deliberately configured to make that task difficult, or compile it yourself!