VistaLover

The FoxyProxy extension checks for fp.isGecko45 = this.vc.compare(this.appInfo.platformVersion, "45.0a1") >= 0; because rudimentary authentication (with login credentials) for SOCKSv5 proxy was finally implemented in Firefox Nightly 45.0a1 when Bugzilla #1200802 landed: Accept SOCKS credentials in proxyInfo object The above condition isn't met for UXP apps (NM28/St52) and St55, because they use the Goanna 4.x versioning; but because UXP[Goanna4.x] was forked from Mozilla[Gecko] 52 (> 45.0a1), #1200802 code exists in the UXP tree and thus, by applying the patch fp.isGecko45 = true; the requested feature now works (same logic applies to Moebius[Goanna4.0] forked from Mozilla[Gecko] 53 (> 45.0a1) ) ... NM27 builds on the Tycho platform; Tycho[Goanna3] was forked from Mozilla[Gecko] 38 (< 45.0a1), and so is AF, thus the fix introduced by #1200802 is absent in the Tycho code tree; hence the FP patch doesn't work there... If @roytam1 was to apply, somehow, the fix from #1200802 to Tycho, then the FoxyProxy "patch" would also work in NM27 - however, the diff introduced by #1200802 involves modifying 20 files, it's unclear (to me) whether it would apply cleanly to Tycho and whether, ultimately, would work... @roytam1, would you care to try and hopefully compile a test build? I'm sure @Mabeso would be more than happy to test... Best regards

Methinks the UOC Enforcer file (user.js) hasn't been correctly installed, as both directories depicted are not the main profile directories of either New Moon 27 nor FirefoxESR 45! Page 1 of this thread says: To easily locate your main browser profile folder, use the browser's about:support internal tab, from there "Application basics" => "Profile folder" => "Open folder" button... E.g. for FxESR 45 it should be located at: "C:\Documents and Settings\Tualatin\Application Data\Mozilla\Firefox\Profiles\e0afyh62.default" Regards

... I'm sorry to hear that ; I'm completely unfamiliar with KM, though... If you're using the KM-Goanna3 fork by @roytam1, perhaps try with a different version of GM; caa:addon/greasemonkey/versions suggests v3.11 is compatible with Fx 38+, on which Tycho+Goanna3 was forked; unless GM v3.9 is the absolute max version that can be installed in KM-Goanna3... It would appear the ViewTube userscript is incompatible with that old a GM version - maybe it could be possible to edit/patch the script to force-make it v3.9 compatible (???); ask around...

The above extension is installed as part of .NET Framework 3.5 SP1 : https://docs.microsoft.com/en-us/dotnet/framework/wpf/app-development/firefox-add-ons-to-support-net-application-deployment#net-framework-assistant-for-firefox It can't be uninstalled the normal way via about:addons; more below: https://support.microsoft.com/el-gr/help/963707/how-to-remove-the-net-framework-assistant-for-firefox

The extension's XPI file is hosted on GitHub which, as you might know already, is now owned by Microsoft; it is a relatively big file (for an extension that is ), so it's probably consuming a big chunk of GH's bandwidth with its downloads - a "valid" pretence for them to request its removal from a free repository - IOW, I don't trust M$ one bit ; fortunately, the extension is just a database, the legacy addons themselves are being hosted on Waterfox servers... Aren't you able to even run the SSE-only compile of New Moon 27? Not even the ia32 (no-SSE) compile? Because CAA installs and loads fine here in New Moon 27 (the standard, SSE2+, build)... As for the legacycollector.org site/service, the alphabetical index resides here ; please give the URL proper time to load fully (it's all on one scrollable page; I guess this is a poor web design choice on the part of the maintainer ). The database for this site is humangous, circa 15 GiB, so not quite sure at what extent it could be saved in the Internet Archive... Of course, individual legacy extension users like you and me have one month (?) to save (both locally and on the IA) those addons they're interested in... The admin of the site has also generated a compressed archive of the whole site (in .tar.xz format, circa 8.23 GiB) and made it available over the Bit Torrent network (but not for long), for people wishing to pick up the baton...

