VistaLover

(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...

@Tamris It's totally fine , I never implied you should have frequented the rest of the XP forums; I just posted that piece of info to let people here (in the Vista subforum) know how "I" was informed of the existence of the unofficial 2.49.5 builds; I hope it's clear now...

... This was also linked to by @roytam1 in the corresponding XP thread: The thing is, I had previously landed in that "repo" some weeks after 2.49.4 became EoS (or rather the Mozilla ESR 52.9.0 platform it builds on...), but I was dismayed to find out that only win64 builds were offered... ; so I was pleasantly surprised to discover a win32 build is now available: Not an official build, surely; these are being compiled and offered by a dev named Bill Gianopoulos (of Greek descent), he states himself that: It comes with ChatZilla, DOM Inspector and Lightning extensions pre-installed (as system addons), too (PS: I couldn't help noticing the increase in size for file xul.dll, from 53.1 MB in official 2.49.4 32-bit (compiled with Visual Studio 2015) to 61.7 MB in latest "nightly" (compiled with Visual Studio 2017 )) ...

... I can reproduce; I had to temporarily switch to the default theme (am using Dark Moon 2.3.0 otherwise) to notice it more clearly: for a fraction of a second, the embedded search bar (in the middle of about:home) appears truncated (i.e. shorter) when about:home is loaded for the first time, but then auto-resumes its normal length... NB that when DDG is set as the default search engine (which is the default setting), the search bar is shorter, because it is prepended by the DDG icon (at least in the default theme); when other search engines are user-selected, these come with no icon and an elongated search bar... The changelog between buildID=20181221223321 and buildID=20181228225818 (for 32-bit) is: https://github.com/MoonchildProductions/UXP/compare/ba81aaf...83cd966 The one relevant commit that easily stands out appears to be: [PALEMOON] Initialize the search service asynchronously from 'about:home' and 'about:newtab' : https://github.com/MoonchildProductions/UXP/commit/cb2f0f614362d3e986d585d6d1b4a2eaa20a1365 Hope your query is answered

Many thanks indeed for letting us know ; I decided to give Otter Browser v1.0.01 a shot Main site: https://otter-browser.org/ GitHub source repo (+ issue tracker): https://github.com/OtterBrowser/otter-browser SF Windows binaries repo: https://sourceforge.net/projects/otter-browser/files/ At this time, no installer (setup) is available for latest (stable) version; one exists for previous RC, "otter-browser-win32-0.9.99.3-rc12-setup.exe", though... It appears that the binaries (setup.exe/.7z packages) meant for Win7+ have been compiled with Qt 5.10.1 (which requires Win7+), while the "*.xp.zip" packages have been compiled with the older Qt 5.6.2 framework, still compatible with both XP+Vista... From my brief encounter with otter-browser-win32-1.0.01-xp.zip, I can safely say this is far from being an alternative to both of roytam1's referenced browsers... At best, this is a project under development, a long distance away from maturity - despite the recent "stable" label, with very little customisation capabilities, no support yet (that I can see) for any browser extensions and, worse yet, the Vista compatible build has some additional shortcomings, due to the older version of Qt used in that... The Qt 5.10.1 versions (Win7+) of Otter have the "mediaservice" directory with wmfengine.dll inside it, this suggests Otter is capable of accessing WMF (system) decoders in Win7+; the Vista version (built on Qt 5.6.2) doesn't have this wmfengine.dll but instead has a "lib/gstreamer-1.0" subdirectory, which suggests that the build can't access Vista system codecs and media decoding is delegated to gstreamer instead ... Perhaps I am missing something obvious to experienced Otter users (e.g. the need to install gstreamer for Windows?), but I was unable to play ANY youtube video on my Vista SP2 laptop; in fact, when visiting www.youtube.com/html5 this is what I get: I wasn't willing to try installing gstreamer for fear it messes up with already installed codec packs, FWIW Vista isn't officially supported either: https://gstreamer.freedesktop.org/documentation/installing/on-windows.html So, for me at least, Otter will remain just a "curiosity" project I may check upon from time to time, not a match to New Moon 28.3.0a1 that I'm currently using for my main browsing needs...

According to Qualys SSL Labs, that domain resolves to two IPv4 (104.28.10.185, 104.28.11.185) and two IPv6 (2606:4700:30:0:0:0:681c:ab9, 2606:4700:30:0:0:0:681c:bb9) addresses: https://www.ssllabs.com/ssltest/analyze.html?d=robotbirds.co.uk Looking closer at the log for, say, the first IPv4 server (104.28.10.185), https://www.ssllabs.com/ssltest/analyze.html?d=robotbirds.co.uk&amp;s=104.28.10.185 if one scrolls further down to the Handshake Simulation section, one can see that Google Chrome 49 on XP SP3 is unable to establish the secure connection due to handshake failure: Google Chrome 49 (unlike Gecko type browsers) relies on the system installed certificate store and system available cipher suites, on XP SP3 the supported cipher suites are shown in: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&amp;version=49&amp;platform=XP SP3&amp;key=136 (I believe additional cipher suites should be available if POSReady updates installed); but the server at robotbirds.co.uk does not support any RSA suites, so no go for Chrome 49... Also, the site requires SNI support in a browser, hence IE8 is also excluded; use FirefoxESR 52, New Moon 28, Serpent 52.9.0 to access; or use @heinoganda's ProxHTTPSProxy with Chrome 49...

Happy New Year to all members here (and since timezones were exchanged, mine is UTC+02:00 ) ! I was away from home during the past few days, internet connection was iffy and expensive, so not very practical to post here at MSFN... @roytam1 May you be blessed and continue, during 2019, to provide us with XP/Vista compatible builds of your browsers; your efforts, altruism/kindness are immensely appreciated... @CoRoNe I think I have a solution to your predicament; what it boils down to is: 1. Use a browser capable of displaying the "consent.talpanetwork" page; I used New Moon 28 with uBlock Origin temporarily disabled on that page (this is needed for the cookie consent dialogue to appear; with uBO ON, it doesn't ); now we know you can't yourself use any of the UXP/moebius browsers, since they require an SSE2+ capable processor; one solution would be for you to do this on a friend's/relative's box... 2. Your "YES" cookie consent is stored in browser cookies, locally; the idea behind my solution is to export those "kijk" consent cookies from the third browser (NM28 in my case) back to the (SSE compatible) NM27 browser you're using... You need install in both browsers the CookieKeeper legacy extension I mentioned some pages back Get yourself somehow familiarised with the addon, its settings and its usage (you'd agree that my intent here wouldn't be to teach you how to use it... ); after you agree to the cookie dialogue presented by the "consent.talpanetwork" domain, you should be auto-redirected to the main "www.kijk.nl" domain; of the cookies stored for that domain, you need to export (via CK addon) only 3 of them, 706b604c-184a-4235-899c-a744921ce65ccconsent 706b604c-184a-4235-899c-a744921ce65ccconsent (same cookie name, different value) CONSENTMGR Export saves them in a .json file, easily transferable between computers. Now, on your copy of NM27 (with CK installed), import the .json file (prior to navigating to "www.kijk.nl"); once successfully imported, load your Dutch media site and this time you won't be redirected to the (NM27 incompatible) consent page, the main site will immediately load: Addendum 1 If you don't have easy access to a second machine with New Moon 28 installed, I think my own .json file will work: { "method": 3, "cookies": [ { "isSecure": false, "value": "BOZwbEeOZwbEeADABANLAEAAAAAE54EfETAAQgAAHAA", "isSession": false, "isProtected": true, "expires": 1580146974, "path": "/", "name": "706b604c-184a-4235-899c-a744921ce65ccconsent", "host": ".kijk.nl", "isHttpOnly": false },{ "isSecure": false, "value": "BOZwbEeOZwbEeADABANLB_-AAAAjCAcAAiABUAC4AIAAZABEgCaAJ4AWwAxABuAD8AIAARgApQBXADvAIQARaAjgCOgEuAJ2AVkAuoBgQDiAHugP0A_YCCg", "isSession": false, "isProtected": true, "expires": 1580146974, "path": "/", "name": "706b604c-184a-4235-899c-a744921ce65ceuconsent", "host": ".kijk.nl", "isHttpOnly": false },{ "isSecure": false, "value": "ts:1546450972680|consent:true|c1:0", "isSession": false, "isProtected": true, "expires": 1547660574, "path": "/", "name": "CONSENTMGR", "host": ".kijk.nl", "isHttpOnly": false }], "date": 1546451392562, "storage": [] } Copy the code in a proper text editor and save it as "kijk-consent-cookies.json" ; then use that to import in CK. Addendum 2 Those 3 imported cookies are not session but permanent ones, they expire at a time indicated by their "expires" attribute (UNIX timestamp, roughly in 6 months' time); you can use CK's editing mode to extend that default expiry further...