VistaLover

@Mathwiz: https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L82 https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L927 We need the location of the code to be modified inside the Source Code, not inside the compiled application ...

The "instagram" issue in UXP browsers (NM28, Serpent 52) has been covered in fine detail in previous pages of this thread, when it first manifested itself ; it's a case similar to player.pl, that is due to new UXP defaults (general.useragent.compatMode.version;60.9), instagram sends JS code the platform can't cope with... The solution is similar to the one suggested for player.pl, i.e. use a SSUAO for instagram that advertises a Firefox < 60.0 version; DON'T touch the "general.useragent.compatMode.version" pref, just create: general.useragent.override.instagram.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

@Mathwiz For troubleshooting purposes, things are much easier when using portable packages/installations; for example, official PM28 (recently updated to v28.5.1) is being distributed also as a WinPenPack portable "setup" (in reality, an extractor): You can substitute the contents of the "Bin" directory (respecting folder tree) with latest NM28 binaries... The portable package comes by default with an empty profile (found inside the User directory); by running the portable launcher, you instantly get a pristine/default browser profile to test with! NB that this portable installation does not interact with your "installed" NM28 version, but they shouldn't be run concurrently while testing... When you want to start fresh with a new clean profile, just back-up/trash the previous one (while the browser is exited) and when you then re-launch Palemoon-Portable.exe, it's like the first time all over again

The same file mpengine.dll is used inside mpam-fe.exe (MSE manual definition updater) and mpas-fe.exe (manual definition updater for Vista+Win7's iteration of WinDefender); while MSE itself is NOT officially supported under Vista, Vista's native WD (for some undisclosed reason) IS, as one can see by visiting: https://www.microsoft.com/en-us/wdsi/definitions Microsoft Security Essentials 32-bit | 64-bit Windows Defender in Windows 7 and Windows Vista 32-bit | 64-bit So if M$ decide on breaking mpengine.dll on Vista (make it only Win7 compatible), they will intentionally quit supporting Vista's WD antimalware solution; but it's their prerogative, you know ; Vista has been EoS for more than two years, Vista users are currently at M$'s mercy (and if one of you "XP-ers" decides to visit MSFN's thread pertaining to installing Windows Server 2008 SP2 updates on Vista, one will clearly see that things have started falling apart recently... ).

Try to install it.xpi from: https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/ (not tested )

Nice catch (... and that's another reason why I always advise to check first on a new/clean browser profile in the case of found "issues" ).

... Dumb question, but has it been verified via Dependency Walker that the new engine file still remains XP incompatible? Engine version 1.1.16000.6 (file mpengine.dll) works OK under Vista SP2, too...

... Would you really? First, you'd have to acknowledge that Serpent 52.9.0/UXP and Serpent 55.0.0/Moebius are two different applications on two different platforms (because I often sense a notion, shared by many here, that they are, in fact, quite similar ...); the former is under active development by the upstream devs, while the latter only receives the occasional "experimental" update by its current maintainer... MCP have changed pref general.useragent.compatMode.version in St52 to value 60.9; this means that the Firefox portion of St52's UAS claims rv:60.9, this alone satisfies GitHub's needs and "github.com" should work out-of-the-box; with recent builds of St52, one does not need a SSUAO for Github per se: (on Vista:) Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0 unless the global UAS has been modified to something claiming older Firefox versions... semi-OT: To ensure better compatibility with the largest number of sites, I have turned ON both Gecko and Firefox compat modes: general.useragent.compatMode.firefox;true general.useragent.compatMode.gecko;true so my global St52 UAS reads: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Gecko/20100101 Goanna/4.2 Firefox/60.9 Basilisk/52.9.0 In the case of Serpent 55, the value of pref general.useragent.compatMode.version has remained at 55.0 (<60.0), additionally Gecko & Firefox compat modes are defaulted to true; this means github.com sees the client as Firefox 55: Mozilla/5.0 (Windows NT 6.0; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/55.0.0 , hence it gets broken and doesn't work out-of-the-box there... You have several options to restore GitHub on St55, the one I suggested was to use a SSUAO which doesn't contain any Firefox portions (github.com gets "confused" and serves moebius compatible code): Mozilla/5.0 (Windows NT 6.0; rv:55.0) Goanna/4.0 Basilisk/55.0.0 ... or you could modify pref general.useragent.compatMode.version to 60.0; in that case, the global UAS will read: Mozilla/5.0 (Windows NT 6.0; rv:60.0) Gecko/20100101 Goanna/4.0 Firefox/60.0 Basilisk/55.0.0 and github will work (but "instagram", "player.pl" and possibly others will break...). To conclude on this, my tests have shown that you can use in St55 the same SSUAO that works in St52 (which, as explained, doesn't necessarily need one!) to restore GitHub functionality; e.g., I just used Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0 successfully in latest Serpent 55.0.0

Latest Serpent 55/Moebius works fine on GitHub here, if the following SSUAO is employed for domain "github.com": general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:53.0) Goanna/4.0 Basilisk/55.0.0 Proof (new clean profile, no extensions): Forgiven ; but you did scare the cr*p out of me! I thought we were good at least until Quantum 60.x.x becomes EoS later in the year...