... I've hinted about this previously in this thread: So, for browsers not supporting the WebExtensions iteration of ViewTube (e.g. NM27/28 or FxESR 45), it is necessary to first install an XUL flavour of a userscript manager (like GMfPM) and then proceed with installing the userscript (*.user.js) flavour of ViewTube...

You win! I sure am ; I was planning to post a detailed new article in the Vista forum (when my spare time permitted), but since you couldn't wait, I didn't want to come off as giving you the cold shoulder... FTR, the setup file itself (mpas-fe.exe) used to be (until and including Sun Oct 20th) dual signed (both SHA1 & SHA2 digest algorithms); that file is comprised by four other files: MpSigStub.exe mpengine.dll mpasbase.vdm mpasdlta.vdm mpas-fe.exe v1.303.1946.0 released on Fri Oct 18th was the last one to be itself and all of its constituents dual signed - engine version in that file was 1.1.16400.2 (as said, dual signed); this was the last version of mpas-fe.exe (and, of course, mpam-fe.exe for MSE) installable on a Vista SP2 OS without SHA2 code-signing support present! Later that day (in my timezone), new version 1.305.17.0 was released (might've been another 1.305.x.x version I missed prior to that ); while file mpas-fe.exe was still at the time dual-signed (but I could only see the SHA1 sig then), to my great dismay I discovered that running the file would not update my WD defs ; to cut a long story short, and after at least an hour of troubleshooting (which included dependency walker, as I was misled by what M$ did to the XP users of MSE/WD), I realised that 1. The 1.305.x.x series introduced a new engine version, v1.1.16500.1 2. While I could see SHA1 sigs for files mpas-fe.exe, MpSigStub.exe, mpasbase.vdm, mpasdlta.vdm, I couldn't for the engine DLL file, mpengine.dll, so I assumed it was only SHA2 signed. In the past, I wasn't that worried about files only signed with SHA2, other than the fact I couldn't be 100% sure the file hadn't been tampered with... For executables, a prior update, KB2763674 , made it possible to run them (although, in retrospect, not a clever thing to do if one is unable to verify EXE's signature...). But in the case of WD (and MSE), the anti-malware application has to verify (via the OS) the updated engine and definitions files (contained in the downloaded mpas-fe.exe setup) for it to load them; not being able to verify mpengine.dll, WD remained stuck at defs v1.303.1946.0 (with engine v1.1.16400.2) Since I was not running Avast, I decided to install (latest) SHA2 code-signing support in my OS and retry with the 1.305.x.x mpas-fe.exe files; it WORKED! It wasn't until sometime during Sun, Oct 20th, that M$ posted some relevant details in their now "rebranded" Security intelligence page: Intelligence my... behind (!) ; make no mistake - you read right: they had already broken mpas-fe.exe on Vista SP2 since the evening (UTC+0300) of Fri 18th... FWIW, latest (1.305.941.0) mpas-fe.exe file is itself only SHA2 signed, files MpSigStub.exe + mpasbase.vdm are dual-signed and files mpengine.dll + mpasdlta.vdm only SHA2 signed (i.e. still a mess! ) It isn't I have blind faith in WD's efficacy these days, I have a paid-for full Internet Security Suite (Kaspersky) as my line of defence, WD is kept going for "legacy" reasons; KIS doesn't object to WD being enabled, nor did it manifest any adverse symptoms after the update to Vista 6003. Windows Update is busted in this machine since the first week of July 2019 (still at build .6002 then), when M$ reconfigured things; in any case, only WD (delta) definition updates were coming via WU until that time (I don't have M$ Office 2010); and, as expected, even after installing both KB4474419-v4 and KB4517134 (latest SSU for WS2008SP2), I still have to manually update WD... Regards

I had to install recently the standalone KB4474419v4 file to enable SHA-2 code signing support in my SP2 system; I can, too, confirm it comes with raising the build number to 6003:

Addition: The above procedure may only be relevant for those who have not yet posted in this new thread; once one posts here for the first time, and according to one's own forum preferences, a "Notify me of replies" switch button should be present to the far left of the "Submit Reply" button - in the bottom of your newly composed post - turned to ON by default...

@S75: Welcome to the MSFN forums First thing you should ask yourself is whether you actually expect any legacy (XUL) version of the Pushbullet extension to work today; this extension relies on third-party infrastructure (secure logins to their servers, etc.) and they may have blocked old "unsupported" versions of their addon, on old "unsupported" browsers, on old "unsupported" OSes (you get my drift...) from even connecting to their service (for "security" reasons, no doubt... ). The latest version 347 of their Firefox extension is still available, but - as expected - in WebExtensions format, not compatible with New Moon 27/28, but possibly compatible with FirefoxESR 52.9.1 and Serpent 52/55: https://addons.mozilla.org/en-US/firefox/addon/pushbullet/versions/ In the remote possibility any XUL Pushbullet version is still functional, then CAA extension caa:addon/pushbullet/versions reveals that the latest legacy version 316 dates from Dec 28th 2015, while the last "supposedly" NM27 compatible version 179[.1-signed] dates from Feb 22nd 2015 The Tycho platform (forked from FxESR 38) on which NM27 is built doesn't support Jetpack SDK legacy extensions, and that was a decision made at the time by the Moonchild team of developers; so you can't directly install such extensions in NM27, as the browser itself warns you about... The tool pointed to by @IntMD was developed to mitigate that imposed limitation (among several others), but it does not work universally on all types of JetPack SDK extensions - don't ask me why, I'm not an XUL extension developer. Force-installing an officially unsupported extension via the aid of the MTT always carries an inherent risk of browser profile corruption! Do keep this in mind and act accordingly (i.e. back up!). Second, if the unsupported extension is force-installed (in [TEST] mode) via said tool, you have no reassurance it will function as designed... I have run some tests on my old NM27 version here, I first downloaded to disk file pushbullet-179-fx.xpi, selected it via MTT (about:addons => Moon Tester Tool 1.2.0 => Options => Select file...) and it was still impossible to install I then tried to do the same with latest legacy version 316, which claims to support Fx 38.0a1 - 49.*; since Tycho is forked from FxESR 38, we stand a fair chance of it being NM27 compatible; following the same procedure, file pushbullet-316-an+fx.xpi did manage to install successfully - but I can't vow about its usability... OT: I wrote this post with NM27 that I seldom use now (UXP forks are mostly used here) and discovered the MSFN post editor has several minor issues (absent on UXP) - but is otherwise functional...

I don't think you can have HW gfx acceleration for in-browser HTML5 MP4 video (and certainly not HW video decoding) under XP (please someone chime in if you know otherwise ) ... HW video decoding when the Adobe Primetime CDM is being used as a h264 decoder is not possible, even on WinOSes where the WMF framework is present (Vista SP2+; the browser there has access to patented video decoders) and a compatible GPU is installed...

iF I understood correctly, the ViewTube userscript generates direct links to Youtube video clips, which are then fed to the WMP NPAPI browser plugin; the plugin then simply invokes an instance of WMP11 loaded with the YT clip to be played back; however, WMP11 lacks native support for the formats (container and codecs) employed by YT; have you noticed ? You need to have installed an SSE-only version of K-Lite CP (or other Codec Pack) to enable WMP11 to play (at least) MP4 (h264+aac) youtube clips; is that requirement met in your setup? 45 is earlier than 48, so it won't work. @Mathwiz: The userscript variety of ViewTube will install and work in FxESR 45 if an appropriate userscript manager (legacy) extension is already installed there; what won't work in FxESR 45 (but will in Fx 48) is the WebExtension flavour of ViewTube (simply because rudimentary WE support was first introduced in Fx 48 ). Actually, many years before that! https://web.archive.org/web/20170304053612/http://www.interoperabilitybridges.com/windows-media-player-firefox-plugin-download

With respect , the maintainer of that page has already warned visitors that the original functionality of the test page is now broken, for reasons outside his control: where by "test cases" he actually means the embedded HTML5 video clips... You should move to an alternate HTML5 video playback test site, e.g. https://tekeye.uk/html/html5-video-test-page http://www.bbc.co.uk/html5 http://web.archive.org/web/20190805082454/https://www.youtube.com/html5 (currently web.archive.org is DOWN for me... )

... And their download page states (both Free and Pro editions): ... Makes one think they have purposely excluded (omitted?) Windows Vista from their support list... It's only when one digs further and visits the dedicated product page, https://www.partitionwizard.com/free-partition-manager.html and then scrolls close to the bottom of it, to the Technical Specification section, that one finds Windows Vista is indeed supported... Given the recent debacle about the Comodo IceDragon browser, detailed in another thread, I've started to grow weary of the System Requirements software authors put up on their sites, especially in what concerns Windows XP and Vista; for the record, ICBB to install and verify true Vista support in MTPW...

It's because of the recent change in the hostname; "o.rths.cf" => "o.rths.ml"

... and I honestly hope that isn't a recent screengrab, because the Engine Version and AV+AM definitions are very outdated ; http://www.microsoft.com/en-us/wdsi/defenderupdates latest Engine Version: 1.1.16400.2 latest defs version: 1.303.1880.0

Hello again ; I have never used the Android (mobile) version of Firefox, Quantum or pre-Quantum, so can't really tell if an import HTML bookmarks feature ever existed there; however, casual on-line searching dictates that the only way to import bookmarks from a desktop (Firefox) browser version is through Mozilla Sync. I guess you can still achieve what you want - if you limit your syncing to only a transfer of Serpent 52 bookmarks to mobile Firefox - if you use Firefox ESR 52.9.x on your Windows XP desktop as a sort of man-in-the-middle; you can still keep Serpent 52.9.0 as your daily browser, but only use Firefox ESR 52.9.x (with a simple default profile, without extensions) when you want to transfer bookmarks... Transferring Serpent 52's bookmarks to FirefoxESR 52 should be a trivial and straightforward process; I think both the HTML and JSON formats are supported (export to HTML file is the obvious route, but you can also create a bookmarks back-up file in JSON format, which can then be loaded/restored in FirefoxESR 52). Once you have successfully migrated your Serpent 52 bookmarks to FxESR 52, you can then use your Firefox Account credentials to log-in to Mozilla Sync, and then selectively sync the bookmarks present there with your Android Firefox version on your phone/tablet - should work! Of course, you are at the mercy of Mozilla, as I suspect at some time not far away they'll disconnect old & unsupported versions of the Firefox browser from their Sync servers... Greetings

Of course @burd is the one to clarify things, but I've seen this orange colouring of the MSE tray icon (in my sister's Win7 x64 laptop) when a System (quick) Scan hasn't been performed for a certain while - in an otherwise fully updated MSE installation; manually initiating the scan and after its successful completion, the icon colour should return to green (barring any issues found) ... Not very surprising if that is just a remnant of a prior Dropbox installation, at a time when the OS was still supported; for a brief period after the end of official support, the following post by @WinClient5270 was relevant: but that hack soon ceased to work ; if you look closely at the screengrab posted by @burd: you'll notice the dropbox tray icon being grey, meaning the desktop client can't connect to the service... But then I could be way-off-base... Regards For reference: https://www.dropboxforum.com/t5/Installs-integrations/When-will-Vista-no-longer-be-supported-by-Dropbox/td-p/261493

