VistaLover

Machine translation to English for those lacking access to on-line translators:

They should've been disabled by default, according to the Wiki: "Experimental filters" is now, of course, a moot point, as, if you did leave them at their default setting (disabled), they'll soon vanish altogether from available filters... FWIW, manual re-introduction is possible via URI: https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/experimental.txt

uBlock Origin "Legacy" v1.16.4.14 (stable) has been released: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.14 (uB0 updater worked OK at the time of posting, I did not have to upgrade manually... )

@Mathwiz : Hope you're doing fine in the new year ; when you first posted this some days ago, I was genuinely puzzled, but since I was occupied with other matters, both in digital (!) and real life , I left it aside for future investigation; my contribution to the subject at hand was simply which basically links to the old Bugzilla bug #967977 Today I had some extra time and decided to search the official UXP GitHub repo/issue tracker, to find proof which substantiates the report that: (them in that context refers to TLS Session Tickets/TLS cache); I've searched specifically for code that sets the hidden pref security.ssl.disable_session_identifiers to true, but my search was, alas, fruitless... I then browsed @roytam1 's forked UXP repo, both branches (master+custom), for similar code signs, but to no avail, again ... So, by simply going with public source code, I found no clues that the default behaviour in either (official) PM28 and/or (forked) NM28 is to disable TLS session tickets, as you suggested... But you are not to blame yourself , I have myself in the past "slipped" in a similar fashion... ; the blame lies on the OP, for causing undue confusion over a "supposedly" new-found issue, most likely self-inflicted: ... was the post that started all this ; as part of my investigation, I have downloaded said NM28 build (BuildID=20200104010047), as well as the one after it (BuildID=20200110230556) and guess what one finds by visiting https://www.howsmyssl.com in a brand new/fresh (browser) profile: and So, nothing has changed in NM28 with regard to TLS Session Tickets, they are enabled by default (which yields the green "Good" button in that test page) ... Once more, it was simply @msfntor 's troll-ish behaviour in posting unchecked/unverified untruths, which ended up wasting people's time...

... According to: https://nakedsecurity.sophos.com/2020/01/09/browser-zero-day-update-your-firefox-right-now/ disabling IonMonkey JIT by setting: javascript.options.ion;false will get you covered , but with a (slight) performance penalty, of course... The linked article mentions that mitigation only in relation to the Tor Browser (and until the time it gets updated, which it did), but that same "about:config" pref is apparently present in FxESR 52.9.x, which, as we all know, won't be patched...

If my understanding is correct, it might be already in with the latest 2020-01-11 build: "above" refers to https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1176055 where it's stated: The "patch" you refer to is platform wide, so it should be present in all latest UXP applications (NM28, St52, MN, BN); Moebius (St55) had to be treated separately...

I'm on v1.16.4.14b2 since yesterday My installation was on an extremely heavy New Moon 28 profile: tens of extensions, many userstyles installed (within Stylem), many userscripts installed (within GM-for-PM), that means it's not a "snappy" profile to begin with ; so I can't make any remarks regarding uB0 related performance issues... I guess the proper thing to do is to install ONLY the beta on a fresh NM28 profile and then submit it to various benchmarking tests; but I couldn't be bothered, to be frank For more info, I'd keep an eye on https://github.com/DandelionSprout/adfilt/issues/7 https://github.com/uBlockOrigin/uAssets/pull/6808/ https://github.com/gorhill/uBlock/pull/3765

Special message from upstream: https://forum.palemoon.org/viewtopic.php?f=1&t=23605 (and https://forum.palemoon.org/viewtopic.php?p=181666#p181666 )

... Trouble's in the air for uB0-legacy : https://forum.palemoon.org/viewtopic.php?p=181590#p181590 ... and following posts... Betas of v1.16.4.14 : https://github.com/JustOff/misc-pm-stuff/releases/ (... but the "on-the-fly" rule conversion to the old format, supported in uB0-legacy, does result in performance degradation... )

... However, you can delay its installation for as long as you like : https://www.askvg.com/windows-10-tip-block-or-prevent-automatic-installation-of-microsoft-edge-browser-via-windows-update/ (... but this would not be a smart move security wise, as M$ will no longer release security patches for the "original" (EdgeHTML/Chakra) iteration... )

