VistaLover

Please, to avoid issues with "upstream" developer(s), always refer to the browser as Serpent 52; as already verified by another member, I, too, have no problem at all "fullscreen-ing" video content from banbye in my St52 copy: As you can expect, I do not have an account with banbye, so can't check whether what you report is specific to logged-in users of that video portal ... In general, site/player preferences are being stored inside browser and/or HTML5 cookies; I'd start by fully wiping out ALL banbye set cookies, clear the browser cache and restart browser - often times, a user setting (e.g. inside a content blocker like uBO, uMatrix, etc.) will block a site from writing/modifying needed cookies and thus site functionality will be impaired... I'd suggest to you to try the banbye site (its new iteration) in a fresh St52 profile and draw conclusions from then on ...

... That post is quite old by now ; the UXP-based browsers now are fully equipped with all the necessary plumbing (JS features) to fully support discoursed-based forums (their "full" version, not the "dumbed-down" one targeting unsupported browsers); however, their browser-detection scripts fail to recognise UXP-based browsers as "supported", so those sites offer to them that "simplified" version ... Some weeks ago, I had answered that same question posed by j7n but he didn't opt to apply my suggested solution, because it involves an adblocker extension (uBlock Origin legacy) and he did not want to install it himself, because a) he had already other arrangements in place to thwart ads b) he feared that installing that adblocker would, somehow, compromise the quality/speed of his browsing... Here at MSFN we are a democratic community, so I respect his reservations ; this doesn't mean others are discouraged from acting differently ... If one has already installed uBO, a custom filter can be added to block the script discourse-based forums serve to sniff browsers: ! Discourse-based forums ||*/assets/browser-detect-$script,important That should be added in the "My Filters" tab... OTOH, if you have a userscript manager installed (usually their names end in "*monkey" ), you can add a custom userscript like the one below: // ==UserScript== // @name CSS aspect-ratio [88] - Discourse Forums // @version 0.0.1 // @match *://*/* // @run-at document-start // @grant none // ==/UserScript== !function() { let CSS_supports = CSS.supports; CSS.supports = function(a) { return a === "aspect-ratio: 1" || CSS_supports(a); } }() This userscript doesn't block the browser-detecting script, it simply tells it that the feature it's looking for exists in the browser (it doesn't, as of now, in reality, but it isn't needed either for properly displaying those sites) ... So, @adata, you're being offered two current solutions for properly displaying and using ALL the discourse-based forums (not just the three you referenced in your post ) ... Best regards ! EDIT: If you're NOT running a recent version of Serpent 52, please DO update, preferably to this weekend's release!

Raise your hand anyone if you think below announcement is just a coincidence : https://forum.palemoon.org/viewtopic.php?f=5&t=30782 (I mean, do you see the "double standard" there? When he was referring to the users of "the forks" as "beta testers", his tone implied a negative connotation for the term; now, he's in need himself of "beta testers" for his own "official" browser, in which case those "testers" are a "good thing", of course ) ...

Something wrong there in your URI pasting ; for those that do want to read that patronising post, the link is: https://forum.palemoon.org/viewtopic.php?p=247714#p247714

I won't even bother falling into that "trap" and start commenting on it ; "The MSFN-type people" ? WT...? My little faith towards reconciliation has just evaporated ; back to your positions, "MSFN-type people", we're again back to "square one", otherwise put: The old SNAFU... A great pity, though ... If inactive for a large amount of time, your PMForums account will be, eventually, purged, but I don't think you'll lose any sleep over that, will you? ...