... What aspects of the GitHub site have now become broken for you? I had restored the SSUAO feature in FxESR 52.9.1 in the way I posted about previously (manual insertion of two local *.js files in the main app directory), my override pref for github is: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 and at the time of this post (June 3rd, 2019, ca, 22:50 UTC) I see no obvious breakage in github.com; but it might also be a CDN issue, i.e. the changes may have been first rolled-out in the Americas and have not yet reached the Europe github mirrors... Time will soon tell... ( On a related note, I see no github.com breakage in both UXP forks (NM28, St52) )

uB0-legacy has just been updated to version 1.16.4.11; those without uB0 updater installed, should download and install manually: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.11 Also, latest NM28-compatible language-packs have been (recently) updated to v28.6.0_RC2 : https://github.com/JustOff/pale-moon-localization/releases/tag/28.6.0_RC2

Have you, by any chance, tried GreaseMonkey for Pale Moon : https://github.com/janekptacijarabaci/greasemonkey/releases/latest (file greasemonkey-3.31.4-pm_forkBranch.xpi) ? Personally, in Serpent 52.9.0 I'm using latest ViolentMonkey (2.10.5) as userscript manager (of the WE type, still supported in St52 - but not official Basilisk/UXP).

It's controlled by pref app.support.baseURL default value is http://www.palemoon.org/support/ When you choose "Help", the browser tries to load http://www.palemoon.org/support/firefox-help which then auto-redirects to http://www.palemoon.org/faq.shtml

