VistaLover

According to this , USD183.00 need to be donated for a duration of one month (Apr 10th - May 10th) for the site to stay online; this sum has been covered more than twofold already , so I'd say we're good to go for at least mid-June 2022 ; BTW, I provided that link for any future reference, as (obviously) MSFN donations is OT for this thread ...

... Here's another example of using that extension, posted by its author : https://github.com/JustOff/github-wc-polyfill/issues/28#issuecomment-920212661 ... that was meant to mitigate non-compatible (with UXP) RegExp syntax served by GitLab; it most probably can't handle "tougher nuts" like ECMAScript2020+ syntax (new operators, etc.), but I still want to suggest it as an inclusion to the "arsenal" in the fight against "latest and greatest (Chrome-only) JS features" - provided one has the know-how to compile the required "filters"...

Nullish Coalescing Operator (??) is only half of the issue here ; that same linked JS script also contains the Optional Chaining Operator (?.), first implemented in Chromium 80 and Firefox 74 (i.e. unsupported in UXP-based browsers); if you do a search for "?.", you'll, sadly, find 210 (!) hits... As I've already posted in this thread, "operators" can't be (easily) polyfill-ed (and then used in extensions like chromefill/palefill), only "methods" can; for "operators", tranpilers (JS translators) must be used, like the already mentioned babel; problem (well, one of the chain of problems) is babel is designed for server-side use (website), not client-side use (end-user's old-engine browser); thus the necessity to deploy a local server (like Proxomitron) to serve the transpiled script to the browser... @UCyborg ; I don't "speak" JS/regexp myself, but have you taken a look at https://github.com/JustOff/modify-http-response ? Could this be used to "Search & Replace" an online incompatible JS script (like the linked "*.index-docs.js") with a babel-processed local version of that script? (NB: Extension only compatible with Fx-legacy/UXP-based browsers)

Specifically, no less than 22 occurrences of the Nullish Coalescing Operator (??) inside https://conversejs.org/dist/converse.min.js The above ECMAScript2020 syntax was first implemented in Chromium 80 and Firefox 72; backwards compatibility is not a thing most 2022 webmasters are concerned with... If on WinXP, am afraid only 360EEv13 (Ch86-based) and, perhaps, miniKafan (Ch87-based) are your options for "conversejs.org" ...

You can do this via the native GUI, but several cookie-related extensions also come with that function built in... One I can recommend is EditThisCookie: https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg but my most preferred cookie manager is MILK: https://chrome.google.com/webstore/detail/milk-—-cookie-manager/haipckejfdppjfblgondaakgckohcihp These extensions offer a very fine way of managing cookies (editing/protecting/etc.) besides just deleting cookies for a specific domain... Later addition: Clicking the MILK icon when on an "msfn.org" tab, the relevant cookies are auto-displayed and then you are presented with several choices of managing them, first one being deletion: If you don't want to use an extension: Load "chrome://settings/cookies" In the search field (top right) type "msfn"; the cookies set by the domain should appear as small rectangles; you can delete them all (Remove all button) or individually:

Yes, it's most probably a platform (forked UXP) rather than an application (St52/NM28/etc.) bug... Is that Pale Moon 29.4.5.1 ? Are you certain? FWIW, in my tests (St52), the bug is present regardless of the gh-wc-pf add-on... A workaround I have found is to reload the GitHub issue tab prior to the second right-click, but it's still an inconvenience...