... Commiserations . Had you taken diligent preventive measures in your OS (e.g. a reputed anti-malware/anti-virus third party suite, coupled with a responsible browsing behaviour), chances are you wouldn't have been infected - but then again, no Security Suite is foolproof... Out of curiosity, was Microsoft Security Essentials (MSE) even installed and updated? Just to get this out in the clear, BORA is a ransonware with very strong encryption, so be prepared to part ways with your personal ENCRYPTED files... Slim chances do exist you can restore at least some of them, but... Every anti-malware software author has compiled at least one remove-BORA-infection tutorial on the net, this is what a simple G-search would reveal: https://www.google.com/search?q=bora+file+extension+virus&ie=utf-8&oe=utf-8 Follow your favourite one - be advised the more you use your infected computer, the less percentage of your original files you'll be able to recover (as they are being overwritten in your HD). Restoring an image back-up of your system and files (should that exist) is your safest bet - as far as I am aware, a simple System Restore (if enabled) won't "restore" personal files (like documents, e-mails, photos, etc...).

What one likes to do and what is actually feasible is, sadly, often quite different things... This issue has been brought up several times in the past, most recently in another XP thread: My own reply there: https://msfn.org/board/topic/180280-automatic-user-agent-spoofing-in-firefox-51/?do=findComment&comment=1171254 TL;DR: if you'd like to sync between the android version of Firefox (now in Quantum version 69?) and roytam1's Serpent 52.9.0 on a Windows [XP] PC, then it simply isn't possible anymore! You can reportedly still sync between Mobile Firefox and Firefox ESR 52.9.1 and, at least in theory, between Mobile Firefox and Serpent 55.0.0 If a mobile version of current Pale Moon 28 were officially available, you could, in theory, sync between Mobile PM28 and official Basilisk (52)/official Pale Moon 28 (desktop) - and New Moon 28; since Serpent 52.9.0 has retained support for WEs, sync between it and PM28 might only be partial ; but official mobile PM28 doesn't exist; please read these following relevant exchanges in the official PM forum: https://forum.palemoon.org/viewtopic.php?p=174199#p174199 (and the posts after that one...) https://forum.palemoon.org/viewtopic.php?f=39&t=21179 Regards