Whatever you do, please don't re-block ATI radeon drivers. I'm even getting good acceleration in an old W2k box ... Please understand Roytam1 doesn't block graphics drivers on his own, only upstream do... FWIW, https://github.com/MoonchildProductions/Pale-Moon/commit/b7841e5 was pushed to mitigate crashes on Linux, as reported in https://forum.palemoon.org/viewtopic.php?f=37&t=23512 But previous commit was reverted by Moonchild on Jan 10th, via https://github.com/MoonchildProductions/Pale-Moon/commit/b4a6053 ... which @roytam1 might've missed by a narrow margin (was published on GitHub at 202001101821UTC) ; in any case, nothing to fear on Windows...

Thank you, - I've set now New Name, boolean, in Moebius 55. Some relevant Firefox documentation, for the curious... which links to the corresponding Bugzilla bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=967977

Oh my God, am I turning into a Matt A. Tobin clone?

"safebrowsing" (as well as Tracking Protection) was/is a Mozilla Firefox feature that is reliant upon Google APIs/services; Mozilla, as is vastly known, rely heavily on Google to collect revenue, so they had agreed on "gluing" this feature onto their browser... It is currently only relevant to FirefoxESR 45.9.x & Serpent 55/Moebius forks and it's still present in (forked) Moebius because MCP had abandoned the platform before taking the time to remove it... In UXP browsers builds, these Google provided services (i.e. Block dangerous and deceptive content => Block dangerous downloads + Warn me about unwanted and uncommon software) have been removed by MCP and, if you ask me, that is a blessing in disguise... This is just me, but I consider (evil) Google to be a malware by definition, so I wouldn't want to be given advice by them on what web page to visit and what file to download... The average Joe, using the latest Firefox (in Win10, no doubt...) only gets a (false IMHO) sense of security because all-knowing Google are taking care of him in the background ( ) ... Common sense is to be exercised here, of course backed-up by an otherwise updated/secure browser engine, a set of updated privacy/security extensions, including in-browser content blockers (but not a myriad of them...), a supported and up-to-date Security Suite OS-wide and I humbly think no-one's in need anymore of the ever spying/tracking Google... You are entitled to a different opinion, of course ; as said, these are only my own views...

Another common mortal here, but I think we've had enough of that same ol' mantra of yours ; you keep revisiting/reciting the same demands, and I imagine you'll keep doing so unless you have it your own way, pretty much like a spoiled child that keeps crying to have its needs met ... Common/mere mortals as in browser users (and, mind you, common/mortal browser users are only using the latest Google Chrome version on Win10/Android these days...) are expected to follow and apply detailed and easy to understand instructions others have compiled to mitigate known issues in the niche browser builds they're using in their niche (as in outdated/unsupported by vendor) Windows OSes; those instructions aren't meant for developers, just users! FirefoxESR 45.9.x and patented decoders support => detailed instructions posted (by me and others) to enable it via Adobe Primetime CDM or LAV Filters DLL files (takes 5min of your time, max...) Arctic Fox and patented decoders support => this fork is originally meant for MacOS, where h264/aac support is native to the OS; added code is probably needed to accomplish this for Windows, especially for XP... uBlock0-legacy on BNav => you need only a code/text editor to open/modify/save its "install.rdf" file according to instructions given; other mere mortals here in these forums can, why aren't you willing to? Doesn't take more that 1min, max... ... "Without your intervention?" This comes across as quite disrespectful to the massive effort exerted by the maintainer of several browser forks; aren't you willing to make yourself even the slightest of efforts? It appears you only want to be spoon-fed, so that your stomach is kept full without "your intervention"... Grow up! To all others: I apologise for the rant-ish nature of my post, but I had to vent...

