VistaLover

New Moon 28 and/or Serpent 52.9.0 also at peril? https://github.com/binaryoutcast/binoc-central/issues/73#issuecomment-467662459 (part of the binoc-central #73 thread...)

The Netflix screengrab you posted earlier mentions Netflix Error N8 156-6023; googling for that takes one to https://help.netflix.com/en/node/200 Make sure you have the very latest version of Silverlight 5 installed (5.1.50918.0); if you're on XP, read this First uninstall whichever Silverlight version already installed (if older) and then, for good measure, restart your system. Install the latest version; head to Start -> All programs -> Microsoft Silverlight (folder) -> Microsoft Silverlight (shortcut) and in the third tab (Playback) be sure to check "Enable download and updates to components required for protected content playback": Then, in the last tab (Application Storage), make sure "Enable application storage" is checked: Exit the Silverlight Configuration manager. I would test myself with a new, clean profile of New Moon 28 (you can back up your existing profile just for this test and restore it afterwards) to exclude any interference from user modified browser settings and/or extension interactions... Visit "about:addons -> plugins" and configure Silverlight to Always Activate. Check your Silverlight installation at http://www.radioactivepages.com/ If your Silverlight installation is in working order, then the (mechanical) clockwork on the top left should be moving: Time now to head over at the Netflix site; unfortunately, I don't have a (paid) account with them, so I can't move on past this point (I also searched - in vain - for a free, sample, Netflix video clip, but none showed up in my searches... ). After signing in and choosing a video for streaming, Silverlight should hopefully ask you to "play protected content"; say yes and it should just do that! (a bit of positive thinking never hurts in these cases ) I honestly hope I've helped...

... Two posts above yours

WidevineCDM, due to an update implemented by Google (current owner of the module) in early January 2019, is currently BROKEN in official Basilisk 52.0.2019.02.11 [and in the unbranded fork Serpent 52.9.0, when used in Vista+; WidevineCDM CAN NOT be used on XP in a Mozilla type browser, due to it needing access to system (OS) decoders (h264/aac) via Windows Media Foundation (an OS feature of VistaSP2+)]. This is currently being tracked in UXP #962 ; I see no recent activity there, admittedly it's not a task for the faint-hearted to adapt mozilla60esr code (merged with lots of Google cr*p) to UXP's EME code... Personally, I have little hope for a fix, but, who knows, maybe I'll be pleasantly surprised; if not, expect EME support to be probably also removed from official Basilisk, no wonder for "security" related issues . After all, no other app built on the platform currently (official Pale Moon 28, Iceweasel-UXP, BinOC's browser and e-mai client) has a need for EME/DRM... As for Netflix: Supposedly, older installations who have acquired licence keys via the now deprecated WidevineCDM version (1.4.8.1088) used in Basilisk will continue to work in old Basilisk profiles, but new/first time Netflix users in current Basilisk will fail to get fresh lic (decryption) keys and thus will be unable to stream Netflix... Netflix is one of the very few services that have a fallback mechanism to Silverlight NPAPI plugin on browsers not supporting EME (e.g. official Pale Moon), thus you can stream Netflix on PM28 with Silverlight 5 installed; PM28 has a native SSUAO for Netflix that forces it to fallback to Silverlight: general.useragent.override.netflix.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Firefox/45.9 95% of DRM'ed sites DON'T have the ability to use Silverlight (and Smooth Streaming) for their encrypted content and are broken in official Basilisk... To stream Netflix in official Basilisk (or in the unbranded fork), one must disable EME in the browser, install and enable Silverlight 5, implement the SSUAO for Netflix and restart browser; hopefully then Netflix streaming in Basilisk should work... Official Support Forum original thread: https://forum.palemoon.org/viewtopic.php?f=29&t=21500