+1 ; in fact, I am indifferent to the whole "rebranding" hullabaloo ; personally, I know very well where I first learned about the existence of the Pale Moon fork (yes, that's what it is), i.e. this very forum/thread, I know very well where the compiled builds are hosted and where to download them from, I am well aware of @roytam1's GitHub repositories and blog, so I'd have to be senile to direct myself to one of the upstream sites for official support (especially given the fact how rude/hostile people there are to "intruders" ); OTOH, taking into account how similar the code is between PM and the fork in question, I have every right - if I wish to do so - to visit the official Pale Moon forum as an unregistered user and seek help there by searching already posted content; and, provided I have access to working official binaries, I might post an issue in the official github tracker (given I already have a GitHub account) if a bug I discovered in NM is reproducible in official PM; I won't, of course, make any mention of the fork on a non-supported OS; NB that Moonchild doesn't like people "littering" his tracker before the reported "issue" has been first filtered in his forum, but that's his own problem... To conclude, that is how far I would approach the official support avenues... ... New-name giving and artwork? Fine, if you like to occupy yourself with what is devoid of real substance ; there, I said it... (DISCLAIMER: No offence meant to members about to - once again - inundate this thread with new candidate browser names )

Cheers , you've come pretty close to the resolution of the reported issue; in fact, it's "instagram #2" deja-vu: the type of Javascript code to be sent to the client (browser) by the player.pl video portal is being determined by UA-sniffing; their poorly written site (which, by the way, is infested with third party scripts ) does not like any of the three user-selectable UA strings (testing with New Moon 28.6.0a1) : Native: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 PaleMoon/28.6.0a1 Gecko compat: Mozilla/5.0 (Windows NT 6.0; rv:60.9) Gecko/20100101 Goanna/4.2 PaleMoon/28.6.0a1 Firefox compat: Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Goanna/4.2 Firefox/60.9 PaleMoon/28.6.0a1 The JS code sent with any of the above UA selections renders the SEZON buttons for the Odcinki series inoperable (non-clickable); further troubleshooting reveals that that's because UXP can't handle the Firefox Quantum 60.9-specific code it's being fed ; a pure Firefox ESR 52.9 SSUAO for player.pl will make the SEZON buttons operable again, but when you first load the site you'll get a prompt to upgrade to a more recent (and supported) browser brand/version; you can dismiss that prompt and, hopefully, proceed to view... However, I've found that to make those buttons work as expected but not get nagged at (for running an older, unsupported, browser), one should use the "Firefox compat" string modified to report a Fx 52.9 version: general.useragent.override.player.pl;Mozilla/5.0 (Windows NT 6.1; rv:52.9) Gecko/20100101 Goanna/4.2 Firefox/52.9 PaleMoon/28.6.0a1 @Seba21 Please understand that your problem site is specific to Polish speakers and that most of its media content is geo-fenced for non-Polish IPs ; so it's quite difficult for members here that don't understand Polish to navigate that site, troubleshoot it and offer advice/solutions Be that as it may, I believe your issues can be cured by creating (in either New Moon 28 or Serpent 52) a Site-Specific-User-Agent-Override (SSUAO) for player.pl ; that procedure has been explained numerous times in this and other threads: Load about:config in a tab, promise to be careful Right-click in an empty space and choose to create a new "string" preference - a pop-up will be displayed As name of the pref, input general.useragent.override.player.pl and click OK - second pop-up will be displayed As value of the pref, input Mozilla/5.0 (Windows NT 6.1; rv:52.9) Gecko/20100101 Goanna/4.2 Firefox/52.9 PaleMoon/28.6.0a1 and click OK Close the about:config tab Reload the player.pl tab ... you should then be able to use your SEZON buttons...

@TechnoRelic @roytam1 has absolutely NO CONTROL over the mentioned URI; http://www.palemoon.org/unofficial.shtml is hosted on the "www.palemoon.org" domain, which is owned by Moonchild Productions; as you said, a tab with that URI loaded is triggered after an unbranded Pale Moon build (New Moon in this case) has been successfully updated (app version change). Actually, what gets displayed in that post-upgrade tab is controlled by the value of pref: startup.homepage_override_url For official builds, value is (string): http://www.palemoon.org/firstrun.shtml and, as stated, for unofficial (unbranded) ones: http://www.palemoon.org/unofficial.shtml What you suggest implies @roytam1 setting up (and hosting) a dedicated webpage with the changes you proposed; this can be a "minimal effort" solution with just some text and links, more effort required if artwork is involved (background and foreground images, logos etc.); the link to that webpage should be then set as value of mentioned about:config pref... In any case, you obviously lean towards "proper" rebranding of New Moon; MCP already direct unbranded build users to so those "clueless" ones are already informed (still, all these who can't be arsed to read any disclaimer of any form will continue to "irritate" Moonchild and company even if a specialised post-upgrade page is set up ). Even if New Moon becomes fully rebranded to Goldie Locks (haven't decided whether to include the 3 bears or not ) with completely new artwork and redirections to non-MCP related support sites, I don't think MCP will be totally freed from the random Goldie Locks user landing on their forum/github tracker (and this is what seems to be the only one and poignant issue they have with the rest of us...); just look at what happens with MyPal and (to a lesser degree) Centaury...

Same version, run on Windows Vista SP2 x86: 9 (!) handshake failures... Grazie ; might have to do with me having Windows Taskbar placed on the far right of the screen (i.e. vertical, not the default which is horizontal and in the bottom) ...

... FWIW, v0.41b runs fine under Vista SP2 32-bit ; previous v0.39b checked against 100 hosts, this newer version checks against 200 ! (0 detections in my system ) ... Might be also worth to "communicate" the app's bugged GUI, at least in Vista : very elongated window, with no-way to resize, minimize and/or maximize...

The "advantages" of "more secure" and "signed" WE-API based Firefox Quantum add-ons: https://www.ghacks.net/2019/05/29/another-malware-wave-hit-the-mozilla-firefox-extensions-store/ Relevant discussion in reddit: https://www.reddit.com/r/firefox/comments/buahte/a_wave_of_malware_addons_hit_the_mozilla_firefox/ Probably of lesser interest to us running still (?) Firefox ESR 52.9.x and/or Serpent 52.9.0/55.0.0, one has to wonder though...

... What is the actual meaning of this message? Will installing your way totally break Windows Update itself on the machine? If, OTOH, you mean that the installed version of .NET FW (> 4.6.1) won't receive any additional security & performance updates directly from WU, this is an already known limitation that applies even to 4.6.1 (which will install simply by running its default installer); only 4.6.0 is officially supported by Microsoft on Vista/Server 2008, as such is the last version that would receive updates the "normal" way; for any version higher than this, the user has to hunt down provided updates for 4.x.x in Microsoft Update Catalog, download and install manually... Also, have you tried a slight variant to your method? 1. First decompress the provided 4.6.2 official installer with 7-zip, as detailed previously in the "Last versions of software for Windows Vista and Windows Server 2008" thread. 2. In the created directory, locate file ParameterInfo.xml, patch as instructed and save the modifications (perhaps one other possible workaround could be to overwrite the original file with the one provided inside 4.6.2 Preview; the "Preview" does install normally in Vista). 3. Then, instead of running the .MSI file (as instructed in the mentioned thread), just run the Setup.exe file; it should read the modified ParameterInfo.xml file adjacent to it, allowing for a successful installation... ... Do you actually mean netfx_Full_x64.msi in the decompressed installer directory (NB, this is for Vista SP2 64-bit, only!) ? At least one person has reported some problems with 4.6.2 Final when installed via the ".MSI" method: My response: Presumably, @Win2000Fan's method simulates better a "proper" install as if original 4.6.2 installer (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) had been Vista compatible from the start...

... Thanks, but as I already explained in detail, this is indeed the default setting, but has no practical effect under Windows XP; wouldn't matter whether it be true (the default) OR false, since XP doesn't have WMF... Many thanks, too ; as feared, this appears to be a limitation/bug in the way Vista's native h264 decoder handles the 9:16 video stream... Such is life

OK, follow-up : @Tangy: Many thanks indeed for your tests on NM28, St52 and FxESR52; the fact the clip played back fine in these browsers on XP provided additional clues for me (see below...). I am on Windows Vista SP2 32-bit myself, with Platform Update Supplement installed correctly; this means I have a working implementation of Windows Media Foundation (WMF) media framework, which, in layman's terms, means compatible browsers (Firefox and forks) have access to system (OS) decoders for patented formats (h264 for video, aac & heaac for audio); to be more precise, h264 decoding in HTML5 videos is delegated under Vista SP2 to system file mfh264dec.dll (file version on my setup is 7.0.6002.18392, "7" indicates this was a Win7 feature backported via PUS to Vista SP2). In Firefox ESR 52.9.0 under Vista SP2 (with PUS) I don't have to install and enable the Adobe PrimetimeCDM to achieve h264 decoding in HTML5 video (which is the case for WinXP), because the browser, as explained above, has direct access to OS decoders; this works 99% of the time, but, apparently, NOT for this specific video . In Media Source Extensions (MSE) capable browsers, Facebook serves the video via MPEG-DASH streams (fragmented .mp4 files); it is my conviction, after extended testing, that the default system h264 decoder can't cope with this video's unorthodox dimensions (being in "portrait" rather than "landscape" form, 9:16 instead of 16:9). If in FxESR 52.9.x I disable WMF by toggling media.wmf.enabled to false (and with no AP CDM present), then the browser has no way to decode the video stream; fortunately, facebook can still fall back to using the Adobe Flash Player NPAPI plugin (v32.0.0.171) for playback purposes and this does play the clip in question (but in a pop-up, not in-page): The situation is a bit different in the case of the UXP forks; to cater to WinXP users who, as stated, have no access to OS decoders via WMF, @roytam1 has patched the ffvpx library to include (ffmpeg provided) patented decoders for h264/aac; in Vista+, both following prefs are set to true by default: media.wmf.enabled;true media.ffvpx.enabled;true but priority is given to the WMF decoders; that is why I can't play back properly the mentioned video clip in either NM28/St52 (screengrab is with NM28) : If I toggle media.wmf.enabled to false, then h264 decoding is being delegated to the native ffvpx (ffmpeg decoders) implementation and, as things stand, can properly decode the "portrait" video (NM28): And, as expected, if I toggle both cited prefs to false, NM28 will use Flash (in a pop-up): ... Before I classify this as an obscure Vista bug (with no hope of ever getting fixed), I need to know the results of some additional tests: Many thanks for your time spent, especially during "office hours" ; but don't bother testing on WinXP, according to my troubleshooting and @Tangy's feedback, it will certainly work when ffvpx is the decoding module ... When given the chance, can you please re-test with media.ffvpx.enabled;false ? If it plays, then Win10's system decoders can handle OK the 9:16 h264 video stream... Lastly, I need some kind soul to test for me how latest New Moon 28.6.0a1 on Win7 performs on this clip when, again, media.ffvpx.enabled;false and media.wmf.enabled;true ; if it doesn't play, repeat the test with an official Pale Moon binary (ffvpx there doesn't have h264 decoding support); in the small chance the video doesn't play, it's a UXP bug on Win7 (which means it could be reported to the official devs and, down the road, be fixed eventually...); if the clip plays fine with only Win7's system decoders, it's definitive: my case is a fatal Vista bug I'll have to live with Many thanks for the attention and precious time of this forum's fine members PS: As to the mystery why the video plays back fine in NM 27.9.6 on my Vista setup, I think the answer coincides with my findings so far: facebook serves MPEG-DASH, this requires MSE; on Roy's Tycho fork, MSE+h264 decoding is handled by the supplied LAV dlls, not by the system decoder (as proven by a "youtube.com/html5" test without those files...).