@roytam1 : I just, accidentally, stumbled upon yet another UXP (longstanding) bug, that manifests itself on GitHub issues; the bug is there regardless of whether the relevant github-wc-polyfill extension is installed or not... I used recent Serpent 52.9.0/UXP builds to test. STR: 1. Load a new, fresh, Serpent 52.9.0 profile (default prefs, no add-ons) 2. New Tab => Paste & Go: https://github.com/JustOff/github-wc-polyfill/issues/45#issuecomment-1066105393 NB: It is imperative the body of the issue comment contain at least one active link (not only in the form of a plain "https://*" string, but any type of "linkified" string) 3. Place the cursor on top of the active link, then right click to access the browser's context menu; so far, so good: 4. Move the cursor away from the context menu, left-click to make the menu go away... 5. Repeat step 3; right-clicking this second time results in the whole content of the issue comment to get selected: I have successfully reproduced this bug with many GitHub issue-comments, with/without the gh-wc-pf add-on... Trying to find a regression range for this bug, I've spent considerable time and effort which, in the end, got me all the way back to mid-2020: Last Good build (without the bug): basilisk52-g4.6.win32-git-20200530-d6ba7ac-uxp-1cecef624-xpmod First Bad build (with the bug as described above): basilisk52-g4.6.win32-git-20200606-547d236-uxp-fdb918dea-xpmod Hopefully, the cause could be narrowed down... Obviously, this isn't a deal breaker, however little annoyances like this one make me use more often either 360EEv11/v12 for GitHub (with extra polyfills applied there via @InterLinked 's extension), while I'd be happy to cling on to Serpent 52 for most of my on-line tasks... Many thanks

Sorry for posting this here , but since several roytam1 offerings were also previously appearing on the "eclipse" forums , do any of you know what happened to "https://board.eclipse.cx/" and where, per chance, they have moved on to? Google cache has archived a snapshot taken on Apr 2nd, but currently all that is returned on the domain is an "Account Suspended" error message...