Again, many thanks indeed for keeping on breathing life into New Moon 27/Tycho ; it is much more lightweight and responsive in my old, SSE2 capable, Vista SP2 32-bit laptop than its 28/UXP counterpart, so it is preferred over the latter where both support the same websites... Sadly, as time goes by, a growing number of sites I frequent migrates to latest Javascript APIs, so NM27, due to its older JS engine, starts to fail at them at varying degrees... Currently, most issues are faced with GitHub pages/functions, they (GitHub) insist on using always the most up-to-date Javascript iterations, so this (i.e. NM27's shortcomings) is hardly a surprise ; so, for GitHub I am forced to using a UXP browser... Do the rmottola/Arctic-Fox devs target NM27's older JS Engine with the aim of bringing it closer to recent standards or are their contributions only targeting other aspects of the Tycho platform code? With each NM27 update containing several of their "changes", I hope part of my GitHub issues are fixed; alas, this wishful thinking has, to this day, remained as such... https://github.com/roytam1/palemoon27/commit/6d775ae - 27.9.1a1 + 27.9.6 I had been the first to suggest, many months ago, that a version string change (to >= 27.9.5a1) was necessary to easily reflect the fact the codebase has progressed significantly from the 27.9.4 release code snapshot, so, on the one hand, I am quite content that thing, be it belatedly, did take place . On the other hand though, I would've expected for you to stay with the "a1" version suffix, indicating an "unstable" channel, as you had been always building on MC's master PM27 branch (and, in fact, you do continue doing so with your NM28/UXP releases, forked from the "master" branch (official "unstable" update channel) for PM28/UXP). I could hex-edit PaleMoon.exe myself to change "27.9.6" to "27.9.6a1", but, as (bad) luck would have it, there exist only two NULL characters after "27.9.6" and the next text entry (actually the value of buildID), so this is not possible without breaking the compiled binary: And since I mentioned buildID, bumping appVersion to a "release" figure has an unwelcome (to me, at least) result; in the "About New Moon" info popup, the actual buildID string is no more displayed: I find that having the actual buildID string there (as was the case until now) to be very helpful, especially in troubleshooting scenarios... BTW, the code that controls the display of buildID in the "about" box is found within file "aboutDialog.js": // Include the build ID if this is an "a#" or "b#" build let version = Services.appinfo.version; if (/[ab]\d+$/.test(version)) { let buildID = Services.appinfo.appBuildID; let buildDate = buildID.slice(0,4) + "-" + buildID.slice(4,6) + "-" + buildID.slice(6,8); document.getElementById("PMversion").textContent += " (" + buildDate + ")"; } As you can see, it is only triggered for alpha (or beta) builds... Hopefully, you'll reconsider and opt for a 27.9.6a1 appVersion string for next release... Many thanks for your work, best wishes!

... Official download links from the official GitHub repository should always be preferred over third party generic "download" sites (like www.dobreprogramy.pl) : https://github.com/MrS0m30n3/youtube-dl-gui/releases/tag/0.4 Just my 2p, of course ...

(you and other eventual users: ) Be advised that: 1. This is NOT a true portable version, as it stores logs, settings and actually downloads youtube-dl.exe in "%APPDATA%\youtube-dlg" directory ; there's an open issue for this at https://github.com/MrS0m30n3/youtube-dl-gui/issues/65 2. The binaries of FFmpeg+FFprobe bundled with the package are NOT XP compatible (require Win7+); you should replace them with XP-compat ones (e.g. v3.0 from VideoHelp archive). 3. The project appears to have become an abandonware, at least for Windows users ; last Windows release (0.4.0) was July 2017 (though last commit activity was Oct 2018 ); in any case, I'm happy myself just using the CLI

... Especially when the likes of Matt A. Tobin drive away the very few that express such an intention: https://forum.palemoon.org/viewtopic.php?f=44&t=21149

... First of all, your request is rather off-topic for this thread; second, TVP media content is geo-fenced, accessible from whitelisted Polish IPs, only ... However, as with many media (video/audio) portals, your best bet lies with youtube-dl; it is a CLI (Command-Line-Interface) application, the pre-compiled Windows executable (youtube-dl.exe) is XP-compatible (built with Python 3.4.4); I had to find a working whitelisted Polish HTTP proxy (you won't be needing that if you're inside Poland ) and I had no issue fetching to disk: youtube-dl --proxy="http://54.37.131.15:3128" -F "https://vod.tvp.pl/video/ojciec-mateusz,odc-100-sklep-z-zabawkami,8286051" [tvp] 8286051: Downloading webpage [tvp:embed] 8286051: Downloading webpage [tvp:embed] 8286051: Downloading ISM manifest [tvp:embed] 8286051: Downloading f4m manifest [tvp:embed] 8286051: Downloading m3u8 information [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: video URL is invalid, skipping [info] Available formats for 8286051: format code extension resolution note mss-audio-175 isma audio only 175k , AACL (44100Hz) mss-video-532 ismv 398x224 532k , H264, video only mss-video-741 ismv 480x270 741k , H264, video only mss-video-1146 ismv 640x360 1146k , H264, video only mss-video-1518 ismv 800x450 1518k , H264, video only mss-video-2437 ismv 960x540 2437k , H264, video only mss-video-4024 ismv 1280x720 4024k , H264, video only mss-video-5397 ismv 1920x1080 5397k , H264, video only hds-707 flv 398x224 707k hls-749 mp4 398x224 749k , avc1.100.30@ 532k, mp4a.40.2@175k http-749 mp4 398x224 749k , avc1.100.30@ 532k, mp4a.40.2@175k hds-916 flv 480x270 916k hls-970 mp4 480x270 970k , avc1.100.30@ 741k, mp4a.40.2@175k http-970 mp4 480x270 970k , avc1.100.30@ 741k, mp4a.40.2@175k hds-1321 flv 640x360 1321k hls-1400 mp4 640x360 1400k , avc1.100.30@1146k, mp4a.40.2@175k http-1400 mp4 640x360 1400k , avc1.100.30@1146k, mp4a.40.2@175k hds-1693 flv 800x450 1693k hls-1794 mp4 800x450 1794k , avc1.100.30@1518k, mp4a.40.2@175k http-1794 mp4 800x450 1794k , avc1.100.30@1518k, mp4a.40.2@175k hds-2612 flv 960x540 2612k hls-2768 mp4 960x540 2768k , avc1.100.31@2437k, mp4a.40.2@175k http-2768 mp4 960x540 2768k , avc1.100.31@2437k, mp4a.40.2@175k hds-4199 flv 1280x720 4199k hls-4450 mp4 1280x720 4450k , avc1.100.31@4024k, mp4a.40.2@175k http-4450 mp4 1280x720 4450k , avc1.100.31@4024k, mp4a.40.2@175k hds-5572 flv 1920x1080 5572k hls-5906 mp4 1920x1080 5906k , avc1.100.40@5397k, mp4a.40.2@175k (best) Several streaming methodologies are implemented, from HTTP progressive download (http-* modes), to Smooth Streaming (mss-video-* + mss-audio-175), to AdobeHDS (hds-* modes), to AppleHLS (hls-* modes); say I want the 960x540 encode (SD) over http-progressive, then I'd type: youtube-dl --console-title --proxy="http://54.37.131.15:3128" -f "http-2768" "https://vod.tvp.pl/video/ojciec-mateusz,odc-100-sklep-z-zabawkami,8286051" -c --no-part --write-thumbnail --embed-thumbnail --add-metadata [tvp] 8286051: Downloading webpage [tvp:embed] 8286051: Downloading webpage [tvp:embed] 8286051: Downloading ISM manifest [tvp:embed] 8286051: Downloading f4m manifest [tvp:embed] 8286051: Downloading m3u8 information [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: Checking video URL [tvp:embed] 8286051: video URL is invalid, skipping [tvp:embed] 8286051: Downloading thumbnail ... [tvp:embed] 8286051: Writing thumbnail to: Ojciec Mateusz, odc. 100 ? Sklep z za bawkami-8286051.jpg [download] Destination: Ojciec Mateusz, odc. 100 ? Sklep z zabawkami-8286051.mp4 [download] 100% of 768.13MiB in 08:33 [ffmpeg] Adding metadata to 'Ojciec Mateusz, odc. 100 ? Sklep z zabawkami-828605 1.mp4' [atomicparsley] Adding thumbnail to "Ojciec Mateusz, odc. 100 ? Sklep z zabawkam i-8286051.mp4" NB: If you want metadata (tag) added to the MP4 file, then you'd need ffmpeg.exe (a WinXP compat version) besides youtube-dl.exe; if you also want an embedded thumbnail, you need atomicparsley.exe (MP4 CLI tagger), too... MediaInfo log of downloaded file: General Complete name : <redacted>\youtube-dl\Ojciec Mateusz, odc. 100 – Sklep z zabawkami-8286051.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) File size : 769 MiB Duration : 41 min 2 s Overall bit rate : 2 619 kb/s Movie name : Ojciec Mateusz, odc. 100 – Sklep z zabawkami Description : Policjanci zostają wezwani do sklepu z zabawkami. Znajdują w nim nieprzytomnego właściciela sklepu, Leona, oraz zwłoki dyrektora jednego z miejscowych banków. Na jaw wychodzi, że pracująca w placówce narzeczona zamordowanego w przeszłości była partnerką Leona. Tagged date : UTC 2019-02-20 00:15:29 Writing application : Lavf58.16.100 Cover : Yes Comment : Policjanci zostają wezwani do sklepu z zabawkami. Znajdują w nim nieprzytomnego właściciela sklepu, Leona, oraz zwłoki dyrektora jednego z miejscowych banków. Na jaw wychodzi, że pracująca w placówce narzeczona zamordowanego w przeszłości była partnerką Leona. Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.1 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 41 min 2 s Bit rate : 2 437 kb/s Nominal bit rate : 2 100 kb/s Width : 960 pixels Height : 540 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.188 Stream size : 715 MiB (93%) Writing library : x264 core 129 r2245 bc13772 Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=34 / lookahead_threads=5 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=100 / keyint_min=51 / scenecut=0 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=2100 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=26 / qpstep=4 / vbv_maxrate=2600 / vbv_bufsize=2600 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00 Color range : Full Codec configuration box : avcC Audio ID : 2 Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Duration : 41 min 2 s Bit rate mode : Constant Bit rate : 175 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 44.1 kHz Frame rate : 43.066 FPS (1024 SPF) Compression mode : Lossy Stream size : 51.3 MiB (7%) Default : Yes Alternate group : 1 Enjoy!

... Works here for me with roytam1's Serpent 52.9.0 32-bit browser: Flash animation successfully shown for a second, but the still ad picture that replaces it afterwards is hidden (by default) by enabled uB0; if I disable uB0 on that page and reload, FWIW, alternative Flash Player check page, also courtesy of Adobe (HTTPS only...):

... Another drawback of FolderOptionsX on Win7 that I discovered: Folder view is Tiles; you're inside a directory which contains a mix of subfolders and various file types; imagine the case an executable is adjacent to a folder; say you decide to swap their mutual places, e.g. foo.exe + folder => folder + foo.exe and this is (visually) performed OK, but when you double-click the folder icon (now on the left), you'll find that you're actually executing file foo.exe; this could be unwanted, even dangerous, at times Actually, after you are done rearranging (folder+file) icons inside the directory, you have to refresh the directory so that Windows Explorer is made aware of their new positions; I'm not certain whether the same bug manifests itself in other Folder Views, but it's definitely there in Tiles ... Cheers

... it's landed , people... https://github.com/MoonchildProductions/UXP/commit/ef75531aa855d64d9cd9c9998de5f02acf7518b7

@Tangy: You appear to have this setting checked (Prevent WebRTC from leaking local IP addresses) while using New Moon; in all honesty, I don't think it has any bearing on New (Pale) Moon, since WebRTC is disabled there at code level... But it's certainly applicable on FirefoxESR 52.9.0, Serpent 52.9.0 and even Serpent 55.0.0; the wiki link for that feature, for anyone concerned, is: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address According to tests I performed on both FirefoxESR 52.9.0 and Serpent 52.9.0, this issue you report appears to manifest itself exclusively with the WebExtension version of UBlock Origin ; if one installs the XUL version of uB0, currently at version 1.16.4.7, then the checkbox remains "clickable" no matter the value of boolean pref "media.peerconnection.enabled"; switch to the WE version of uBO (stable channel currently at version 1.17.4) and one discovers that the WebRTC checkbox has been disabled (and text greyed out ), again irrespective of the state of the "media.peerconnection.enabled" boolean pref... ******************************************************************* A word to those using uB0 WE on Basilisk/Serpent 52.9.0 : 1.17.4 is the final version that can be installed in Basilisk 52 out of the box; 1.17.7b2 of the dev channel was (has now been removed from the GitHub repo) equally the last (beta) version to install (out-of-the-box) in either Basilisk 52 / Serpent 52.9.0; this development has been reported first in the official PM forums, https://forum.palemoon.org/viewtopic.php?f=61&amp;t=21241 which also links to the uB0 support reddit: Mozilla fanbois aside (they're so irritating , aren't they?), it was claimed that "Basilisk was never officially supported", while in the end of the thread the author revealed that he had to increase "strict_min_version" (inside extension's manifest.json) to "55.0", because he started using the Web API requestIdleCallback. So, latest dev version 1.17.7rc2 won't install in Bk52 I've done some research and have discovered at least two discrepancies here: 1. For some inexplicable reason, Firefox versions 52.0.2 and 53.0.3 (release channel) as well as 52.9.0 (ESR channel) do not honour the "strict_min_version": "55.0" requirement and version uB0 1.17.7rc2 has no problem installing and working there... 2. While the MDN documentation states that window.requestIdleCallback() is "Implemented but disabled by default" in Firefox v53-55, I found boolean pref "dom.requestIdleCallback.enabled" extant (but defaulted to false) in all 3 mentioned Firefox versions (52.0.2, 52.9.0, 53.0.3); so, at least in theory, Firefox >=52.0 already meets the new requirement by @gorhill, provided the user manually flips "dom.requestIdleCallback.enabled" to true; what is even more important is the fact Moonchild devs have already defaulted that pref to true in Basilisk 52, so there's no actual reason why the Basilisk browser should be exempt from the list of supported (by latest uB0 WE) browsers - but, sadly, @gorhill does not follow closely Basilisk's development, hence his decision to block it based solely on its reported appVersion string ; also worth noting is that Serpent 55.0.0/moebius doesn't exhibit this issue because, its appVersion string reporting 55.*, it already fulfils the new enhanced requirements... To cut a long story short, I downloaded file uBlock0_1.17.7rc2.firefox.signed.xpi to disk and manually changed line 5 in manifest.json file to read: "strict_min_version": "52.0", ... then the extension had no problem installing and working as expected in Serpent 52.9.0 Of course, when Moonchild's new unfortunate plan (to remove WE support in Bk) bears fruits, this post of mine would be a moot one... *******************************************************************

Personally, I'm not at all content with the decisions made by the Moonchild+Tobin duo... In New Moon 28, I am, of course, confined to only using "legacy" extensions, many of them I inherited from my FxESR 52 usage era; they (continue) to work at this time of writing but the harsh truth is when they start to break (and they will, sooner rather than later ), the chance they receive proper bug fixes, especially those that started life in AMO and haven't been forked to APMO (GitHub?), is minute/none... Recent "troublefests" in NM28 for me include Print Edit 18.4 (a rather convoluted, hack-ish, method to regain basic functionality is to be found in the Pale Moon forums, since the original developer shows no interest at all in fixing his XUL version: all development efforts are focused on its WE counterpart) and Stylem 2.2.4, which is currently bugged and unable to follow the progress made in the UserStyles field; more specifically, it is unable to correctly install configurable userscripts from "UserStyles.org" and has 0 support for the new "trend" that is the "user.css" format (to which many style authors have already changed ...). Even Moonchild himself acknowledges that there is a dim future regarding author support for XUL extensions (intended for consumption by PM/Basilisk users): https://forum.palemoon.org/viewtopic.php?f=46&amp;t=21214 As @Mathwiz has already pointed out, in Serpent 52.9.0 I had found an elegant way to keep on using the greater part of the WEs I was using in FxESR 52; some of these WEs have progressed to versions incompatible with FxESR 52 and/or UXP, so am again forced to using slightly older versions (with no hope of receiving further updates), some others continue to be routinely updated to fix newly introduced bugs; plus, there's always a chance I can find on AMO a new (to me) WE (that I wasn't necessarily using in FxESR 52); in any case, retaining that (rudimentary, at times) WE support in Basilisk/Serpent was always welcome by me,,, For example, I can install and use Stylus 1.4.23 (WE-only) in Serpent 52.9.0, alongside Stylem 2.2.4, to properly install configurable userstyles and "user.css" type styles from GitHub (and elsewhere). And while Moonchild claims: in every day practice that statement is far from being a Holly Truth ; there exist (recent) extensions that only started life in the WE format; as a non-coder, it is impossible for me to "translate" them to the superior XUL format and satisfy Moonchild's expectations... I have quite a few WEs installed in Serpent 52.9.0, these include Google search link fix 1.6.7 ImTranslator: 14.15 (last version properly working) Markdown Viewer Webext 1.4.0 Native MPEG-Dash + HLS Playback 1.1.0 (only available as WE) Play/Pause 2.0.3 uBlock Origin 1.17.7.102 View Page Archive & Cache 1.5.3 Violentmonkey 2.10.1 (only available as WE) Adaptive Bitrate Manifest Viewer 0.9.0 (only available as WE) Browsec VPN - Free and Unlimited VPN 3.16.16 (only available as WE) SaveFrom.net helper 8.1 (only available as WE) Stylus 1.4.23 (only available as WE) ... so I'll be quite frustrated when Basilisk (Serpent) 52 In any case, I might keep a copy of the last WE-compatible version of Serpent 52.9.0, use my copy of Serpent 55.0.0 (which, incidentally, has better WE support) or some other thing... BTW, reddit, ghacks and the like are mostly infested by Mozilla fanbois, who never lose breath badmouthing all Firefox forks (including Pale Moon, Basilisk, Waterfox), so I never place credence to all the FUD they're spreading there... Yes, I am to an extent concerned with browser security, but usability is of primary importance to me... Being on 32-bit Vista, this obviously holds little promise for me... Unless you're implying the Waterfox Team efforts would, somehow, find their way into your forked UXP copy (hence Serpent 52.9.0)...

... This is because Pale Moon 28 (New Moon 28) has a native Site-Specific-User-Agent-Override (SSUAO) for youtube.com that forces it to display in the older ("Classic") web style, which lacks, among other things, the "Watch later" button (placed after "Share" button in the new "Material" web style). general.useragent.override.youtube.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 PaleMoon/28.3.0a1 If you want to force the new "Material" design for youtube (and thus make the "Watch later" button available to you in NM28), you should modify the SSUAO to spoof a recent Mozilla Firefox version: general.useragent.override.youtube.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 Be warned that the Material youtube design works better in more recent hardware (namely GPU/CPU)...

"but Basilisk reports that they all appear to be corrupt. Must be a bad hash somewhere" : This is a generic message given out by Basilisk/Serpent when the WebExtension addon one attempts to install is somehow unsupported/incompatible; only rarely does it actually indicate a corrupt file (due to, e.g., erratic connection during download, etc.). In the case of the referenced extension, the error is caused by a limitation in the set of WebExtension APIs present in Basilisk/Serpent (which, as you know, is only a subset of the WE APIs present in the MozillaESR 52 platform, that UXP forked) ... In fact, Basilisk/Serpent have no support for id-less WE addons, hence the generic error message produced... Easy workaround: Once you download to disk file webrtc_control-0.2.3-an+fx.xpi, open it with 7-zip archiver; first, you can optionally delete the whole META-INF directory, to reduce addon size, since Basilisk doesn't check for extension signing; then, open file manifest.json in an editor and, towards the end, add an arbitrary extension-id, e.g. I added: (modified file, shown here is excerpt starting at line 31) "128": "data/icons/128.png" }, "applications": { "gecko": { "id": "webrtc-control@basilisk.org" } } } Save your patched .xpi file (for me, once I exit my text editor, 7-zip auto-prompts to save the committed changes) and then install to Basilisk via drag-n-drop; it should install now without errors: As discussed previously, the WE version of an addon is preferred over its legacy version when the browser is to be (force-)run in multiprocess (e10s) mode ...

With all due respect... I am afraid you fail to see the bigger issue; the problem here isn't about me (or two Polish NM28 users or a French guy, etc.) wanting to see the WebRTC button translated into my (their) native language; it can, of course, be in English, I couldn't care less if it was in Korean for all I know, as I wouldn't be using it myself... The problem is that already available PM28 official language packs (look here, it's 39 of them) cannot be used any more with your NM28 fork; for the browser to simply start in a localised GUI, the two lines (be it in English, I don't mind) cited in my previous post have to be inserted manually in every one of them, in order to become again functional when installed in NM28; who is going to provide those NM28 (half-)compatible language packs? Mind you, that process should be repeated every once the packs get updated upstream... If a language pack is missing the aboutWebrtc.properties file, then it's not fatal as the missing lines in browser.dtd (NM28 will launch localised), but when such a LP user navigates to "about:webrtc", he/she will be met by a blank page; as said, I don't use WebRTC, but from a quick look at that page I see it contains useful configuration/functionality... I have no inclination (nor legitimate right, someone would argue) to contact their l10n team; for starters, I (and other XP/Vista users here) am not using the official product, i.e. Pale Moon 28, for which uniquely the language packs are intended to work with, but a fork (which we know how much they frown upon); let alone a fork which has just implemented a feature unsupported by design in the original product... "translate that button"?... what button, may I ask? They will never implement WebRTC in Pale Moon, their default en-US locale code simply has no strings related to webrtc, nothing for them to translate; or are you (or anyone else for that matter) under the impression that somehow we could beg and convince @JustOff (head of l10n team) to compile WebRTC enabled PM28 test builds (against Moonchild's wishes) and generate applicable language packs, just for the sake of international NM28 users, here in the MSFN forums (and continue to do so with every upstream string change)? With respect, this expectation is absurd, a folly even... As I see it, it is indeed a bonus that we are (were) able to use official PM28 LPs in NM28; after all, official LPs contain the official branding , I bet both Moonchild and Matt A. Tobin will go ballistic if they become aware... So NO, I see no reason to contact any of the Moonchild Productions persons with regards to this; it will only make matters worse for us... To conclude, it's not about me; I know my way around LPs and have produced a private, working, Greek Language Pack, that mitigates the WebRTC inflicted changes; I even transplanted to it a fully translated (in Greek) copy of file aboutWebrtc.properties that I extracted from the Greek LP for FirefoxESR 52.9.0; I think I can move forward merrily, no matter what the decision taken about the future direction of NM28... Still, nothing is foolproof: my installed modded Greek LP informs me that an update to (official) version 28.3.0 is available ; now, I shall have to be very cautious not to install it inadvertently, because - guess what? - if I do, my default Vista browser will revert to its en-US GUI... Frankly, I don't have anything additional to contribute to this discussion; what I had to say is best summed up in my previous relevant post; it would be prudent, though, that some additional views/opinions of users here be voiced before the fate of the webrtc-in-NM28 feature is finally cast... As ever, best regards and many thanks to the maintainer...