Could you clarify, please? Do you mean it doesn't launch at all under Windows XP with an SSE-only CPU, or that it doesn't offer the option to install the SSE-only flavour of the New Moon 27[9.6] browser? If it's the latter, I'm sure @i430VX will, at least, consider implementing this useful for you option in the near future; just keep in mind this is a volunteer project offered as-is and maintained during one's own spare time - not to mention managing a server to host it and the cost of the associated bandwidth...

Confirmed ; here's what Web Console in Serpent 52 shows: @roytam1, could you have a look?

Actually, I never said that; what I said was: i.e. I couldn't be sure off the top of my head whether VP9 support is present in Fx 48; I had to search about this, Implement VP9 video decoder in Firefox suggests VP9 codec support landed in Fx 28, ergo is indeed present in Firefox 48 . In any case, I've instructed you how to tell the video codec used in the clip reproduced in youtube's HTML5 embedded player; based on your report (and my search), VP8+VP9 ones should be OK; h264 (avc1) wouldn't play How one's own clips have been originally encoded and packaged (in what media container...) prior to uploading them to youtube is kind of a moot point, because once the original encodes reach yt's servers, they are being re-encoded (re-coded and/or trans-coded) to several different formats/resolutions, to be able to meet yt's dynamic streaming requirements; you can easily check this fact by using one of the several "youtube downloading" apps (e.g. the CLI youtube-dl) and see how your originally uploaded video (in a defined resolution, bitrate, container, etc) is now available in several "qualities". Google have recently (Aug 9th 2019) removed their very useful youtube/HTML5 test page, http://web.archive.org/web/20190805082454/https://www.youtube.com/html5 which was invaluable in troubleshooting HTML5 video playback in browsers (they've replaced it with https://www.youtube.com/supported_browsers and I suppose the reasoning behind the original's removal is that Google now only support latest versions of Firefox, Google Chrome, Edge, Opera - all these browsers had been, since long ago, passing the tests extant in that previous page with flying colours; of course, they don't care about older unsupported versions of browsers on unsupported OSes... ). As I said, the procedure outlined in the first post of this thread was tailored, tried, and known to successfully work in Firefox ESR 52, the last released for XP (but with an SSE2 capable processor); Fx 48.0.2 is not Fx ESR 52.9.1, so there might be other factors why the procedure doesn't yield the expected result in your case (???...) Perhaps some of the documented about:config prefs need to be modified for Fx 48? Some other(s) missing? ... Hard to tell; it would help if other SSE-only XP users could test and report back (to rule out it just isn't you..); @looking4awayout, would you possibly care to oblige, please...? Firefox 48 was at a peculiar spot with regards to Adobe Primetime CDM; Adobe had signaled Mozilla that their closed-source module wouldn't be able to be used on XP for its original purpose, i.e. decrypt DRM content, and that they (Adobe) would only continue its development targeting Vista onwards... The module itself had some unresolved bugs on XP machines that Adobe weren't inclined to fix; Mozilla OTOH did not have at the time a concrete plan what to do with it; they swayed between leaving it visible and enabled on XP (and Vista OEM) for MP4 decoding purposes, not downloading it by default on XP, hiding it completely on XP (just like they did with WidevineCDM) etc... So, as to what extent was/is AP CDM supposed to work in Fx 48, I can't honestly be sure... The module was at one stage upgraded from version 15 to 17 (16 was only an interim update for 64-bit Firefox), and then EOL'ed in favour of WidevineCDM; v17 had lesser bugs on XP, Mozilla decided to keep it alive a bit longer, until Fx 51; Fx 52 did not come with official support, nor would it download it by default; finally, the underlying support code was completely removed from the codebase in Firefox 53.0. Pending reports from other SSE-only users, I'd speculate that your failure is caused by the CDM's inferred dependency on a SSE2 CPU; while the browser itself may be fine with just SSE, the module might be needing SSE2 instruction set to function properly... I tried to find documentation to sustain my claim, but, sadly, Adobe have now removed almost everything related to the CDM ("help.adobe.com/en_US/primetime/drm/HTML5_CDM" now redirects to a recent page ); I stumbled upon a blog article by some Russian guy, https://weekly-geekly.github.io/articles/373803/index.html it's quite long, but inside it there's this part ... which I interpreted to mean: "set this pref to false, unless you have an SSE2 CPU and the Adobe Primetime CDM installed" ; so my bet is on Primetime requiring SSE2... It's quite a long shot, but perhaps you might try the previous version of the module, version 15, accessed via https://cdmdownload.adobe.com/firefox/win/x86/primetime_gmp_win_x86_gmc_30527.1.zip (if it doesn't need SSE2, then you might have a chance...) You are not left without other options ; several members here on SSE-only processors use @roytam1's Firefox ESR 45.x.x fork (but I'm not sure whether he has modded it for h264 support under XP) and New Moon 27-SSE; the latter does indeed come with h264+aac support, courtesy of custom LAV files you have to download separately and place inside NM27's main folder - just be sure to download the SSE-only flavour of the LAV .dlls (and I'm sure you know already, but security-wise, official Firefox ESR 45.9.0 is more secure than Firefox 48.0.2 ). Hope I've helped a little...