Recent Serpent 55 builds come with a BUG involving session restore on some sites such as "msfn.org"; my tests were carried out on the latest 32-bit binary, Serpent 55.0.0 (2022.04.01) (32-bit) (BuildID=20220401234639), but I believe previous build was also affected... STR: 1. Load a fresh, new, St55 profile (default prefs, no add-ons); "about:home" should be the (default) one open tab... 2. New Tab => about:preferences => General => "When Serpent (55) starts: Show your windows and tabs from last time" 3. New Tab => Paste & Go: "https://msfn.org/board/topic/180462-my-browser-builds-part-2/page/44/" ; wait for that URL to fully load 4. Change focus to another tab, e.g. the first one (about:home) 5. Exit the browser 6. Relaunch the browser; session restore should kick in, with 3 tabs present in the tab bar, focus on the first (L to R) one (about:home) 7. Select the 3rd tab (https://msfn.org/*); instead of the content loaded during the previous session (or an attempt to reload the tab), the browser displays the following error: ... which isn't the expected behaviour... FWIW, clicking the "Try Again" blue button does end in the "msfn.org" page fully loaded, but the "bug" repeats itself the next time the session is restored; remember, for the bug to be replicated, the "msfn.org" domain tab has to be out of focus when the browser is exited! basilisk55-win32-git-20220226-01d12e322-xpmod is the last good build that doesn't exhibit the bug, basilisk55-win32-git-20220326-216281f40-xpmod is the first bad build with the bug; so I believe it's either something inside the first batch of the UXP stuff ported over to moebius or something inside the NSS Mozilla stuff... Your attention to this reported bug will be highly appreciated @roytam1 , best regards! PS: Serpent 52.9.0 doesn't suffer from this (but I'm still on the 2022-03-25 build...).

... You can always opt to clear just the cache, but retain the cookies... The main reason I suggested wiping cookies is that you yourself stated that "the problem sites load OK in a private window"; private windows, as you might know already, don't take existing cookies into account, new, "private", cookies are temporarily stored for that window and then auto-cleared when the window is exited... Are all the sites refusing to fully load ones you were already logged-in? If not, try a "problem site" which doesn't require you to have an existing account, selectively clear the cookies for that site and try to reload; if successfully loaded, then your predicament is definitely cookies-related... I don't own a mobile device myself (yes, you read that right ), so 2FA is a no-go for me; I personally think of it as yet another Google/Apple ploy to buy one of their mobile devices; I haven't enabled 2FA on any account that demands it, I just use very strong passwords (> 20 characters long), which I change very often (at least once every 3 months, and that includes my e-mail password); no on-line account of mine has been hacked yet (fingers crossed)... My two banks aren't happy, to say the least, but I still manage for the time being; on-line purchases/payments are limited to where absolutely necessary, pre-paid cards used most of the time... And, of course, I'm no member of any of the youth-oriented, very popular, social media sites/portals, these are the ones mostly requiring a "smart" phone and 2FA; one notable exception is Discord - I had to join a private server there and Discord are constantly nagging me about 2FA and installing their mobile app on my "phone" (little do they know me...) ; but I'm obviously going off-track... FWIW, accidents do happen, you should be always able to re-log, 2FA or not, to any of the sites you have created accounts for... Like my friend @NotHereToPlayGames, I'll also advise strongly against tab-hoarding! This isn't the reason tabbed-browsing was created for, I never find myself having more that 20-25 opened tabs during a browsing session... An increased number of tabs slows down things considerably, especially in the case of UXP browsers like Serpent, which have been engineered/optimised by "upstream" as single-process applications... You can create a bookmarks folder with all currently opened tabs, then each and everyone is just two clicks away - and bookmarks usually survive a browser-crash, not always the case with browser sessions ... In any case, you can back-up your current dirty profile, as suggested, so you'll have a working copy of it to fallback to... Session (includes opened tabs) info is stored in profile "sessionstore-backups" directory and "sessionstore.js" file... Assuming you have opted for When Serpent starts: Show my windows and tabs from last time you should be good recovering your session; and sessions can and will become corrupted over time, especially with a large numbers of tabs, you have been warned! Cookies OTOH are stored in the "cookies.sqlite" profile file; account credentials in "logins.json" (in conjunction with key3.db file). In fact, I'm never in any "rush" to update to the latest release of St52 (or any other app, for that matter) as soon as it's being released on a Saturday... I usually wait until the middle of the coming week, to see if any "issues" with it have presented themselves here in the forum, then I do update, having first created a backup of my dirty profile, just for good measure... As you say, I can't test the 64-bit binary here, but the 32-bit one [Serpent 52.9.0 (2022-03-25) (32-bit)] has been running for the last four hours without any noticeable hiccups ; my browsing session was successfully restored after the upgrade from the previous (2022-02-25) St52 build, I remained logged-in to both of my GitHub and MSFN accounts; ImgUr (not logged-in user) gave me some slight issues during uploading the images in this post, perhaps it was something on their end - we'll see; in any case, I have no URL refusing to fully load here! Some NSS library changes were included in these latest builds (as posted previously elsewhere in this thread), perhaps they affect the way (some) cookies are encrypted/stored/decrypted in your setup... Unless some other member here comes forth with issues similar to yours, affecting latest St52-x64, we'll assume, for now, that the issue is limited to your end; you'll have to provide additional, detailed, info about your profile, such as extensions used, etc. You've been given ample guidance on how to tackle this, as an additional test log-out from just one of the problematic sites (clearing its cookies), then try to log back in and see how that goes... Sometimes, instead of spending too much valuable time troubleshooting things at length, it's best to just dive-in and start fresh (... the "moto" at my local computer-repair shop : a re-format and OS re-install is what they always come up with for anything I seek remedy for; fortunately, on-line communities such as this one exist... ). Best regards

1,885 changed files with 168,699 additions and 191,064 deletions. Was that just to make things extremely painful for fork-maintainers ... And it turns out I was 100% correct in my suspicions... Moonchild himself admitted this, in the latest installment of the PM "drama" (i.e. after M.A.T's exit): https://forum.palemoon.org/viewtopic.php?f=62&t=28090 TL;DR: "GRE" has been now dropped, official Pale Moon v29.4.5.1 has been released, there'll will be no more v30.x.x/GRE releases, v31.0.0/UXP will be released "in the fullness of time"... What a fine mess...

... He already said that he did and the previous 64-bit St52 build works OK: Have you tried clearing up both browser cache and cookies and then restart the browser (in normal, non-private, window) ? If clearing cookies, you'll have to log-in again to the sites you were previously logged-in... Also, and this is essential, have you tried to replicate your issue with a new/fresh St52 profile? Are those FxESR 52.9.x and Chrome 49/50 (yes, Chrome 50, if you can still find it, works fine on Vista SP2) ? For the sites not supported in UXP browsers (like Serpent 52/New Moon 28), you can check versions 12 and/or 13 of the Chinese-made 360 Extreme Explorer (Chromium 78/86 forks); you can search for them in other MSFN threads, where you'll hopefully find that two competent fellow MSFN members have created and shared modded versions, with practically most of the Chinese "spyware" removed (however, these mods are primarily targeting WinXP usage...). Welcome to the forums, fellow Vista user !

... Probably what had happened to Windows 9.0 ... In all seriousness though, I think "they" (the Chinese) have adopted the "same application version as current year" model (360EEv21 was first released in 2021); come to think of it, their year is lunar-based, do they even observe the Christian calendar (as in 2021 AD) ? Perhaps they do, in relation to the rest of the (Western) world ...

@dmiranda : Try the link below, https://addons.palemoon.org/addon/getemall/ with the following SSUAO (that I successfully use): general.useragent.override.addons.palemoon.org;Mozilla/5.0 (Windows NT 6.3; rv:68.0) Gecko/20100101 Goanna/4.8 Firefox/68.0 PaleMoon/29.4.5

I second that, @roytam1 However, as I am heavily reliant on GitHub, I was sort of miffed that GH still doesn't work in latest St55 (32-bit) with the latest release (v1.2.17) of gh-wc-pf force-installed; in the not-so-distant-past, GH used to (mainly) work in St55, but, as said, M$ threw at it many recent JS "baddies" that eventually broke it completely ... I understand St55 is under a monthly release schedule, how far do you reckon we are from a working GH implementation (of course, with the aid of gh-wc-pf) ? Thanks for all you do for us, "greedy" users of your browsers!

What "3 codec DLLs" are you referring to? New Moon 28 doesn't require any additional "patented decoder DLLs" (aka LAV DLLs), only New Moon 27 does... This should be generally avoided, as "upstream" use a different modded version of the NSS Mozilla library (hence cert8.db+key3.db resultant profile files); at least that's my recollection of them, I stopped closely following their development when they turned "private-repo" last autumn (FWIW, GRE+PM are now public, again ).

(I thought it important to quote all these relevant parts, due to the intervention of a great number of completely irrelevant posts...) @roytam1 : This seems indeed a genuine bug affecting the most recent NM28 release, however it's particular to the 64-bit binary ; as others have already chimed in, the 32-bit binary behaves as expected, below is my own screenshot from it, running (pristine new profile) under physical Windows Vista SP2 32-bit (fully updated, with selected WS2008 updates manually installed): Of course, I couldn't test the 64-bit equivalent there , but I borrowed briefly my sister's Win7 SP1 64-bit laptop (fully updated to Win7 SP1 EoS), and the story is the same (as already reported by @nicolaasjan) : Taking a look at the provided changelog, and at a quick glance, I can only spot [NSS] ported mozilla upstream changes (a squash of several, NSS-related, Bugzilla bugs) as potentially the culprit for this breakage, manifesting exclusively on the 64-bit compile (but I could be wrong, I have been in the past ) ... Could someone also test, for that same bug, the 64-bit distribution of latest Serpent 52.9.0 ? I don't have a need myself for the 64-bit binaries, but, obviously, others do... Thanks in advance for any additional info...

Most sadly, no such hope could ever materialise, at least on the part of the Chinese... 360EEv13 is based on Chromium 86, its latest release currently being 13.0.2310.0 (issued a mere two days ago...); no planned core updates (to Chr>86) are scheduled for v13.0 ... The Chinese have already upgraded their 360EE browser to v21.0 (Chromium 95 based), which has dropped altogether WinXP+Vista support and, to add insult to injury , is being offered exclusively as a 64-bit binary... Sorry for sounding pessimistic, but that "ship" you're alluding to has already sunk ... [For XP/Vista 32-bit users, 360EEv13 is the most advanced version we can currently rely on... It will certainly buy us some additional time (for those of us that have the H/W to properly support it ,), perhaps well until the end of current year, but if "popular" sites insist (as is the trend now) on implementing latest (>=99.0) Chromium features, the end is near... Already several Chromium extensions I currently use (in my 360EEv11-13 copies) have migrated to MV3 (Manifest Version 3), which demands at least Chromium 88; it's fine when older extension versions do still work (but it'll get more difficult to retrieve those older/previous versions), it's not fine when an extension gets updated (alongside MV2->MV3) to mitigate a service/site change it targets... ]

Official Pale Moon v29.4.5 released ... Also, something that really made me ROFL: https://web.archive.org/web/20220322142423/https://forum.palemoon.org/viewtopic.php?f=65&t=28003&start=80#p225547 (above proposal was suggested to Moonchild, perhaps meant seriously, but... really? )

I get similar Javascript Console errors in 360EEv11 (chr69-based): Uncaught SyntaxError: Unexpected token . in https://www.rb.cz/scripts/main.9082edf4740251c6.js And this is by simply loading the page; clicking the blue button produces an additional (CSS?) error: problem calling custom script: ReferenceError: $ is not defined at HTMLDocument.<anonymous> ((index):14) Their "main" script uses no less than 110 (!) invocations of the optional chaining operator (?.), an ECMAScript2020 feature (first implemented in Chromium 80/Firefox 74)... The master villain is, again, a Bank URI; perhaps they "feel" using the latest and greatest JS "goodies" makes them look "more safe" in the eyes of their otherwise "clueless" clients ; I'm of the opinion the @NotHereToPlayGames route should be pursued here, too...

@roytam1 Moonchild has withdrawn the PM 30 branch (both releases v30.0.0 & 30.0.1) and now (only) offers, again, PM v29.4.4, while a "security-only" release v29.4.5 is in the works... The PM 30 milestone will be re-engineered, with a strong probability of the dual GUID system - as was in v29.1.1 - coming back, and a fresh v30.1.0 will (after v29.4.5) be released in "due course"... So, perhaps, it'd be prudent not to hasten merging "current" GRE into "our" UXP tree (as suggested by https://github.com/roytam1/UXP/commits/custom ) ; what are your plans? Many thanks!

Sadly , that "format" of yours no longer produces the "calendar for a specific year" in Tycho-based New Moon 27, so users of that (e.g soggi) and even-older-engine browsers can't profit from it... Works OK, though, for UXP-based browsers ...

Firefox Quantum 63.0, to be exact (less finished implementations were behind a disabled pref in immediately previous Fx versions) ... I, personally, don't give that test the credence/importance others do... Have often found it to misrepresent browser features (especially when it comes to the non-mainstream browser engines), so my advice is to take its reported results "cum grano salis"... According to this UXP open issue, https://repo.palemoon.org/mcp-graveyard/UXP/issues/1361 Shadow DOM v1 is still marked as unfinished (further below in the issue, they cite Element.attachShadow() Element.shadowRoot() DocumentOrShadowRoot.activeElement as having been implemented...) Relevant GRE issue https://repo.palemoon.org/MoonchildProductions/GRE/issues/3009 signals Shadow DOM support is still not "FULL" and, of course, WebComponents support (of which both ShadowDOM+CustomElements are integral parts) is still marked as unimplemented... https://repo.palemoon.org/MoonchildProductions/GRE/issues/3011

... But you did quote in your previous answer @Ben Markson's post about the "mozlz4_edit" add-on (which he installed in FirefoxESR 52.9.0) and that was the bit that got me sort of confused ... Anyhow, there's no point in flogging a dead horse, by now I think the both of us made really clear what we intended to state... Have a nice night, spring already came here in the Northern Hemisphere (but it's awfully cold right now, despite... ) Later addition: soggi commented: This wouldn't have worked in any case , because the "mozlz4_edit" (Fx) extension is of the "Web Extension" format, not compatible with New Moon 28 (and it still wouldn't serve any purpose had it been compatible, because NM28 doesn't use the mozlz4 compression for any of its profile files ...).

This is ONLY applicable as-is for New Moon 27/28 (and possibly some other browsers like BNav & K-Meleon, which I don't use myself); FxESR 52.9.x, St52 & St55 by default DON'T store search engines inside a profile "searchplugins" directory, but inside a profile search.json.mozlz4 file - I thought I was clear on that... If you want to import a manually crafted XML-format search plugin in, e.g., St52 without an extension, you'd first have to manually create a "searchplugins" directory inside the browser's profile (it isn't there by default), place within the XML file and RESTART the browser; then the XML file is internally converted to the JSON format and stored inside the compressed search.json.mozlz4 file (this procedure mimics a profile "upgrade"), after which time you can safely delete the "searchplugins" folder, it served its purpose... What is "cumbersome" for one person might not be for another, I respect that , but let's not dispute the real facts, please... Anyhow, whatever tickles your fancy... Best regards