uBlock0-legacy 1.16.4.13 has just been released: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.13 Once again, we have to thank Ukrainian developer @JustOff ( ), who is part of the MCP devs team (though not inside Moonchild's immediate circle...): https://github.com/gorhill/uBlock/commit/0f3c467 If you prefer to let his extension, uB0-updater, do the update for you, make sure it's in its latest version, 1.6.8

Thanks for that! Thanks for that second confirmation ; it isn't that I doubted @WinClient5270 's initial report (of course not! ), just that I began questioning the validity of what I had learned via Qt's official documentation on supported Windows OSes... Added thanks for your attempt at explaining this (still considered by me as) oddity; FWIW, any (other) application built on Qt 5.7+ has more chances not running under Vista than the opposite... Festive greetings!

... But mere mortals running Vista SP2 32-bit are, once again , excluded from even trying to run that application on their Vista copy... If you had tried on (regular) Windows XP SP3 32-bit with lowering the subsystem version in the PE header to 5.1 (it's set to 6.0 by default), I guess a similar error, pertaining to win32 apps, is to be expected, as the application is NOT win32, compiled to be only runnable in the 64-bit architecture... What I can see , based on your attached screengrab, is that the app was compiled using version 5.9.7 of the Qt Framework, which in itself provokes major surprise on yours truly... ; I have always known, and that knowledge is based on official Qt documentation, that the last Vista-compatible version of the framework was 5.6 (5.6.3 to be exact!), and only on client machines : https://doc.qt.io/archives/qt-5.6/supported-platforms.html ... whereas v5.9 of Qt has zero support for Vista (and, of course, XP): https://doc.qt.io/qt-5.9/supported-platforms.html Any explanation as to how a Qt 5.9 built application is able to launch under Vista SP2 64-bit is highly welcome (if somebody can provide one ) ... For official system requirements, see @win32 's post; so, your assumption is not correct, as Vista (64-bit only) isn't officially supported! Given that the PE-header in the main executable is set at a subsys version of 6.0, at least our beloved OS was taken into consideration in that regard, but who can say which NT version the actual build-time compiler optimisations were targeting? As detailed above, I remain quite sceptical this is indeed running under Vista SP2 64-bit... OT: I hope you all had a great Xmas Day, surrounded by your loved ones; best wishes for the New Year, too!

The site maintainers do not support the UXP-based browsers; use a pure Firefox based SSUAO, if on New Moon 28/Serpent 52.9.0 (though you did not provide any clue yourself regarding which browser you encountered this artificial block with ; why are help seekers always being stingy in giving out details about their configuration?... ). E.g. FirefoxESR 68 (the latest supported ESR) on a Win7 64-bit host: general.useragent.override.vintom.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Proof on New Moon 28 32-bit run on Vista SP2 32-bit:

@Cixert : The "Preferences" (no file extension there!) file is the one that stores your custom browser preferences (modified from their original default values) and, as posted, should be found within your "Profile" folder, usually under ".\User Data\Default" First, BACK UP that file to a secure location in your disk, before you attempt messing with it manually; any such attempt should be made with the browser exited! The file itself is in a human-readable "pretty-printed" JSON format; open with a proper text/code editor; search for string "accept_languages" It should be there (with, I suspect, zh-CN as the first/default choice in the official Chinese version of 360EEv11); if this JSON block isn't there in your case (but it should be in an already used profile where the user has selected the English language pack), then you should create yourself a nested JSON block for it... I opted to display pages in the Greek language, if available, first - for example, the Google Web Store[GWS], so my manually modified setting inside the "Preferences" file looks like below: "intl": { "accept_languages": "el-GR,el,en-US,en" }, That code means that whenever the page hasn't got a Greek version available, the browser will fallback to displaying the American-English localization of it, and so on (if you add additional locales in that line) ... (Save the modified file while the browser is closed, then launch the browser anew and check for the effect of your new "custom" preference!) Hope I've helped

Most sadly, the author no longer provides a 32-bit Windows installer, so Vista x86 users (like yours truly) are scr**ed ; last 32-bit installer for Hugin is from two and a half years ago, for version 2017.0 : https://sourceforge.net/projects/hugin/files/hugin/hugin-2017.0/Hugin-2017.0-win32.msi/download Merry Xmas to all (that observe it, since this is an international forum )

@msfntor : Have you ever heard of the saying: "Half-knowledge is more dangerous than no-knowledge at all" ? Because this is what's happening here: you dismissing/discounting what I post by presenting your half-knowledge... For the rest of you (I take it you don't want to be fully informed yourself, else you'd have already taken the needed steps to do that before displaying here your ignorance...): Except for the Safari desktop browser on Mac OS and its (Safari's) versions on the rest of the Apple devices, no other major browser brand/engine natively supports (yet) direct playback of AppleHLS streams inside an HTML5 player; this is true for both Webkit (Chromium and forks) and Gecko (Firefox and forks) based browsers. You can verify this fact by taking the HTML5 test in your browser (look in the Streaming section). Be that as it may, AppleHLS streaming methodology is very popular with streaming sites, in its various formats (there exist iterations with unencrypted fragments, AES-128 encrypted fragments (HLSe) and fully DRMed fragments (Apple FairPlay DRM); also, while initially fragments were placed inside the MPEG-TS container, in later implementations fragments can also come inside the MP4 container; of course there's ample info pertaining to HLS streams on wiki and elsewhere, use your search engine and become informed yourself, don't just take my word for it... ) Media streaming sites wishing to deploy HLS streams to the majority of non-Safari browsers (not inherently supporting those streams in HTML5) while still staying away of Adobe Flash NPAPI/PPAPI (a technology soon to be obsoleted), have to resort to using a third party library in their embedded HTML5 players, most notably some form of hls.js ; through this library (sometimes wrongly called HTML5-player "plugin"), a browser which supports 1) native media playback in HTML5, 2) native h264/aac decoding (either via WMF+OS codecs or some other implementation), 3) Media Source Extensions (MSE), can perfectly play AppleHLS streams inside a specially crafted HTML5 embedded player that the streaming site loads in the browser. Now, let's revisit Twitter in @roytam1 's Nightly ESR 45.9.18 that started all this... In my copy of the browser, h264+aac decoding support is enforced via the Adobe Primetime CDM v15 (see previous posts of mine, media.gmp.decoder.enabled;true); the browser does support HTML5 native playback (media.navigator.enabled;true) as well as MSE (media.mediasource.enabled;true). When you first access the Twitter sample page in a tab, you can switch-on Web Console (CTRL+SHIFT+K) so you can inspect what the Twitter page loads inside that browser tab; since the browser meets all 3 requirements for HTML5 HLS playback, Twitter sends it first its HLS-enabled embedded player, in the screengrab below it's the URI that contains the *.PlayerHLS11.en.* string. Once that is fully loaded, it requests from the media CDN the appropriate HLS master playlist, it's the first URI that ends in *.m3u8; the master playlist is then parsed and a suitable (depending on network+bandwidth conditions) variant playlist is requested from the CDN; it's the second URI that ends in .m3u8 in the screengrab, as you can see it'll fetch a 320x568p video resolution; when that variant playlist is loaded and parsed, the CDN will start sending HLS fragments inside the MPEG-TS container, see the first one represented in the first URI that ends in *.ts (and so forth...). SO WHEN I POST THAT TWITTER SENDS TO FIREFOX ESR 45 "APPLE HLS" STREAMS, I have the knowledge and means to back up my claims; but I thought I would never have to post such verbose proofs to convince the half-ignorants, who only know how to dispute what already posted... It's a pity really , given my helping record in these forums... So be it then...