... ... Well, when basilisk-dev first went "public" here, he outlined his "intentions" in a crystal-clear fashion that I immediately understood and respected ever since; to summarise, off-the-top-of-my-head: 1. He is NOT inclined to support any other Windows OS beyond what the official UXP platform supports (currently, Win7SP1 and up; though, if I were to rekindle past debates, MCP had declined back then to extend UXP support to Vista (NT 6.x family) because the vendor (Microsoft) had, at the time, just ended Extended Support for it ; where does Win7 stand now?) ... 2. His support is ONLY limited to the official (stable) Basilisk binaries he himself compiles and publishes. 3. The main - but NOT exclusive - channel to reach out to him for support, with 1+2 above still being honoured, would be the PMForums dedicated Basilisk subforum . To the best of my knowledge, I have never gone against his wishes, so whatever "infuriation'/bitterness he tried to vent "there" doesn't touch me in the slightest... Additionally, 1. Whether basilik-dev doesn't want to be forewarned about potential bugs in the platform (UXP) his own application builds upon is his own prerogative (though slightly unfortunate, if my personal opinion was queried) ; it's basically the platform's master branch that we, fork users, get first to be exposed to; I think there's a misinterpretation of incentives plaguing the MCP camp: since when is "potential" bug reporting equal to "blaming us for them (the bugs)" ? My impression still is that any bug reporting (on any project) isn't meant as an accusation, rather as an attempt for betterment - I do file many bug reports on many open-source projects, when I sometimes happen to be in error (yes, I do ), the project's maintainer just labels my bug report as invalid (and usually explains why that is so), but never jumps onto accusations/name calling against me... 2. The "tagging" basilisk-dev part: Well, I did recently tag him myself, but it was only after a bug initially discovered in Serpent 52 was found to be reproducible in the latest official Basilisk binary, run on a sanctioned OS: I was hoping an acknowledgement of this bug (the "dropbox" one) would come from basilisk-dev that would have put things in motion towards its hopeful resolution by "upstream", but so far nothing of this sort has happened; was I in error to "tag" him about it (since the bug is present, too, in his own binaries)? I honestly don't think so... 3. ... As things stand, and that's already common knowledge to members here that read Roy Tam's weekly "release notes/changelogs", basilisk-specific code from here is only sparingly+selectively copied over to Roy's UXP-custom-branch; in fact, more often than not, his changelogs state: So I don't really see what that "Basilisk master branch" argument was about ; and, honestly, were you really "flooded" with unjustified reports about official Basilisk from St52 users, as hinted? Or was it, like, once or twice by some misguided St52 users who ought to have posted here but didn't even bother to search for "here" at all? In conclusion: I don't think I, personally, owe some form of apology to basilisk-dev for any wrong-doing; his post in the PMForums thread I'll describe as mostly emotionally-charged and/or somewhat biased ... Disclaimer: My views here reflect only me, personally, not MSFN as a whole or Roy Tam in particular... Kindest regards, a "happy" alpha-tester ...

...The "magnifying glass" icons in the column headers open popups that can be used to locate specific filterlists (via their name/description); the "funnel" button on the "software" column can be used to filter based on adblocker used; filtering for "Easylist" and (software) "uBlock Origin" gives me the "Easylist (Optimized)" FL (that I mentioned previously) as the third entry in the second results page:

... Er, that's just typical ol' Moonchild there , not surprised or impressed... That's why I specifically cited martok (the author of the code involved) as the person to be contacted, NOT MC... In any case, I don't feel guilty myself of proposing something "inappropriate", nor should @UCyborg apologise for his intervention (and his wording, in all of his posts in the linked PMForum thread, was very civil and to the point ) ... In fact, MC was ready to "wontfix" UXP#2452 (based solely on the unwarranted use of NoScript involved), so I just thought, out of genuine consideration in the broader term, that the case of "https://www.theregister.com", which never surfaced among the MCP discussions, be brought to martok's attention, too... Hang me in the town square, won't you? ... A simple yes or no, "thanks for letting us know", from their side would have sufficed... But, perhaps I'm being too naive... Any impartial by-standard will admit that "us" here act, in an indirect way, as α-testers of upstream's UXP master branch, as being the first to be more widely exposed to that code, despite "our" tree's divergence from "official" UXP; this view is, actually, shared/recognised by @dbsoft in this post ; mind you, MC had himself abolished PM's unstable branch/releases some years ago, because very little of his target audience actually used them and reported existing bugs ... And, FTR, I, personally, don't mind being "a guinea pig" ; no-one forces me to update every single weekend (I usually just update once a month or when important webcompat fixes arrive), and before ever updating, I always take a back-up of my current "dirty" profile, in case things break (extremely rarely); going back to a previous build is "a piece of cake" under that scenario ... ... I have always suggested that (even very recently, read this regarding the "dropbox" UXP bug, still "a thing" with official apps, too), but it was NOT feasible in this case because martok's code wasn't present in the latest official "stable" binary releases - I, and I suppose most here (excluding you ), wouldn't be able to compile that "upstream" sourcecode and test that URL on the resulting binaries... Focusing on just "the issue itself", martok responded here that he's unable to reproduce; so, was, in the end, the "www.theregister.com" induced crash in xul.dll (before the fix) particular to "our own" tree? In any case, martok has now prepared UXP#2459 and MC is probably OK to merge it, so all this discussion will become moot... ... Pardon me for asking, but do you think there will ever come a time when some bridges could be built between the two "communities"? We now have @basilisk-dev gracing us with his presence here (but, strictly speaking, not a member of MCP ), plus at least two MCP members are now members here (with different usernames), with at least another one silently following this thread (by his own admission) ... I'm not sure if it was just pretense, but MC seems to still have a beef because: Does this leave a small ray of light come through? Would MC ever accept one "genuine solution" by you for official UXP if you were ever inclined in the future to offer it (rhetorical question, probably...) ? Before anyone here accuses me of old-age-caused dementia , yes, I was here ALL along during the many dramas of the past, but I'd like to see a glass half-full rather than half-empty ; frankly, all this toxicity that existed/still exists between MCP and "us" burdens my soul and if mutual compromises between the two "parties" have to be made at some point, I'd be the first one to welcome them... Just my own humble opinion, though ... Best regards, always extremely thankful PS: December 2023 is well behind us now - any development regarding the "Glory to Hong Kong" song judicial saga (you're still with us here, your repo and blog are still alive, so I suppose things are calmer now?) ?