I personally avoid Facebook like the plague, but, via e-mail, I was recently given a link to a specific facebook video (two orphaned bear cubs being given milk): https://www.facebook.com/arcturosgr/videos/2355323964725837/UzpfSTU2MzI1NjMwNjoxMDE1NTgyNzQ4OTUzNjMwNw/ I had latest Serpent 52.9.0 32-bit open at the time I received the e-mail but when I tried to watch the linked video (without loggin' in to facebook - I have no account with them, thank God! ), the page and the embedded player would load OK, however, as soon as I pressed the play button, I would only get sound but no video (player turns to black ). I decided to investigate and the other UXP-based browser (latest New Moon 28.6.0a1 32-bit) as well as Serpent 55.0.0/moebius and Firefox ESR 52.9.1 all three exhibit the exact same behaviour, i.e. the video stream isn't displayed! Browser Console in St52 gets populated with many Type, Syntax and Reference Errors... To my great surprise, New Moon 27.9.6/Tycho would play that specific facebook video fine! Both New Moon 27/Tycho and New Moon 28/UXP have by default the same SSUAO for facebook: general.useragent.override.facebook.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:99.9) Gecko/20100101 Firefox/99.9 (Pale Moon) so the difference between them should not be UA related... What did not come as a surprise, of course, was the fact that Google Chrome (49.0.2623.112, 50.0.2661.102, 51.0.2679.0) also played that facebook video fine (it's no secret that, in recent years, the web is tailored to suit mainly Chrome and not the other way round; especially when Google's own devs dictate themselves how the web should be; but this is a discussion for another forum... ). The person who sent me the video link was using Firefox Quantum 67.0 on Win7 SP1 and she could watch the video on her setup without issue; so, this appears to be a bug afflicting pre-Quantum Firefox versions and, to what concerns us XP+Vista users, the UXP platform... I took the extra step of creating a new clean St52 profile and even trying Safe Mode there, but the issue persists ; @roytam1 can you replicate and if yes, any insight/solution offered? In the meantime, I used youtube-dl to fetch the clip to disk, the resulting MP4 file has a Display Aspect Ratio (DAR) of 9:16, which is non-standard; perhaps this is somehow relevant?