And I will tell you, once more, that FirefoxESR (Nightly) 45.9.18 (by Roytam1) doesn't come with h264+aac decoders out-of-the-box; you have to download one yourself (instructions about Adobe Primetime CDM are to be found in a stickied thread in the XP forums, instructions/links for the LAV Filters DLLs are provided by Roytam1 himself and are to be found in a prominent location in this thread (which I've also linked to...); SIMPLE AS THAT! (Unless you consider spending 5min to install one of these "solutions" as a major inconvenience that will further deter you/anyone for that matter from using the browser(s)...) (For the record, you were also previously advised to "install" an appropriate h264 decoder by @Mathwiz, a "solution" you obviously chose to ignore... ) As for uMatrix, stick to it if it's "indispensable" to you, but don't automatically assume it's the browser's fault (and by association the maintainer's bugged coding) when you keep facing various page-rendering/media loading issues; try to post such a similar issue in the official PM forums and you'll be immediately told (and not in a courteous manner) that it's not the browser's job to adapt to a particular extension, but the other way round (BTW, "legacy" uMatrix is an abandonware, as far as I am aware - a fork is available; and WE uMatrix, if that's the one you're using with FxESR45, hasn't seen any major action for quite a long time...). FYI, Roytam1 did not create his FxESR45 fork out-of-nothing, but it's mainly based on the original 45esr code by Mozilla; this is an old codebase, and there's only limited "things" one can do to improve it (Fx45 can't be turned into Fx52+ as if by magic); Roytam1 is focusing on improving TLS support there, plus other (minor) rendering fixes are backported from another fork; all these as a courtesy to members running old hardware that lacks SSE2 instructions set support; and it's often the case that those users are simply content when a specific page justs loads in the browser, having little or no desire to start in-page HTML5 MP4 playback (which could "fry" their old CPUs or just be practically unwatchable) ... Trust me, his life would be made much easier/simpler if he stopped maintaining these forks... And please, do not post any more HTML5 MP4 video testing sites, I have myself more than a dozen to suggest; all will work fine, as long as the browser they're tested on can use patented (h264, aac) decoders and the video sites are properly allowed to load their embedded HTML5 players... I am personally done with this specific issue of Roytam1's 45.9.18 fork not playing back MP4 video in OP's machine; anyone is free to pick up the baton and pursue it further... @msfntor : Joyeux Noël !

I've just finished re-testing latest Firefox (Nightly) ESR 45.9.18 (2019-12-07) (32-bit) and in my Vista SP2 x86 laptop: 1. The browser's WMF implementation is broken ; no matter the value of media.wmf.enabled (default is true), the browser can't access native OS patented decoders; hence, tests like https://demos.flowplayer.com/videotest/mp4.html fail on a stock profile/installation! So, despite being on Vista SP2 (fully updated codec wise), I still have to add to the browser a functioning h264+aac decoder, very much like in Windows XP 2. The two available choices for a h264+aac decoder to be added to roytam1's FxESR45 fork are: a. The Adobe Primetime CDM ; at least here on Vista, the browser fetched and installed the (first) older version 15 of the CDM; I double-checked the CDM is enabled in about:addons => plugins and that its decoder is also active, "media.gmp.decoder.enabled;true" b. If you don't have/don't want to install the APCDM, then you download and "install" (this is a local "portable" installation) the (linked on first page) LAV Filters DLLs (to be placed adjacent to firefox.exe) I have tried both methods (but not when both decoders are present and enabled ; you can disable APCDM from within about:addons (and its decoder from within about:config) but, AFAIK, you can't disable LAV Filters in any way other than removing them from main appDir); both methods yield a working h264+aac decoder (various HTML5 MP4 tests succeed). As for Twitter in particular, the sample video page does load successfully https://twitter.com/i/status/1160137655524270080 without messing with the User-Agent, but, probably due to older JS+CSS support in FxESR45, the PLAY button does not stay visible on-top of the embedded HTML5 player (I have "media.autoplay.enabled;false" so that video clips don't autostart ; however, if you click on the clip area, the video playback will successfully start (with an MP4 decoder properly "installed" beforehand): So again @msfntor, your inability to achieve Twitter clips playback is due to something particular to your FxESR45 profile and your OS version (XP SP2 x86); check if Twitter plays in a default FxESR45 profile with ONE of the two MP4 decoders properly installed - it is uncertain yet whether APCDM (v15/17) and the LAV DLLs work as expected under XP SP2 32-bit; it may be only one of these solutions works for you! If you can successfully install one of the two solutions, then, as instructed, check in an otherwise untouched browser profile; if Twitter plays (with a DIRECT connection, don't use Proxies/VPNs), then it's something else you've changed! Twitter normally send HLS streams, these require a working Media Source Extensions (MSE) implementation in the browser you're testing with; in FxESR45 verify: media.mp4.enabled;true media.mediasource.enabled;true media.mediasource.mp4.enabled;true And I repeat: Less Is More; I only use uB0-legacy in most browsers, I don't feel I need more "protection"... Me humbly thinks uMatrix causes you more trouble than it's worth ... And one last comment, if you will: @roytam1 , God bless him always , provides a wide selection of browser forks, to cater to various user cases; but you don't have to have (and test) all these browsers on your system! Stick to the one better working/most suitable for your browsing habits/needs (I personally alternate between NM28/UXP and St52/UXP, occasionally using St55/Moebius, since my CPU does support SSE2).

He wrote: ... so by "latest" it could only be firefox-45.9.18-20191207-082eb5b14-win32-sse