Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

  • Days Won


VistaLover last won the day on December 24 2018

VistaLover had the most liked content!

Community Reputation

184 Excellent

1 Follower

About VistaLover

Profile Information

  • OS
    Vista Home Premium x86
  • Country

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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...
  2. ... 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
  3. 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 ) ...
  4. ... And if you spoof a Firefox browser, they still insist you download and install the ultimate spyware, Google Chrome :
  5. ... 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
  6. Second that! All the more, since, in its settings, I have configured PSPad to be the default code editor !
  7. 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 they 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 )
  8. VistaLover

    Newest Adobe Flash and Shockwave, and Java, too!

    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...
  9. VistaLover

    Newest Adobe Flash and Shockwave, and Java, too!

    It's probably a CDN thing; I just tried the link for the ActiveX setup here (UTC+02:00) and it correctly fetched the version; content on their US distribution servers (UTC-08:00 to UTC-05:00) will update soon, methinks...
  10. @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...
  11. ... 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 )) ...
  12. ... 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
  13. 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-", 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...
  14. VistaLover

    January 1st 2019 / still 4%

    According to Qualys SSL Labs, that domain resolves to two IPv4 (, 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 (, https://www.ssllabs.com/ssltest/analyze.html?d=robotbirds.co.uk&amp;s= 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...
  15. 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...