VistaLover

... This has been already previously covered many a times in this thread ; in the case of New Moon 28, which is built from code on the UXP master branch, you shouldn't be using the official language packs destined for officially released stable Pale Moon versions: http://addons.palemoon.org/language-packs/ Instead, one should install the most up-to-date pack offered at @JustOff's GitHub repository: https://github.com/JustOff/pale-moon-localization/releases (at the time of writing, 28.6.0_RC1 is the most current release); if the installed LP becomes incompatible with a new NM28 release, one has to disable it (via Safe Mode, if browser won't start at all) and thus return to the default en-US GUI, until such time as an updated LP becomes available in the linked GitHub repo (or, if you're qualified, try to fix it yourself by looking at "*/locales/en-US/*" string changes in the official GitHub changelog and then porting these to your installed package...).

LAV files provided by @roytam1 are only meant for NEW MOON 27 builds! They are not compatible with NM28! I would instead look at the state of your Vista install; is your system FULLY updated (at least up until the official EoS updates, April 2017)? If it is, then (patented) system decoders should have been put in place in the context of Windows Media Foundation (WMF) framework and once you visit the youtube HTML5 player test page with New Moon 28 (28.6.0a1), you should have all checkmarks ticked in blue background... Also please verify media.wmf.enabled;true and media.ffvpx.enabled;true (both are the default values). FWIW, the Live stream on your test page (https://www.kan.org.il/) starts and plays fine here on New Moon 28 (I am left slightly behind at an older version, 28.5.0a1 (32-bit) (2019-03-29), since I mostly use Serpent 52 these last weeks, due to restored WidevineCDM support ) EDIT: I would also check for overzealous script/content/ad blockers; this has happened to me quite often in the past, where an embedded video wouldn't load unless I (temporarily) disable uBlock Origin ...

The ultimate "solutions" page : https://www.jeffersonscher.com/ffu/armagadd-on_2_0.html FirefoxESR 52.9.1 (technically a "tinderbox" build intended for developers) will gladly accept language packs from official release 52.9.0: https://ftp.mozilla.org/pub/firefox/releases/52.9.0esr/win32/xpi/

Some more background to the story... As many of you will remember, Firefox 51.0.1 was the last stable release officially supported on both XP and Vista; after that, the Fx users on said OSes were forcibly migrated to the FxESR 52 channel (it starts with 52.0esr build; but I can't recollect precisely at which exact esr version the migration was performed; it might've have been 52.0.1esr or 52.0.2esr etc.). Though not officially supported on XP/Vista, all three stable builds 52.0, 52.0.1, 52.0.2 will install, launch and run under those OSes; many users at the time (including myself) chose to manually install a stable 52 flavour, for the duration it was being current; of course, one could not go past 52.0.2 in the release update channel, since 53.0.x wouldn't install/run under XP/Vista. Several XP+Vista users were left stranded on one of the stable 52.0.x versions and, via telemetry, Mozilla were made aware; sometime during the middle of the 52esr support cycle, Mozilla decided to first migrate those users to a pseudo 52.0.3 stable release, in essence simply changing them to the esr update channel (where Mozilla decreed they should've been in the first place), and that would then invoke an automatic update to the then current 52esr release... FxESR 52 codebase is pretty much derived from the stable 52.0 codebase, so yes, the Windows XP "checking" code with regards to e10s is there, too... ICBB to check for relevant Bugzilla bugs, but if memory serves me right, blocking e10s on XP had to do with conflicts when graphics hardware acceleration (via D3D9) was ON in Firefox (about:support -> Graphics -> Features: Compositing); whether it is enabled by default or not has to do with your gfx card (and whether its driver is at its most updated version); I can't test this myself on XP, but in theory, if you manually disable gfx acceleration (Options -> Advanced -> General -> Browsing -> (untick) "Use hardware acceleration when available" and then RESTART the browser!), you should ( ) be able to activate e10s under XP the standard way (i.e. without "force-enabling" it). Firefox 53.0.x was never meant to run on XP/Vista (HINT: It can be made to run on Vista if you "install" the zip package and then patch the main executable so that the subsystem version is lowered to 6.0 from 6.1; system patented decoders via WMF are inaccessible though, because 53.0 doesn't check for Vista's WMF implementation, which is slightly different to Win7's); so the Mozilla devs had already removed (another case of code clean-up) the XP/Vista checks; since Basilisk/moebius (ergo Serpent 55.0.0) was forked from a pre-53.0 codebase, that's the reason why e10s on St55 on XP can be activated the "standard" way (you don't get the "0/1 (Windows XP)" block). Basilisk/UXP (ergo Serpent 52.9.0) has had additional roadblocks put in place by Moonchild Productions to thwart multiprocess, as it's a feature they oppose to (and their stance has been explained in detail in their forum); that's the reason why trying to enable it by simply toggling browser.tabs.remote.autostart to true (and restarting) will get you the "0/1 (Disabled forcibly)" block; also, since Bk52 is not meant to run on XP, my educated guess is that MCP have already removed the e10s WinXP "checking" code in their forked (from 52.6.0esr) tree; again, lazy to check their code in order to verify this assumption... As much of the e10s code is still there in Bk52 (but planned to be gutted anyway in the near future), force-enabling e10s in current St52 should work! BEWARE: Pale Moon 28/UXP (New Moon 28) also comes with the pref browser.tabs.remote;false ; in contrast to St52, practically most of the underlying e10s code has been removed, so NEVER toggle that pref to true; you'll end up with an unusable browser and profile corruption! In Firefox 53.0+ and on Win7+, an additional process is spawned when e10s has been activated: this is the GPU_PROCESS (about:support -> Graphics -> GPU_PROCESS); this requires the Win7 version of D3D11 and, again, your installed gfx card has to be compatible... A fourth (if ipc.processCount;1) process can be spawned if the pref browser.tabs.remote.separateFileUriProcess;false is toggled to true... What is true for Fx 53.0 should also apply to St55 under Win7! Simply changing the value of the app.update.channel pref doesn't change already installed code (an installed esr branch build can't be magically turned into a stable branch one)! It only has two effects: 1. Change the reported channel in the "about:support -> Application Basics -> Update Channel" section (BTW, this is absent in St52). 2. Make the already installed build check for updates in the modified (if exists) update channel; while this "hack" could be used in Firefox versions some years ago to easily change channels, now it does not work for that purpose; Mozilla devs have implemented security checks in the existing updater.exe binary; each update branch has a different binary with different file hashes, so even in the event an update (in the "new" channel) is found (in the form of a *.partial.mar or *.complete.mar file), the update won't be installed by the previous (belonging to a different channel) updater.exe binary. The proper way to change update channel is by manually over-installing a build belonging to the desired channel; do note that changing update channels causes (possibly) irreversible effects to the previously used browser profile... Forcing multiprocess on unsupported platforms and configurations always comes with inherent danger; it is said so in the link I posted previously: https://wiki.mozilla.org/Electrolysis#Force_Enable So people, ALWAYS MAKE A BACK UP OF YOUR EXISTING BROWSER PROFILE prior to venturing into uncharted waters!

I am still on the 2019-01-19 (32-bit) build of Serpent 55.0.0 under Vista SP2 x86, and I could NOT reproduce what you reported ; I set browser.tabs.remote.autostart;true (default was false) dom.ipc.processCount;4 (default was 1) restarted the browser and with 21 tabs open (17 pinned, 4 normal, all loaded) I do have 5 basilisk.exe processes in TM: ?

Microsoft will have "dropped" Win7 in mid-January 2020, so, of course, they would find no justification for a new .NET FW release, 10 months after Win7's EoS, to have backwards compatibility with OSes they wouldn't service at that time ... I'm just lazy to check, but I suspect .NET FW 5.0 to require Win8.1+...

Kindly (re-)read my detailed instructions (again) in my previous post HERE I think it's all been explained in a clear, easy to follow, fashion...

Hello I don't currently have an answer to your queries, but here's a related older thread from 2017:

... For those with a curiosity to learn the finer details, here it goes: While browser.tabs.remote.autostart is currently the main pref that controls e10s activation in Firefox, at an older time when the feature was being developed (particularly in the Aurora/Devedition and Nightly branches) the Mozilla devs had introduced two related prefs to control e10s activation: browser.tabs.remote.autostart.1 browser.tabs.remote.autostart.2 so that they (the devs) could enable themselves e10s (when a user updated the browser build) on controlled user groups; telemetry would then inform the devs of the performance of the e10s code on said client machines... Those prefs would "ride the trains" (Mozilla speak for migrating code from Nightly -> Aurora -> Beta -> Release branches) all the way down to stable Firefox builds, where they would simply not work anymore as originally designed, since e10s activation had, by then, been delegated to only the main pref, browser.tabs.remote.autostart. The following screengrab is from one of the last Nightly 53.0a1 builds that would run on Vista: Config Descriptions v1.0.1-signed.1-signed is installed, so that about:config "Source Comments" are made visible... So the browser.tabs.remote.autostart.2 pref in FxESR 52.9.0 is just vestigial code from previous developmental stages, harmless on its own... As we know, @Mathwiz did plant over his FxESR 52 profile on both Serpent 52 & Serpent 55 (which it was discussed in another thread some weeks ago as not being the proper/smartest way of doing things), so that is indeed how that pref, unrelated to Basilisk/Serpent, found its way there...

I feared as much... As I wrote in my previous post, you should also set extensions.e10sBlocksEnabling;false ... but I told you to RESET that and restart the browser! This is quite ominous; it might indicate that the Mozilla devs have excluded Firefox installations on XP from being able to activate their e10s support the standard way; after searching Bugzilla for related bugs, I think I found it: [e10s] Block e10s on Windows XP Given that e10s is being blocked on XP, the only way to enable it (under XP) is to force-enable it, like @Mathwiz suggested: https://wiki.mozilla.org/Electrolysis#Force_Enable Hopefully, after a full browser restart, it'll work; if it isn't, I'm out of ideas TBH; but people on XP have indeed managed to make it work: http://wp.xin.at/archives/4103 (scroll down to chapter 2, Electrolysis / e10s; but don't use as high a process number (16) as in that article!) (More reading material: https://www.ghacks.net/2016/07/22/multi-process-firefox/ ) Cheers

@Dave-H Hi, I hope you had a nice Bank Holiday Monday! > The setting browser.tabs.remote.autostart.2 is also set to "true" Is that pref in bold? I don't have it currently in my FxESR 52.9.1 (32-bit) (buildID=20180905233201) copy; reset the pref and it should go away with the next restart... > dom.ipc.processCount = 1 That should be the default setting (not in bold) > browser.tabs.remote.force-enable = true You don't need that new pref per se, when existing prefs are set correctly; please, for the time being, reset it (and it should go away with the next restart) > browser.tabs.remote.autostart = true The default value is false, so if you've toggled it to true, the whole pref line should be in bold > I've still only got one process in Task Manager, no matter how many tabs I have open! Please load about:support and scroll a bit down to "Application Basics => Multiprocess Windows" It should report "1/1 (Enabled by user)"; if not, please post the exact message; if it's extensions related, I fear you fell prey to a blunder I committed in my previous post (now corrected!). When one (or more) of installed legacy extensions are not MPC-compatible, they'll block electrolysis (multiprocess mode, usually abdreviated to e10s), and a new pref will be created extensions.e10sBlockedByAddons;true To negate that pref you should set extensions.e10sBlocksEnabling to false Always restart the browser after modifying any process related pref Disclaimer: Force-enabling e10s when incompatible extensions are installed and active may introduce some instability to the browser behaviour; YMMV... Inside your Firefox ESR profile directory there should be an .ini file called extensions.ini ; with the browser closed, open it with a proper text editor and check whether a section labelled [MultiprocessIncompatibleExtensions] exists (if yes, it should contain a list of incompatible addon IDs; you can use the Extensions section of about:support page to identify the offending addons and you should probably disable them while conducting multiprocess experiments in your browser)... Cheers

Well, while what you suggested would indeed work for FxESR52, you need not create a new pref to initiate e10s; already existing prefs control multiprocess activation in the browser: browser.tabs.remote.autostart;false Toggling that pref (to true) and restarting the browser will enable e10s; in the event you have installed conflicting legacy extensions, you should also toggle (to false) the following pref: extensions.e10sBlocksEnabling;true (followed by a new browser restart) The number of additional processes can be manually configured via the following about:config pref: dom.ipc.processCount;1 The default value of 1 means that when e10s is enabled, one additional content process is spawned (two overall present in Task Manager); modify to 2 and you'll get three in total and so on... But the multiprocess support present in Firefox 52 (and UXP) is not that mature and increasing the value to high figures (>= 4) will probably result in adverse effects (e.g. I have experienced frequent crashes); also, the more processes you configure, the better CPU you should have (e10s works best with recent, powerful, hardware... ). JFYI, the Moonchild Productions developers are currently in the process of removing any multiprocess code still extant in their UXP code tree, as they do not endorse e10s; Pale Moon never supported e10s, the same fate awaits official Basilisk (and hence Serpent 52.9.0); this is being tracked in UXP issue #953

I could not reproduce this in Firefox 52.0.2/52.9.0esr/52.9.1esr, but I don't have NoScript installed either! But I can reproduce this behaviour in (latest) Serpent 52.9.0 (2019-05-03) if I disable javascript in the browser (about:config => javascript.enabled;false); when I then load linked page, it complaints about "requiring the use of scripts" (in red letters): but if I click the magnifying glass, lo and behold I am being redirected to https://www.microsoft.com/en-us/search?q= So, clicking the magnifying glass normally triggers JS code that the UXP browser can't handle , but removing JS out of the equation you get the redirection to MS's search portal ...

... Please understand I have nothing personal at you, you're just a typical example of the mindset exhibited by most help seekers; I also apologise if you felt personally offended, which wasn't my intention in the slightest; but do allow me to stick to my beliefs, which are properly expressed in the following (well known, I hope) saying: Give a hungry person one fish and he'll have his stomach full for a day; teach him how to fish himself, and he might never go hungry again... First of all, I do not consider myself a "software-pro" as you put it ; on the contrary, computing came quite late in my adult life and I was horribly clueless at first, having no-one in my immediate circles to help me towards that goal; many nights over many months over several years reading forums and receiving just minimal (usually) tips from more "educated" people on line was the way to get myself slightly more "comfortable" with computers and software and to this day there exist fields for which I unashamedly confess my total ignorance. Mind you, like you, I also had "more serious tasks than software-learning", but I did strive to find at least some personal time devoted to that It's only through educating oneself that the what-you-called "low-level" people will, over time, become "middle-level" people and even - why not? - "software-pros"; otherwise, those "low-level" people will forever remain in a help-leeching stage, seeking guidance for even the simplest of things in forum after forum after forum... ... and you're only seeing your own side of things, as a help seeker; don't you think the volunteers (not only here in this specific forum, elsewhere too...) offering the help have themselves more serious tasks to do than explaining things down to the finest detail to people not willing to do some of the needed work themselves? My stance on offering help is to give people the needed push towards the right direction (e.g. in the form of knowledge articles and related documentation), not hold them by the hand all the way to their final destination... To make it perfectly clear to those using the SSE variant of New Moon 27 (latest win32 build here), you need to download at least the MMX LAV files found here and, after decompressing, put them in NM27's installation directory (IOW, adjacent to main executable palemoon.exe); it is unclear from the instructions in the first page of this thread whether the standard LAV files (found here) would work with just SSE (but not SSE2) processors! ... Again, it should be self-explanatory if one cares to study already "provided" screenshot or even attempts to familiarise oneself with only the basics related to Developer Tools; but as we established, people need pre-chewed food spoon-fed to them: ... write .mp4 on the "Filter output" input field... ... and you are genuinely welcome...

... And that is (among other things) what I meant by saying: With version 0.1.1 you have a constant visual display of the number of tabs (both pinned and ordinary ones) open, and that number is being updated in real time whether you open a new one or close an existing one; no need at all to interact with the button (which I've placed in the far right of the tab bar itself). Once you let AMO update the extension to v1.4.0 (WE format), you end up with an implementation of the addon with what I regard as inferior functionality: by default, its toolbar button shows no tab number, until clicked that is... And again, as you found yourself, to update the number displayed after new tabs are opened / old ones are closed, you'll have to click, click, click... Not my cup of tea, thanks! Perhaps my wording was poor; the WE flavour of the addon (v1.4.0) might actually work as intended by its developer on Serpent 52 (and Firefox 52.9.1), so it's not a matter of Serpent's inferior WE API support in that sense; but the point I wanted to make is that if you let Serpent 52 contact AMO to check for addon updates, you might end up with unwanted updates being applied to some of them...

... On Serpent 52.9.0, it appears to be Javascript related (as Web Console and/or Browser Console would reveal): Clicking the Learn More link takes you to a MDN article: https://developer.mozilla.org/el/docs/Web/JavaScript/Reference/Errors/Not_a_function Possibly unsurprisingly (now that MS and Google have turned into best pals), clicking the magnifying glass works as expected in Google Chrome (51.0.2679.0 in my case): @roytam1: If it is reproducible in latest official Basilisk (52.0.2019.03.27), perhaps the bug should be reported to the official Pale Moon forum (but NOT by a Serpent 52 user), so that MCP are made aware and, hopefully, come up with a fix...

In UXP commit 33ebc88 , platform (i.e. Goanna) version was bumped to 4.2.0, so I think the Serpent52 repo packages starting with the quoted above (and including the latest one) should be renamed to properly reflect that change: basilisk52-g4.1.win32-git-20190427-3424afcca-xpmod.7z => basilisk52-g4.2.win32-git-20190427-3424afcca-xpmod.7z basilisk52-g4.1.win32-git-20190504-d9d9d1ed8-xpmod.7z => basilisk52-g4.2.win32-git-20190504-d9d9d1ed8-xpmod.7z (for brevity, only win32 packages mentioned here...) In its current incarnation, Serpent 52.9.0 is incapable of contacting AMO to check for installed WE updates; there are two about:config prefs that control extension updates, the first is the main one and the other is a fallback one, extensions.update.url extensions.update.background.url Due to MCP changes, currently both point to the Basilisk extension repository (ABO) : https://addons.basilisk-browser.org/?component=aus&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% ABO does not contain any WE addons; to mitigate that, if WE addons (from AMO originally) are installed in Serpent 52.9.0, you should change the value of at least one of those prefs to point to AMO; e.g. in my installation I modified extensions.update.background.url to have a value of 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=52.9&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% But in reality, the kind of WebExtensions compatible with Serpent 52 are, more often than not, previous/older versions that are not being updated and if they are, they (of course) target Quantum (Fx >=57.0) with its richer set of WE APIs (compared to the ones present in Serpent); so by contacting AMO you risk 1. Having a legacy extension installed in Serpent 52 get updated to a non-compatible WE version of it... (remember, even though Serpent may advertise itself to AMO as Firefox 52.x, it has only a subset of the WE APIs found in Fx 52 ). 2. Having a WE addon get updated to a non-compatible (WE) version of it. An example from my own usage is https://addons.mozilla.org/el/firefox/addon/tab-tally/versions/ The one version fully compatible with St52 is XUL v0.1.1 (you can find it in CAA); if you check for updates on AMO, you'll be updated to v1.4.0, of the WE flavour, that does not work as expected in St52! That is why I have configured Serpent to NOT auto-update installed extensions...

... YES, we know already! Please stop repeating yourself ad nauseam... As I wrote in my post: What is it exactly you don't understand? I think the saying "A picture is worth a thousand words" should have applied here... If you're not at all familiar with the browser's Developer Tools section, then educate yourself; basically, for the purposes of URL sniffin (detecting background URLs for media and other content), you really only need WebConsole (CTRL+SHIFT+K): https://developer.mozilla.org/en-US/docs/Tools/Web_Console ... and, on occasion, Network Monitor (CTRL+SHIFT+Q): https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor Load https://winfuture.de/UpdatePack in a New Moon 27 tab; in that same tab, open WebConsole, filter for ".mp4" (without the quotes) and then reload the page, followed by clicking the play button in the embedded web player; the link to the video itself should appear (https://videos.winfuture.de/16838.mp4) Right clink the link; you can copy the link (and use whatever download manager/extension already installed to fetch it to disk) OR you can opt to open it in a new New Moon 27 tab; if you have set up the browser correctly (LAV filters provided by roytam1 for SSE-only processors), it should start to auto-play; right-click the video and an option is there to save/download it! (<Personal rant>: I acknowledge most people here offering guidance/help do so on a voluntary basis, out of the goodness of heart, sacrificing valuable personal spare time... I'm no different ; but what really aggravates me is the lack of willingness on the help-receiving parties to do some of the "homework" themselves, learning things along the way; it appears that most people expect to be spoon-fed like a one year old toddler, this attitude never promotes one's own knowledge </Personal rant>)

=> // For Amazon Prime videos (forces use of Microsoft Silverlight plug-in) pref("general.useragent.override.www.amazon.com","Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Firefox/45.9"); I don't have an Amazon Prime Video (paid) subscription, so take this cum grano salis, but it was reported in the (official) Pale Moon forums that Amazon have updated their framework to now require the DRM API and, thus, having WidevineCDM present, enabled and up-to-date (>= 1.4.9.xxxx) is a prerequisite (no Silverlight fallback is possible anymore... ): https://forum.palemoon.org/viewtopic.php?p=163937#p163937 FirefoxESR 52.9.0[1] comes with a deprecated WV version (1.4.8.903), so it won't work under Vista+ (for reasons already discussed elsewhere, WV won't work at all under XP). At least for Amazon Music, supposedly a posted SSUAO would allow (for the time being?) a fallback to using Adobe Flash Player NPAPI: pref("general.useragent.override.music.amazon.com","Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15");

The (new) user preference name that should be input in the "New string value" pop-up field must NOT contain the last semicolon (;), it should just be general.useragent.override.whatismybrowser.com Do not edit pref.js file manually to create SSUAOs; ONLY use the native about:config editor as you were instructed in previous posts (mine and others')!!! As it has already been said to you, FirefoxESR 52.9.x DOES NOT CONTAIN ANY STOCK (default) SSUAOs, so it's quite natural that ANY SSUAO created in its about:config page should be labelled as user set (and thus appear in bold!); STOP looking at other people's images, if you can't tell yourself that the image there is from New Moon 28, which (and this has also been conveyed to you) DOES come with STOCK SSUAOs inside its config editor (which are non-bold when not modified, i.e. "default"). Please do exactly as you are being instructed, do not deviate one iota from my SSUAO guide (linked to also by @Mathwiz)! What you do with other about:config prefs (that control other aspects of the browser behaviour) should not be your focus in the SSUAO context! ================================ OT: I have a background of many years in education (Physics, Chemistry, Biology), I have to admit this is being one of my most hard "teaching" cases... No offence is meant towards the other party, I am simply lost as to how I can make this come across... I think I am done myself - assigning this to someone more able/patient at (over-)explaining things...

Don't you worry one bit! You're already very high in our admiration list (at least in mine, that is... ) for simply trying to target that OS...

... Both @Mathwiz and I have literally hand-held you in this... ; what I would suggest is temporarily quit trying, have a soothing drink or something and simply relax for a couple of hours... Then go back two or three pages in this thread and with a clear mind try to re-digest what has been already detailed in, hopefully, good English, sticking only to what is being documented in the posts and refrain, as advised already, from actions like trashing your current profile (via browser reset for instance); pay religious attention to about:config pref names, excluding typos... To re-enable SSUAOs in Firefox 52, only the program installation directory path is needed, don't mess with any of the browser profile files... By the looks of it, you have created the correct javascript files and placed them in the right locations; then, you only need access to the native config editor found in "about:config" tab - don't mess with the JS files or any other InstalDir and/or profile files! The about:support internal page will only display the GLOBAL user agent of the browser; that value would either be the stock browser value (e.g. Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 on WinXP 32-bit) or the value of the user set pref general.useragent.override (if present)... SSUAOs do not show up in the User-Agent entry in about:support/Application Basics, but do show up further down, under the Important Modified Preferences section. SSUAOs take precedence over the GLOBAL user agent (be it stock or user set); as instructed numerous times, right-click in an empty space inside about:config and choose New => String ; rather than typing there long pref names/values, I advise you to first create the correct pref name and value (please, doublecheck!) inside a .txt document and then just copy-paste them in the suitable fields (New string value -> Enter string value); hopefully, you'll make it right!

I trust more people here are familiar with the English language, am I right? https://browser.360.cn/ee/en.html (JFYI, also reported on the Vista forum a while back... )

... Again , this is most probably due to the lack of a proper installer for the XP/Vista Interlink fork (Mail News); my advice again would be to install official Interlink on a supported OS (default installation location and 32-bit architecture would be preferable), export the written key as a .reg file and then merge it on your XP machine; sadly, I'm not interested in testing that e-mail client, but modify the paths accordingly if the Mail News fork doesn't advertise itself as "\Binary Outcast\Interlink"... In the above case, you can always modify yourself the "Winapp2.ini" file locally, since it's open source: https://github.com/MoscaDotTo/Winapp2/commit/ff1cb36 Just my 2 eurocents, of course (auguroni )... EDIT: By inspecting more closely your CCleaner screenshots, I can now see that indeed Mail News does create "\Binary Outcast\Interlink" directories, so you should be fine with a .reg file imported from, say, Win7 x86... EDIT2: Since you also keep Thunderbird installed, you can probably figure out yourself what subkeys should be contained under "HKLM\Software\Binary Outcast\Interlink" by extrapolating from "HKLM\Software\Mozilla\Mozilla Thunderbird"; shouldn't be hard to create needed entries yourself

... You don't need an extension in NM27 to download that video to disk; it is being served through HTTPS progressive streaming, so you can use the browser's native Web Console (inside Developer Tools) and filter for ".mp4" links while loading the embedded player: The screengrab is from New Moon 27.9.6 32-bit (the SSE2 compile, running on Vista SP2 x86; you should be able to get the video download link on your SSE compile under WinXP, too! ).