https://forum.palemoon.org/viewtopic.php?f=62&t=30769&p=247631 Many thanks! Sure thing ; I had no issue passing the hcaptcha challenges (two successive sets of images) in St52 (dirty profile): The text next to the green tick reads "I'm human", the text in green letters reads "Challenge Success!" Have you tried in a fresh PM profile? I can report similar success when using latest NM28, but won't post a screengrab, due to late-night laziness ...

... Yes, and you'll have to thank @martok for that (the German creator of PaleFill ); martok is himself a Frtiz!Box owner, so he had immediate interest in getting this fixed (as it turned out, all by himself ) ; look here ... The "fix" materialised as Implement PromiseRejectionEvent but, while working on that, Align microtasks and promises scheduling with current spec also had to be implemented ; however, that last one is the cause for the much-discussed here NoScript-related crashes, so the moto "fix something, break something else" comes to mind (often inherent with coding, especially on such complex sourcebases) ... The new issue opened about it looks like is heading to a "wontfix" (at least where Moonchild is concerned), but someone should alert martok (somehow) that at least one URI induces a browser crash without the presence of the "evil" NoScript extension ...

(Slightly OT: ) I recently became aware that the "geckorevision" value for FxESR 115.x.x has been frozen at "rv:109.0"; so, actual FxESR 115 on a Win10 x86 OS will report: Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0 You can read more about that here (bugzilla#1805967) ... Additionally, some years ago, the decision was made by Mozilla to deprecate the "WOW64" slice, so, even if you're using the 32-bit release of FxESR on Win7 x64 OS, your browser will advertise its bitness as x64: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109) Gecko/20100101 Firefox/115.0 Read more at bugzilla#1559747 ...

Well then , I can indeed tell you that: https://www.theregister.com/ is able to crash Serpent v52.9.0 (2024-01-11) (32-bit) in xul.dll (without ever having installed NS in its profile), while the hotfix release Serpent v52.9.0 (2024-01-13) (32-bit) can load that site fine! So, thank you @modnar for reporting a NS-unrelated case where the "microtasks" bug can be witnessed! Kind greetings, good night and have a good week ahead, too!

I still am on the initial release of St52 (BuildID=20240111073248), late Friday night in my timezone (UTC+02:00), that doesn't contain the "NoScript mitigation": https://github.com/roytam1/UXP/commit/c75d50addea4f134130f2f2d822aec7f56f4cbd3 NoScript, as posted already, ISN'T installed, both https://www.majorgeeks.com/ and https://www.register.com/ do NOT crash the browser and load OK; yet another proof that NS, when installed, does hook deeply into your browser, even when disabled ... Though, in the case of "www.register.com", the browser mis-renders the site's CSS: Can anybody else reproduce, or should I start digging into my dirty St52 profile (not an ideal way to pass one's Sunday evening ) ?

... Well, call me the odd one out, but (browser) extensions were created/exist to extend the browser they target, NOT the other way round ; especially in the case of a maintained browser, whose engine and features frequently change/are being modified to adapt to the (mostly Google governed) current web! As AstroSkipper has pointed out above (sorry , I've run out of "reactions" for today), NoScript-legacy is an abandonware now; why should the browser dev(s) commit to an obligation to support it (or other abandonware extension) indefinitely? I understand the recent NoScript-related crashes may be related to some coding "mishap", but I have to emphasise once more that "upstream" do not code with NoScript in mind (or test the authored code with it installed); so, even if you , you're indirectly impacted by their coding practices (and their determination NOT to support in code "your choice" of extensions ) ... Along my long journey using Mozilla Firefox (from v2.0.0.x to 52.9.1), I lost several extensions I considered "must have" at the time, because Mozilla devs made coding decisions (while still in the XUL era) that introduced incompatibilities with said extensions, that their authors were unable/not ar*ed to "fix"... Only very rarely and at older times, when Mozilla wasn't a Google subsidiary, did they care to "fix" popular "broken" extensions (DTA!, uBO, e.a.) by modifying themselves the core browser code, instead of transferring all burden to extension maintainers ... Right now, I'm running a self-concocted version of Stylus (git-1.5.22+92) in St52 that isn't able to store its settings longer than a browser session, plus has other shortcomings even in that same session ; I need that a recent version because the Fx52-EoL version (1.4.23) comes with an outdated CSS parser that prevents it from installing recent versions of "user.css" userstyles; no "legacy" userstyle manager exists that can support "user.css" styles; Stylem hasn't been updated for 1.5yrs, no plan to support Stylus-targeting styles, either... It would be unrealistic to expect Roy Tam to come up with a "fixed" Stylus version for Serpent 52/55, on a par with latest Stylus 1.5.42; even more so if you direct your pleas to Stylus maintainers themselves, their mantra being UCyborg is (again) right: MCP were delusional when they expected an XUL-extension-development resurgence, ready to cater to their no-WE-supporting browser platform... Frankly, I'm feeling very pessimistic over the challenges 2024 will put on "our" legacy browsers ...

Due to dropbox's (semi-)popularity, this issue has to be acknowledged and troubleshot, hopefully mitigated... ALL UXP-based browsers (and their current sibling , St55) suffer from this annoyance; here's latest NM28 with the bug: The Error Console only prints cryptic messages: Timestamp: 14/01/2024 01:28:02 Error: uncaught exception: ApiError Timestamp: 14/01/2024 01:28:03 Error: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://browser/content/browser.js :: onStateChange :: line 11154" data: no] Unlike previous DB breakages, this doesn't seem to be fixable by a SSUAO ... FxESR 52.9.1, at its default UA, simply loads a blank page now on the given DB link ; what's interesting, though, is that such an old Chromium version as 69.0 (actually, 360EEv11) is able to display the text inside those buttons properly: @mina7601, are you able to reproduce in the official clients, i.e. Basilisk 52.9.2023.12.09 and/or PM 32.5.2 ? If affirmative, perhaps @basilisk-dev or some member of the MCP team (I'm sure some of them, God bless their kind hearts, do occasionally visit here ) should investigate; else, perhaps @roytam1 can have a go at it... FWIW, after seeing "which button is which" in Ch69, I can now use DB in UXP, but... what the heck? ...

Thanks for asking about my opinion but, to put it honestly, I don't consider myself a uBO expert ; in the past I had tried (hard) to follow the kind advice/hints of MSFN's uBO guru, @Sampei.Nihira, when he was still using these browsers in his XP box (now, I understand, no longer ON); plus, things I picked over time from GitHub issue trackers related to adblockers... It was via those avenues I was introduced to this excellent portal: https://filterlists.com/ a veritable treasure trove of content-blocking, open-source, subscriptions ... Being on under-resourced H/W and on a 32-bit OS, I had tried to slim-down (somewhat) my uBO installation (to reduce RAM consumption by the browser) and it was then when I spotted the "Optimized" renditions of the stock EasyList+EasyPrivacy FLs: EasyList (Optimized) https://filters.adtidy.org/extension/ublock/filters/101_optimized.txt EasyPrivacy (Optimized) https://filters.adtidy.org/extension/ublock/filters/118_optimized.txt I test-installed them in lieu of the default ones, tried them over an extended period of time and found them to be equally efficacious, so I'm stuck with them ever since ... I still have: https://hostfiles.frogeye.fr/#whats-a-first-party-tracker installed in uBO-legacy (recommended at the time by Sampei), which is still being maintained/updated; supposedly this isn't needed anymore in the current WE version of uBO, but can't say with any degree of certainty whether this is so in the case of uBO-legacy ... Until recently, I also kept installed some flavours of ZeroDot1's CoinBlockerLists, but these aren't being updated regularly anymore... So, basically, that's it ; IOW, the real experts must come forth!

The ad-blocker detecting scripts in both the HTG and XDA-dev sites are being served by Admiral: https://www.getadmiral.com/pb (The brand name Admiral is also visible in the screengrab I posted above ) With slightly more free time on my hands now, I loaded a minimal NM28 profile with a default/stock installation of uBO-1.16.4.31b2; there, I, too, got blocked by the XDA-dev site, like attested already by UCyborg and AstroSkipper; if I just disable the stock EasyList filter list, I get through, but then I have to consent to Admiral's tracking: I briefly went through that form of theirs and, honestly speaking, I felt extremely violated by the extent of their tracking and data harvesting; 1,512 third parties want to store/access data on my device simply because I happen to want to load that site; this is pure insanity, if you ask me ... This is why I consider content-blockers of equal importance to the browsers themselves when surfing the (mostly hostile) web...

... And I was NOT blocked on the XDA-dev site probably due to me using "EasyList (Optimized)" instead of the stock "EasyList": For anyone interested: https://filters.adtidy.org/extension/ublock/filters/101_optimized.txt

... Yes, I do!

In my St52 copy, with the original UBO-v1.16.4.31b2 (will check the mods created by AstroSkipper hopefully tomorrow), I don't get blocked by the XDA-dev site ; I do, however, have many custom-added filter lists and several changed ones (out of the default set), so it's possible one of these is responsible for thwarting the blockade ... OTOH, I do get blocked by the HTG site, however I've learned not to be easily intimidated by such ploys ; uBO-legacy is still able to nullify the block by a simple "cosmetic-filtering" rule: ! 2024-01-13 https://www.howtogeek.com www.howtogeek.com##.bOvWNQ The purists will say that the ad-blocker-detecting script passes through and is still executed (unlike with the current, WE, version of uBO in supported browsers), but for me the end result counts, i.e. I'm free to browse the site without disabling and/or further configuring my content blocker ... Of course, it's always been a "cat-and-mouse" chase, so one must always stay alert...

... Nope, I've never used NoScript in my entire browsing life (that'd be 17yrs now - the internet came in late in my household ); especially when it comes to UXP-based browsers, where, from the very beginning, "upstream" declared they don't support its usage with "their" browsers... I'm part of the "less-is-more" group here, only been using uBO (and, at times, Privacy Badger) in my browsers (both Mozilla and Chromium based) as content blocker, NEVER got infected through a browser, but I do acknowledge NoScript as having an avid userbase among MSFN members ...

... Is that St55? Why have you renamed the main executable (from "basilisk" to "firefox") ? ... You'd have to discover this yourself, via trial-and-error. ... Make a backup of the current version of the profile file "prefs.js" and then, on a fresh St55 profile, try adding progressively, one-by-one, your custom "about:config" modifications, until the "fresh" profile breaks (i.e. produces the same URL crashes as your "dirty" St55 profile); been there, done that, NOT a happy pastime, I can guarantee you that ...

Well, that seems to have fixed it : Nice job!

... Can't repro here ; tried in both latest NM28 [v28.10.7a1 (32-bit) (2024-01-11)] and latest St55 [v55.0.0 (32-bit) (2024-01-12)]; what I can tell you, though, is that: https://wiki.mozilla.org/RapidRelease/Calendar now redirects to: https://wiki.mozilla.org/index.php?title=Release_Management/Calendar&redirect=no and that last one loads fully and OK in both the above browsers; below, a screengrab from my St55's "dirty" profile: Try in clean profiles, in case one of your extensions and/or customisations interferes here... Later addition: I only saw your edit: after I hit the "Submit Reply" button ...

... For more than a year , Serpent 55 is incapable of properly/fully loading: https://web.archive.org/ (referred to as WAO henceforth); below, a screengrab from a fresh St55 profile (latest build): The error appears to be jQuery related ... OTOH, the UXP forks have no problem properly loading WAO (screengrab from latest St52 - dirty profile): Dear @roytam1 , can you investigate and identify which feature from UXP needs to be backported to St55 so that it, too, loads a working version of WAO? My default is St52, most people here know already , but sometimes, especially with GitHub, I also launch St55 ... Thanks in advance, best greetings!