VistaLover

The CSS fix posted by @mixit is indeed needed in FirefoxESR 52.9.1 and Serpent 55.0.0/Moebius, but not needed in the UXP browsers (NM28, Serpent 52.9.0, Bnavigator) and latest SeaMonkey 2.49.5, because this issue is fixed in the respective platforms - don't forget that in NM28 and St52 browsers (at least), SSUAOs are needed for instagram.com (with a Firefox version < 57.0).

Exactly! Just to confuse things further, Google have done some re-versioning to their WV CDM and what were to be versions "1.4.10.xxxx" are now versions "4.10.xxxx.xx", 10 being the interface currently supported. Interface 9 CDMs were revoked, as announced, on Aug 13th 2019 (14th, if - like me - you're in Europe) and thus official Basilisk/Serpent 52.9.0, with internal support for only WV CDM v1.4.9.1088, was broken by Google Widevine license servers (they won't serve decryption keys any longer to revoked versions of the CDM); unlike e.g. NPAPI Adobe Flash Player, you can't just upgrade the CDM and expect things to continue to work, especially when only newer "interfaces" of the CDM are current; the "guts" of the browser have also to be updated accordingly, to support the newer Widevine CDMs. EME and WidevineCDM support in UXP (in practice, in Basilisk only) is being tracked in https://github.com/MoonchildProductions/UXP/issues/962 Their "media" (and Linux) dev, @trav90, appears to be having some serious issues in real life, which keep him still away from contributing code in the project; despite Moonchild's plans, he had to release Basilisk 52.9.2019.09.03 without fixing its broken Widevine implementation; for Netflix and Adobe Prime, Basilisk/Serpent users will have to use SSUAOs to fake older Firefox versions and then install/use the Silverlight NPAPI plugin (more in the official forums); of course, other DRM services without a Silverlight fallback provision will be simply BROKEN! Before Aug 13th, @roytam1's Serpent 52.9.0 (with WV v1.4.9.1088) and 360 Extreme Explorer (with WV v4.10.1196.0 manually installed) were, AFAICT, the only two working implementations of Widevine under the Vista SP2 OS; both these two WV versions have been now deprecated/revoked/blacklisted, the one current and whitelisted by WV lic servers is v4.10.1440.19; most sadly, the corresponding widevinecdm.dll file has been compiled by Google with optimizations targeting the Win7+ kernel only, so it won't work under Vista (this is easily verifiable via dependency walker in Vista); since the WV source code is a tightly kept secret, no-one can recompile it and make it again Vista compatible; so, WidevineCDM is henceforth a DEAD technology under Vista

... Please accept my most sincere apologies, both of you In my dirty SM profile, the AP CDM does indeed show up in both about:plugins and about:addons/Plugins; prompted by your reports, I then created a new, clean, SM profile and applied my instructions from here to install the CDM; lo and behold, I, too, couldn't see the CDM installed in either about:plugins nor about:addons/Plugins, though, as you both confirmed, the CDM does appear to be working as intended in "silent" mode! After comparisons between the prefs.js file on the dirty profile and the same file on the new profile, I did manage to find the culprit: My original instructions are missing one additional about:config pref: media.gmp-provider.enabled;true (boolean) I had added that pref in my dirty SM profile many months ago, in an attempt to install and use the WidevineCDM on SM under Vista SP2 (NPAPI Widevine on XP doesn't install/show up/work); SM, like the upstream Fx ESR 52.9.1, only supports version 1.4.8.903, which is now severely outdated and blacklisted by Google Widevine license servers ); this is the reason the mentioned pref was pre-existing (and overlooked ) when I started my Adobe Primetime CDM experiments in SM! The original instructions will be soon edited to remedy this omission... Sorry again!