This assumption couldn't be more wrong... Youtube (i.e. Google) employ a variety of streaming methodologies and combinations of video+audio codecs, there's not a one-size-fits-all philosophy here... The older VP8 video codec is natively supported in Firefox, so is the newer VP9, but I'm unsure about its support in Fx 48 that you're using ; Firefox also supports natively the very widely used h264 (AVC1) video codec, but only on Vista SP2 (with platform update supplement); h264 support in Firefox implies Windows Media Foundation (WMF) framework, an OS feature absent in XP; the use of Adobe Primetime CDM in Firefox under XP is meant exactly to mitigate this missing OS feature, since the CDM comes with its own h264 decoder, which the browser can then use to decode unencrypted MP4 video... Right-clicking the Youtube embedded HTML5 player and then choosing "Stats for nerds" will tell you what codecs are being used in the streamed video; Additionally, MPEG-DASH streaming in Youtube (notably the high resolutions) requires the browser to support Media Sourse Extensions (MSE), but not all Youtube videos use that, some use the older "progressive download" type of streams; OTOH, live Youtube streams (may) use AppleHLS streams; so no, if one clip plays, it's not a given all the rest would also play... @vipejc is correct; YouTube have completely killed their Flash embedded player; I suspect those "older" clips that do play are in the older VP8 codec, supported natively in Firefox... If you head to about:addons/plugins (and even about:plugins), can you spot an entry for the Adobe Primetime CDM? if yes, is it always enabled? If there isn't an entry for it, something's gone awry in its proper installation... Any reason why not using Firefox ESR 52.9.1 (on which the procedure is known to work)?

... More rather a belated release to patch a vulnerability made public in September! https://borncity.com/win/2019/10/03/internet-explorer-cumulative-update-kb4524135-10-03-2019/ I'd still look out in the Catalog come next Patch Tuesday (Oct 8th 2019) for a newer IE9 cumulative update...