... I don't think that @roytam1 has taken steps to change minimum system requirements for his FirefoxESR 45.9.x builds - the main purpose for the release of these builds is that 45 ESR is the last Firefox ESR version to run on (maximum) SSE CPUs . As with any ESR branch build, it has the same System Requirements as its stable (release) branch counterpart: https://www.mozilla.org/en-US/firefox/45.0/system-requirements/ https://www.mozilla.org/en-US/firefox/45.0esr/system-requirements/ So, if standard XP 32-bit is being discussed here, SP2 is mandatory! AFAICT, the last Firefox ESR that would run on XP x86 SP1 is v10.0.x (10.0.12esr the last to be released); the last stable release to run on that configuration was v12.0: https://www.computerworld.com/article/2502032/mozilla-sets-end-of-firefox-for-win2k--early-xp.html

"xpmodsse" is meant for people on older CPUs which only support the SSE instruction set (not SSE2 or higher...). Just "xpmod" is a more generic build for relatively newer CPUs that do support at least SSE2; and, though you didn't ask, the ia32 builds are for even older CPUs that have no SSE support at all... https://en.wikipedia.org/wiki/SSE2 https://www.mathworks.com/matlabcentral/answers/93455-what-is-the-sse2-instruction-set-how-can-i-check-to-see-if-my-processor-supports-it NB: UXP browsers (NM28, Serpent 52.9.0) as well as Serpent 55.0.0 require a minimum of SSE2