Some points to be made: 1. If on Win7, you don't really need Adobe Primetime CDM as a HTML5 MP4 video decoder (on Serpent and/or SM); Win7 comes already equipped with WMF and M$ provided patented decoders for H264+AAC. 2. To test the successful functioning of Adobe Primetime CDM (as a decoder) on either Serpent (52+55) or SM under Win7 (actually Vista SP2 and higher), don't neglect to first turn off WMF in the browser's about:config ; in Serpent's case (as opposed to SM), don't also neglect to turn off the ffmpeg provided patented decoders, by setting media.ffvpx.enabled to false!

@TechnoRelic : I have the answer to your SM 2.49.5 issue of not being able to playback HTML5 instagram videos under WinXP: 1. Via the Adobe Primetime CDM a. [LATER EDIT: I was kindly asked to provide here a download link for the AP CDM files; links for those do exist in the "Enable MP4 (H.264 + AAC) HTML5 video in Firefox on Windows XP without Flash" pinned thread, so it isn't like it's hard to find them; however, I have opted to provide the original official link, straight from Adobe's servers: https://cdmdownload.adobe.com/firefox/win/x86/primetime_gmp_win_x86_gmc_40673.zip The link is still live and tested mere minutes ago - if you're wondering how I got there (because, tried as I might with web searches, I wasn't able to find it), it's by loading the following URI: https://aus5.mozilla.org/update/3/GMP/51.0.1/20170125094131/WINNT_x86-msvc-x86/en-US/release/Windows_NT%206.0.2.0%20(x86)/default/default/update.xml ... which is the URI queried by the internal gmp-manager of stable Firefox 51.0.1 32-bit under Vista SP2! ] Just make sure you do install the CDM properly inside your existing SM profile: ./<ProfileDir>\gmp-eme-adobe\17\[3 files, one of which is eme-adobe.dll] b. Create/modify accordingly the following prefs: media.gmp-provider.enabled;true (boolean) browser.eme.ui.enabled;true (boolean) browser.eme.ui.firstContentShown;true (boolean) media.eme.apiVisible;true (boolean) media.eme.enabled;true (boolean) media.gmp-eme-adobe.abi;x86-msvc-x86 (string) media.gmp-eme-adobe.enabled;true (boolean) media.gmp-eme-adobe.forceSupported;true (boolean) media.gmp-eme-adobe.lastUpdate;1500000000 (integer) media.gmp-eme-adobe.version;17 (string) media.gmp-eme-adobe.visible;true (boolean) media.gmp.decoder.enabled;true (boolean) media.gmp.decoder.h264;2 (integer) media.gmp.decoder.aac;2 (integer) c. Restart SM 2.49.5; head over to about:addons/Plugins and configure the CDM to Always Activate: If everything was done right, heading to https://www.instagram.com/p/B2Nb4FGFQZ8/ and pressing the white PLAY button, you should be able to view the video inline... (I tested this successfully under Vista SP2 by first toggling media.wmf.enabled to false, thus simulating XP) 2. Dirty hack, by using @roytam1's modified DLLs. All this was inspired from: http://forums.mozillazine.org/viewtopic.php?f=40&t=3040639 a. Download latest Serpent 52.9.0 package by Roy Tam b. Extract the .7z file to a folder, copy the following 3 files: mozavcodec.dll mozavutil.dll vcomp140.dll c. Locate your SM 2.49.5 installation folder - rename and back-up the original files mozavcodec.dll & mozavutil.dll (of version 52.9.1.7156) d. Place there the 3 aforementioned files, extracted from the Serpent package. e. Launch SM Now SM 2.49.5 should be able to use the patented decoders contained in the modded DLLs; so HTML5 MP4 should be playable! (not tested by me, though... EDIT: Just tested, and it works!) Best wishes

... It's all because of upstream changes: https://github.com/MoonchildProductions/UXP/issues/1124 This was again code clean-up, conceived and executed by Matt A. Tobin: Specifically, the DevEd Theme GUI breakages are due to: [Basilisk] Remove Dev Edition theme. Like you, I also happen to like the Dev Edition Theme over the default Australis one, even in my Firefox days; did you know there's also a light Dev Edition theme in FxESR 52 (with square tabs)? You just have to first install the legacy extension DevEdition theme enabler (v1.0.1), which then adds a Developer Edition entry in about:addons/Appearance; enabling that and restarting the browser will give you the light theme (attached snapshot); to change to the more familiar dark DevEdition theme, just modify in about:config the pref devtools.theme to dark (instant application). Mozilla in Firefox 53.0+ (not compatible with XP/Vista) had added the two DevEdition theme flavours as default themes, they had simply rebranded them as Compact Dark and Compact Light: https://www.askvg.com/2-new-themes-compact-dark-and-compact-light-added-to-mozilla-firefox/ But to achieve the same in Fx 52.0.x-52.x.x, you had to employ the help of aforementioned extension; I should also mention at this point that the maintainer of the now defunct browser project called Cyberfox had successfully backported this Fx 53.0+ feature to his v52.9.1 browser, forked off Mozilla ESR 52 code: ... i.e. whereas other developers liked to backport additional Firefox features, it is, once again, demonstrated how fixated the MCP team is at removing inherited Firefox features (Container tabs, Web Extension support, to name just some recent beheadings in Basilisk...) Given the underlying supporting code has now been axed, I don't expect the DevEdition theme enabler extension to work now with latest Serpent (52.9.0) builds (it was, with older builds such as 2019-05-31).

... It appears your chosen username is indeed reflected in the verbosity (or lack of... ) of your last post! Can you please tell us (... pun intended!) whether it is actually the x64 edition of latest mumble-1.3.0 that can't be launched under Vista SP2 64-bit? Thanks

... Actually, I could not reproduce this on my Vista SP2 32-bit Home Premium installation; grabbing MSIs from their GitHub repository, all versions 1.3.0rc1, 1.3.0rc2 and the stable final release 1.3.0 had no issues installing and (at least) launching properly under my OS : As I'm not a gamer myself, I can't really tell if the application works fully as intended! Seeing you're on Vista Ultimate x64, perhaps what you report is true for the x64 OS, when the mumble-1.3.0.winx64.msi installer is being used; other Vista x64 users may have to test, too... But on Vista x86, all appears OK thus far... (BTW, I believe the x86 mumble version can surely work in your x64 Vista OS, wouldn't it? )

Hi ; what you report is to be expected, not a surprise at all... ; let me explain: 1. SM 2.49.x is built on the Mozilla ESR 52 platform, same as Firefox ESR 52.x.x; for legal and cost reasons, Firefox doesn't come bundled with its own patented decoders (h264, aac), unlike Google Chrome (Google can afford the huge sums of money needed for the licenses payable to the MPEG group to bundle their patented decoders with the Chrome binaries). In order to decode HTML5 MP4 video, Firefox must access the OS-provided patented decoders (the cost of which is included in the price of the OS, i.e. Microsoft, rather than Mozilla, paid for it...) Unfortunately, the mechanism that gives access to these OS-provided decoders is Windows Media Foundation (WMF) framework, available only in Vista SP2 (with Platform Update + Platform Update Supplement) and higher, NOT in WinXP ; hence, SM 2.49.5 on XP can't decode HTML5 instagram video (or any other HTML5 mp4 video for that matter), as XP lacks WMF and associated M$ provided decoders. And no, installed codec packs won't do the job! If you like, you are faced with the same predicament as in the pinned thread below: This is just an educated guess on my part, but since SM 2.49.5 is FxESR 52.9.1 based, you could try and implement what is currently valid for enabling HTML5 MP4 playback in FxESR 52.9.1 under XP in the linked thread; not tested myself, SM 2.49.5 has no issues here (Vista SP2 x86) playing back [h264+aac] MP4 files... 2. The bnavigator fork has been built on the UXP application platform; but @roytam1 has long ago patched the platform to fallback to its own patented decoders when WMF is unavailable (the case of XP); the patented decoders in UXP, provided via FFmpeg libraries, are contained within a custom patched version of the ffvpx third party library; it's the same reason the other two UXP browsers, NM28 & St52, can also decode HTML5 MP4 files under XP... I hope it's clear now!

... It could just be a case of artificial blockage by increasing the subsystem version string in the binaries to 6.1; editing it back to 5.2 might make them work in XP+ x64; better check with the zip packages, if the installer is also blocked under NT < 6.1... But then again, it could be compiler optimizations targeting Win7+; in any case, dependency walker x64 (under XP/Vista x64) will reveal what the true case is...

... Yes, a major c*ck-up ; the links should have pointed to https://archive.mozilla.org/pub/seamonkey/releases/2.49.5/langpacks/win32/ instead of https://archive.mozilla.org/pub/seamonkey/releases/2.49.5/langpack/ (a plural number "s" is what makes all the difference in this case! ) BTW, you did mention in passing win64 SeaMonkey builds for v2.49.5, they state they require Win7+; it'd be challenging if someone made them install/work under WinXP/Vista 64-bit! Best wishes

... Did I not provide links to latest SeaMonkey 2.49.5 language packs in my previous post?

Hello ; I am indeed quite familiar with that project, though running it on Vista SP2 32-bit, for which minimal official support does exist (but the lead developer there is quite keen on axing Vista support soon... ); as far as I'm aware, the app is just a Python script that does support Python versions 2.7.x and upwards - Python 2.7.16 to 3.4.4 is, as you may already know, XP compatible, so one just has to install Python and then install SL via pip (which will also fetch all needed dependencies). How so? In most cases, SL uses native Python libraries/dependencies to extract stream URIs from pages and then either feed (stream) them to a media player of choice (I think the current default is VLC, but they are keen on switching to mpv (no longer XP+Vista compatible ) or save them to disk; in most cases, FFmpeg is just being used as a muxing application, to place elementary (raw) streams into a media container (usually Matroska) that can be handled by the player's input API... Please provide examples where FFMpeg+OpenSSL support is required for normal operation. FWIW, the provided FFmpeg binaries have been compiled with --enable-mbedtls, mbedtls being a rebrand of PolarSSL; it is a crypto open source library able to handle all the tasks managed by its OpenSSL counterpart... OpenSSL has a restrictive (non-free) license, so builds with it enabled statically can't be redistributed; using a build script to build custom binaries one will use on one's own machines, it is necessary to configure the build script with "--enable-nonfree --enable-openssl" (that's what I had to do with the media-autobuild_suite when it was still Vista 32-bit compatible - ca. spring 2017); @Reino does provide openssl win32 binaries in https://rwijnsma.home.xs4all.nl/files/other/ perhaps when placed alongside his FFmpeg binaries, they are being loaded in a dynamic fashion? (Added later:... probably NOT - just misled by the behaviour of the libfdk-aac DLLs... ) EDIT: When I started composing this post, @Reino's reply wasn't live; thanks for the detailed info there...

When Basilisk was first conceived as a Moebius Platform test bed browser application, the language packs from Firefox 53.0 did initially work (for their most part); but as MCP started deviating from the Mozilla code by deleting/relocating/adding GUI strings, the Fx 53.0 LPs (installed in Bk55/Moebius) quickly broke ; users did complain: https://forum.palemoon.org/viewtopic.php?f=61&t=17876 but the final word from Moonchild himself was: https://forum.palemoon.org/viewtopic.php?p=131106#p131106 Their view on things did not change when their Moebius "experiment" backfired and they had to start all over again with Basilisk (52.9.x) on UXP... Time now for me to be overly pedantic, but since 2.49.5 has been properly released, one had better look into the "releases" directory for official signed binaries and language packs: https://ftp.mozilla.org/pub/seamonkey/releases/2.49.5/win32/de/ LPs only: https://ftp.mozilla.org/pub/seamonkey/releases/2.49.5/langpacks/win32/ (FTR, I doubt the RC3 builds are any different to the final (released ones), apart from the signature, that is...) Perhaps @TechnoRelic has that link handy, since I know he's one of the few (?) users here of that fork... ; in any case, let us first hear what @AndreasB. is really after... Best regards

There are NO (official or otherwise) language packs for Basilisk! (and NO, FirefoxESR 52.x.x's ones won't work either...) - see my previous reply to @AndreasB. : ... And according to @AndreasB.'s wording, the query was for @roytam1-only maintained browsers; to this, I may point out the availability of the FirefoxESR 45.x.x fork, intended basically for SSE-only older processors; I faintly recollect weeks ago I directed one user of that to the Mozilla provided language packs, I think his response was positive: https://archive.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/ OTOH, I'm not following closely the development of the KM Goanna fork, perhaps users such as @siria can shed additional light on the availability of updated, working, language packs for that!

... Yes, posted links unfortunately yield last week's packages; may happen to the best of us! Correct links: 32bit https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod.7z 32bit SSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod-sse.7z 32bit noSSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod-ia32.7z 64bit https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190907-c6d625af7-xpmod.7z

... You shouldn't be, had you read more closely what I've written in my previous post (Hint: It depends on what the user setting is for Preferences -> General -> When Pale Moon starts: )

Hi and welcome to MSFN forums What you describe isn't a bug to fix but intended behaviour implemented by the Mozilla devs and thus inherited in the FxESR52 based UXP platform (so present in upstream Pale Moon 28 and forked New Moon 28); you can read more about it in the following SU question: https://superuser.com/questions/1183272/re-enable-the-multiple-tabs-close-warning-in-firefox-50 If you have configured NM28 to save and restore previous tab session when launching, then the following Mozilla logic applies: If this is not implemented upstream, then implementing it only downstream (in NM28) will cause the official Pale Moon language packs (maintained and provided by the Pale Moon devs and community) to break when installed in New Moon 28; we don't want this (and have avoided this breakage several times during the past months by not implementing downstream-only patches that introduce new strings - it may be done in Serpent 52.9.0 for which no official language packs exist, but it's undesirable in New Moon) . As suggested, best route is using a tab-related extension! I'm recommending Duplicate in Tab Context Menu, retrievable via the Classic Add-ons Archive (CAA) extension: caa:addon/duplicate-in-tab-context-menu Regards

Thankfully, I'm not seeing this here, not yet anyway - however, things do look grim in the weeks to come: 1. Today is the release date of Firefox ESR v60.9.0, the last member of the 60esr branch: https://www.mozilla.org/en-US/firefox/60.9.0/releasenotes/ v60.9.0 will become EoS on Oct 22nd, when v68.2.0 will be released (there won't be a 60.10.0, of course) and existing 60.9.0esr users will be migrated to 68.2.0esr. https://wiki.mozilla.org/Release_Management/Calendar 2. UXP's (platform) support for GitHub is based on the fact the javascript code they (GitHub) are serving to Firefox ESR 60.x.x (which they'll support until it reaches EoS) is still compatible with UXP (and hence with browsers like New Moon 28 and Serpent 52.9.0 built on top of it...). 3. Serpent 52.9.0 doesn't have a native SSUAO for GitHub, but if the following prefs are at these posted values: general.useragent.compatMode.firefox;true (user set) general.useragent.compatMode.version;60.9 (default) I find that GitHub still works at the time of this writing: I also find that a SSUAO for GitHub of the following format: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.0; rv:52.0) Goanna/4.4 Basilisk/52.9.0 also does the job if I set the previous pref to a value of 52.9 (Serpent 52.9.0 is really NOT Firefox 60.9 - this value was a setting implemented by MCP to achieve better compatibility with recent sites (which tend to use UA sniffing rather than browser feature set detection); actually, I feel better having the browser advertise itself as Fx 52.9 and then create as needed SSUAOs for those sites that break with that setting... When FxESR 68 becomes the only one available ESR branch, no doubt the sites implementing UA sniffing will raise the bar, so to speak, to demand Firefox 68.0 as a minimum Fx version; spoofing UXP browsers to Fx 68.9 in the state they are now may or may not work for those sites; if the sites update along the javascript+CSS code they serve to Fx 68.0, then that SSUAO hack won't work ; indeed, using a SSUAO for GitHub in Serpent 52.9.0 and making it pose as Firefox 68.0 (or 69.0) will give you grief, as GitHub will be broken . When we come to that point, we (using UXP browsers on XP/Vista) will be at the mercy of the Moonchild team; they'll have to successfully backport newer Javascript and CSS iterations to UXP (Pale Moon + Basilisk), so we can benefit, in turn, in the NM28 and St52 forks!

... My e-mail client on my 12-year-old Vista Home Premium SP2 32-bit laptop is, to this day, the default one provided by the OS, i.e. Windows Mail; while I rarely use today IE9 itself to browse the web, Windows Mail does use the IE9 engine to preview and display e-mails; without TLS 1.2 support present (in IE9), you risk having e-mails, certainly the ones in Rich Text (HTML) format, render broken, e.g. if in-line images are served exclusively over TLS 1.2! Using Windows Mail in 2019 might not be the smartest choice security-wise; but AFAIAA, very few current e-mail clients are being actively developed with Vista in mind; the one several of our XP friends have migrated to is the Interlink (a Win7+ client developed by notorious Matt A. Tobin) fork called MailNews, maintained by roytam1, the same dev who gives us New Moon 28 and Serpent 52.9.0/55.0.0!

... And if I added the figures right, that would be a sum total of HK$7447 (for those of us in the Eurozone , it's ca. 852 Euros; in Boris's UK, it's ca. 774 GBP; and in Trump's USA, make it ca. US$950); so, as I said some weeks ago when you announced this intended purchase, quite a small fortune it is! May you get every single cent out of this high-end hardware; congratulations for your new rig ; may you long enjoy it ! Greetings from 35 Celsius northern Greece

Bingo! ... Not to toot my own horn, of course, but I think I was the first (only?) person to have suggested the eventual connection of that directory to your reported issue; first here and then repeated here; so I feel slightly vindicated TBH . Anyhow, all's well that ends well Cheers

Basilisk is the upstream official browser application built on the UXP platform, developed and released by Moonchild Productions (supported officially under Win7+); Serpent is the generic name for an unbranded, unofficial, build of a Basilisk fork, in our case the fork (supported under WinXP+) maintained by our dear @roytam1 here in MSFN! Due to various development decisions made by both parties involved, the fork has started to diverge somewhat from the upstream application; some things/features removed by MCP (Tab Containers, WebExtensions support, etc.) have stayed in Serpent, so I can definitely say they aren't the same thing Hope it's all clear now!

... Skype for Web doesn't work in New Moon 28, even with a SSUAO; as advised previously, test either Serpent 52.9.0 or 55.0.0 Good to know! Cheers

There was no need to do that, because your original thread has already been migrated to the XP subforum, as per @Vistapocalypse's request! Windows XP forums: https://msfn.org/board/forum/34-windows-xp/ Your original thread (this one - migrated from the Vista subforum): Roblox is ending support for Windows Vista/XP => https://msfn.org/board/topic/179888-roblox-is-ending-support-for-windows-vistaxp/ Your newly started, duplicate, thread: Roblox is shortly ending support for Windows XP and Windows Vista => https://msfn.org/board/topic/179953-roblox-is-shortly-ending-support-for-windows-xp-and-windows-vista/ @dencorso, I am indeed sorry to trouble you, but I'm afraid additional housecleaning is in order!