... Likewise here ; after updating to the latest New Moon 28 win32 build [Version: 28.3.0a1 (32-bit) (2019-01-11), buildID=20190111225658], the official Pale Moon Greek language pack (el.xpi, even latest version 28.3.0_RC4 released mere minutes ago) stopped working! Inquisitive as I am, I went for some troubleshooting, what I eventually discovered is quite ominous for NM28 users who want to use localisation in their favourite browser... @roytam1 I kindly ask you to pay close attention to what I'll be detailing below, it is of somewhat "technical" nature, so apologies to those not able to follow through... ======================================== Previous NM28 build details: Package name: palemoon-28.3.0a1.win32-git-20190105-7fcb7f544-xpmod.7z "about:" info: Version: 28.3.0a1 (32-bit) (2019-01-04) buildID: 20190104234139 => Language Packs WORK Current NM28 build details: Package name: palemoon-28.3.0a1.win32-git-20190112-f38edc94a-xpmod.7z "about:" info: Version: 28.3.0a1 (32-bit) (2019-01-11) buildID: 20190111225658 => Language Packs DON'T WORK Changelog on the official UXP repo between builds is described by: Comparing 7fcb7f5...f38edc9 As you're hopefully able to see, no change has been committed by the Moonchild devs to files inside application/palemoon/locales/en-US/* so the breakage of Language Packs in New Moon 28 isn't caused by changes upstream; this, in itself, means there will be 0 chance of the official LPs becoming compatible with NM28 in the future ... So the next logical conclusion is that language packs became (and shall remain) broken due to something you yourself commited; so, taking a closer look: libaom/NSS changes seem inconspicuous, but it is --enable-webrtc in "Configure options" (about:buildconfig) that is the real culprit for the LPs breakage ... Indeed, building with WebRTC API enabled introduces new strings inside the browser, strings that are absent in the official Pale Moon 28 (where WebRTC is not implemented/supported) and so are equally absent inside any language pack meant for PM28. And since I don't have at my disposal a relevant git changelog depicting the locale changes introduced by WebRTC, it is/was very difficult for me to pinpoint these string changes easily... My era as a Firefox Nightly tester somehow helped me in this task; I first set out to extract and compose the default en-US locale as has been compiled in this latest NM28 build (relevant directories/files are to be found in: <installDir>/palemoon/browser/omni.ja!/chrome/en-US/locale/* <installDir>/palemoon/omni.ja!/chrome/en-US/locale/* ) and then compare this en-US LP with my installed el.xpi one, for newly introduced strings/files; I may have missed some non-important changes, but the main string change causing the break is to be found inside: el.xpi!/browser/chrome/el/locale/browser/browser.dtd Two new lines should be added: <!ENTITY webrtcIndicatorButton.label "Camera / Microphone Access"> <!ENTITY webrtcIndicatorButton.tooltip "Display sites you are currently sharing your camera or microphone with"> (and be translated into the language of choice, Greek in my case...). Then again, enabling WebRTC in NM introduces a new system page called "about:webrtc" which comes with many new strings which have to be added and hopefully localised; the strings for that "about:" page should be found inside file: el.xpi!/chrome/el/locale/el/global/aboutWebrtc.properties The en-US version of file aboutWebrtc.properties has been uploaded to: http://s000.tinyupload.com/index.php?file_id=63793921022754074631 With above changes implemented, I finally got 28.3.0_RC4.el.xpi to install and work OK in latest NM28 (but with more than 2 hours spent overall on this feat... ); it is more than obvious to me that a non-techie NM28 user who wishes to have NM28 localised in his/her native tongue would not be up for that... ======================================== @roytam1 The following constitutes my personal views on the subject, you are free to proceed as you please: 1. Should you continue to build NM28 in the future with "--enable-webrtc", it would put a permanent end to NM localisations; the browser would only be capable of being run in the default en-US locale, much like Basilisk/Serpent is (for which no LPs are available). 2. I know you meant well and wanted to cater for those NM28 users that want to use voice chat features (e.g. Web Skype, Facebook, Web Discord etc.) in their browser; after all, that was an issue (lack of webrtc support in NM) I myself pointed out in the Vista Discord thread and recently, again, in this very thread. 3. I have no use myself for Voice Chat in NM28, for all that matters I don't know if what you did here even works as intended: (e.g. I think WebRTC also implies the download and use of "OpenH264 Video Codec provided by Cisco Systems, Inc.", doesn't it?) 4. Official Pale Moon has never supported WebRTC, they have their reasons - privacy also being one of them, as pointed out by @Sampei.Nihira, so their code is tailored/optimised to that decision; why then should New Moon, a Pale Moon fork, attempt to implement WebRTC? 5. FirefoxESR 52.9.0 as well as its official fork Basilisk52/UXP are perfectly capable of handling WebRTC, albeit with some user-agent spoofing to ease up those sites insisting on NT 6.1+ and Google Chrome as browser ; this is why we here, the XP/Vista communities, have, thanks to you , an alternative browser choice, Serpent 52.9.0, to use when NM falls short; if it was upon me to decide, I would simply point voice chat users to Serpent (as I already have), than break localisation for New Moon (by enabling an unsupported feature there)... 6. Ultimately, it may come down to numbers; if there's an excess of NM28 users who prefer WebRTC (provided your latest "hack" works) compared to those who need their browser localised, then I guess the majority should prevail; in that case, may I kindly ask you continue to provide NM28 builds without the WebRTC API for those of us with no use for it but who still prefer the browser GUI localised? Thanks for your time reading this long post, thanks again for your forks! EDIT: When I started writing this, https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158755 and https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158756 had not been posted yet; I had to stop writing mid-way and was not notified (by e-mail) of them being posted; when I resumed and eventually finished writing, I just clicked Submit, oblivious to their existence

If you want to use the Discord "Voice" feature ("You want to be able to talk to your team, ..."), then am afraid that New Moon is a no go (by design/Moonchild's choice, it does not support WebRTC); this same issue was brought up a while ago in the Vista subforum: Web version of discord doesn´t work please do read through, included is an explanation from yours truly and some possible workaround (but not with NM28 ) ...

... And if you spoof a Firefox browser, they still insist you download and install the ultimate spyware, Google Chrome :

... Would you mind letting us know which exact Markdown Viewer extension you're using and its version? In New Moon 28.3.0a1 I have installed (though seldom used...) the XUL (legacy) version 1.1.2 of https://web.archive.org/web/20181102002010/https://addons.mozilla.org/en-us/firefox/addon/markdown-viewer/ Its .xpi file can be retrieved from the Web Archive, its GitHub repo and via the CAA extension discussed previously... It can, of course, be installed in Basilisk/Serpent, but if you want e10s enabled there, you had better switched to a WebExtension equivalent, like: https://addons.mozilla.org/el/firefox/addon/markdown-viewer-webext/ Latest v1.4.0 installs and works fine in Serpent 52.9.0 (32-bit); no way to test on official Basilisk 52, since on Vista here... Being of the WE format, it functions properly even when e10s is force-enabled in Serpent; you can test it at, e.g., https://raw.githubusercontent.com/KeithLRobertson/markdown-viewer/master/README.md Regards

Second that! All the more, since, in its settings, I have configured PSPad to be the default code editor !

Hi ; this is a well known and documented limitation of said extension: https://github.com/JustOff/ca-archive#compatibility-and-installation => The author (@JustOff) is a member of the Moonchild dev team, this addon was primarily conceived to be installed in Pale Moon and/or Basilisk; the former does not inherently support electrolysis (e10s code present inside the UXP platform has been willfully crippled by Moonchild team for "application/palemoon"), while the latter does not officially support e10s (nor have any tests for it been performed with multiprocess mode turned on...). However, the same author appears to be somehow affiliated with the Waterfox browser project, they are the ones kindly providing hosting space/bandwidth for all legacy extensions catalogued inside CAA. Current Waterfox (a 64-bit only browser) requires Win7+, so am not in a position to try it (Vista SP2 x86 user); it comes with e10s turned ON by default, hence CAA issue #2 was submitted; the extension author came up, in v1.2.2, with a "dirty hack" to deal with e10s in Waterfox: https://github.com/JustOff/ca-archive/commit/a565810 What this hack in effect does is, instead of generating the Multi-process mode is not supported now, please disable it and restart Waterfox pop up notification, upon clicking CAA's toolbar icon, it spawns a second non-e10s Waterfox window, where CAA can function properly (i.e. Waterfox can interpret the caa: protocol). I have inspected the "new" code inside linked commit and, after local experimentation, have found out that implementing the same "dirty hack" for multiprocess Basilisk/Serpent is as simple as substituting the string "Waterfox" in https://github.com/JustOff/ca-archive/blob/a5658100f67aafe1ee140545a6ab7397cdc1ec78/bootstrap.js#L169 (this is in file bootstrap.js) with the string "Basilisk": - if (e10s && Services.appinfo.name != "Waterfox") { + if (e10s && Services.appinfo.name != "Basilisk") { Be sure to first close the non-e10s window after you're done with it, i.e. simply browsing the CAA lists or having just installed something from CAA, prior to restarting the browser (to complete legacy addon installation) ... Hope it works for you as it did for me (though I am inclined to run Serpent 52.9.0 in its default configuration, with e10s OFF => less RAM consumption )

I recollect posting this before, but for people reading this latest discussion about JRE 8u191 (CPU release) vs JRE 8u192 (PSU release): and from there: https://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html You are then, of course, free to make your own individual choice...

It's probably a CDN thing; I just tried the link for the ActiveX setup here (UTC+02:00) and it correctly fetched the 32.0.0.114 version; content on their US distribution servers (UTC-08:00 to UTC-05:00) will update soon, methinks...