Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,245

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    ... The short version of it is both ; long version below: Having originally been a Mozilla Firefox fan only, my first acquaintance to Userscript Managers was via the XUL/legacy version of Greasemonkey ; at some point in time, this was converted to the much restrictive WE format , to which I did never migrate... When I started using the UXP-based browsers, NM28 initially, I migrated to the UXP-fork Greasemonkey for Pale Moon (now an abandonware ), which was also kept when I decided to move over from NM28 to Serpent 52 (because the latter had kept support for WE - I needed to use Stylus there, because many of my preferred userstyles had migrated over to the "user.css" format, which Stylem doesn't support ) ... While in St52, I explored the availability of actively maintained WE userscript managers, the two more prominent choices were Tampermonkey and Violentmonkey; TBH, I was quite miffed that TM had already dropped support for Fx52-level platforms, with only a much older version being installable in St52 (I have v4.11.6120beta archived on disk) ; additionally, while TM was in the past open-source, it had already moved by then to closed-source development... OTOH, Violentmonkey was, and still is, open-source and actively supported Fx52/St52, so I chose to install VM in St52 and have kept it ever since ; when I started experimenting with the Chromium derivatives that support Vista SP2 32-bit, I installed VM there, too, because I had grown accustomed to it ... As far as script compatibility is concerned, it's true that most userscript authors first target TM, because it's more popular I guess; but VM should also do the job in the 99% of cases; incidentally, the "Restored Pagination for Google" userscript works better in VM than TM, it says so in its code: // @match only allows wildcards for the TLD in ViolentMonkey, not in TamperMonkey or other alternatives Ultimately, it's down to the English saying: "whatever tickles your fancy" and for me it's VM... Kindest greetings (in the hope you're not under 2m of snow there ) ...
  2. VistaLover
    ... I noticed that, too, myself ; having no JS knowledge , my "dirty hack" was to use "cosmetic filtering" in uBO and hide the "More results" button at the bottom of results page no. 1: www.google.com###cc www.google.com##.w7LJsc.WZH4jc However, a "proper" fix inside the userscript itself would also be much appreciated here ...
  3. VistaLover
    Fixed (initially, only "link text" had been edited, while the URL itself was not, sadly - old age is a b***h ) ...
  4. VistaLover
    Thanks you two for your input ; after deeper troubleshooting, it appears my inability to permanently disable "continuous scroll" inside the "modern" GS settings in my browser profile(s) was indeed due to some protected Google cookies, specifically the CONSENT and NID ones ; I had to un-protect them, delete ALL Google-related cookies in my browser profile, then a) disable uBO, b) disable ALL Google-related userscripts inside Violentmonkey (some of them affect G-cookies) c) load "www.google.com" and consent to them setting browser cookies, d) access the GS settings page(s) and configure GS how I see fit - now the (disable) "continuous scroll" slider position would stick e) protect anew the NID+CONSENT cookies f) re-enable uBO g) re-enable the Google targeting userscripts inside VM I was then able to enable and successfully use the https://gist.github.com/sp00n/e8b91d2f47c471bc0627f7b31d659291 userscript posted by nicolaasjan : Should be applicable to St52/St55 able to run Violentmonkey (a WE); likewise to the Chromium derivatives known to the retrocomputing communities here ; FWIW, I, too, use CookieKeeper to protect cookies in UXP-based browsers, while in the Chromium-based ones I use the excellent MILK extension...
  5. VistaLover
    Ditto for the rest of the UXP-based browsers (I tried it on St52/St55), 360EEv13.x and KafanMB, with Violentmonkey as the userscript manager ; it's because of its dependency on: which I haven't been able to make it persist on ALL of the aforementioned browsers ; I do move the slider to the left, but it doesn't stick ; reload the tab and the slider gets reset to the right ; that's the only slider that does this, AFAICT... Edit: Issue finally resolved ; read below ...
  6. VistaLover
    Thanks ; I had set preferred page locale to Greek in my browser, so GF loaded the "el" edition of the userscript page: My post above will be edited to a "locale-free" userscript URI, so that GF will load the default (en-US) or user-specified locale of that page (if it exists on GF, that is) ...
  7. VistaLover
    ... That's the exact popup I'm being served with Kafan MiniBrowser (Ch87-based) ... For anyone interested in getting back "traditional pagination" in the search results generated by the "modern" GS GUI, there's a userscript that attempts to emulate it (not fully, read the details in its description ) : https://greasyfork.org/scripts/468360-return-pagination-to-google
  8. VistaLover
    ... Not all Google Search results offer the "cached" version feature ; as for NM28 with "the" SSUAO, I did a test right now and can't confirm your finding ... The "modern" GS GUI loaded alright, I searched for "xenon fluoride": the "about this result" popup to the right (for the first result) has a footer with a "cached version" button, that leads to, er, a cached version of the result, with the proviso it hasn't expired by the time you asked for it (the specific example in the screenshot now returns a 404 ...): FWIW, in NM28 I've noticed that the popup has the word "beta" in its header, whereas in Kafan MiniBrowser (I'm writing this on ) the popup is quite different, supposedly it's the one you yourself get with Mypal68 ... ... As you said, the "legacy" format is much more lenient to older, under-resourced, H/W XP users are likely to be running the UXP browser(s) on ; one thing I still like about the old format is that it's kept the "pagination" feature in result pages (look for it at the bottom of the page, i.e. "Next" -> "< Page 2 >" -> "<< < Page 3 >" etc.), while the "modern" format has now permanently switched to "more results/infinite scrolling" ; BTW, while the true UXP-based browsers have no issue with that, Serpent 55 is BROKEN in this regard ; STR: in St55, apply the SSUAO that enables the "modern" GS GUI; search for a term that is likely to generate a lot of results; as you scroll the results page down and have almost reached its end, a rotating circle will briefly appear but no additional results will be displayed; thus, in St55, you are limited to the first 10 results the "modern" GUI will offer ; pinging @Mathwiz and @roytam1 ...
  9. VistaLover
    ... I just tested latest NM28 32-bit on two different household laptops; one has Vista SP2 x86 as the OS and a recent-ish wireless (non-bluetooth) Logitech mouse; the second one has Windows 7 SP1 x64 as the OS and an old USB (wired) Microsoft mouse; on both machines, middle-clicking and wheel-scrolling work as intended in NM28 - so I'd say it's something specific to your setup/configuration...
  10. VistaLover
    ... Yes, it is ; so does middle-clicking my mouse inside the page and moving its wheel up/down: But my point isn't limited to just being able to scroll ; if one doesn't thwart discourse's browser-detection scripts, one will just get the dumbed-down version of the discourse-based forum, with limited functionality - and a top banner: which needs further actions to be removed (cosmetic filtering, if you use a content blocker , or a userstyle), if not just ignored... Kindest regards !
  11. VistaLover
    ... As I have explained already, without blocking those "browser-detect" discourse scripts, you won't be able to get this working; what is the "less complex" type of adblock that you currently use (because I can't believe there exist people "here" browsing the web of 2023 without any type of adblock) ? FWIW, you can always use a new St52 profile with just uBO (or other script blocker), specifically for Discourse-based forums (in any case, you can at least try this to verify my solution really works ) ... PS: It is my experience that content blockers do not slow down browsers, at least not to a perceivable extent (unless, ofc, you load too many filter lists in them); blocking all those third-party resources, i.e. scripts (especially miners), ad video, ad images, etc., results in quicker page loads and reduced bandwidth usage, if anything - YMMV, ofc ... PS2: Are you familiar with the English adage "You can't have your cake and eat it, too" ? You come here and ask for solution to a problem, an offered, proven, one involves slightly modifying "your" workflow (i.e. employing a script blocker), with minimal or zero risks, yet you remain reluctant to apply the proposed solution - while I do indeed respect your choices, often times the key to success is simple compromises ...
  12. VistaLover
    @j7n: UXP-based browsers have all the necessary mechanics (I'd say 99.9% of them) to properly display ALL discourse-based forums; the real issue is discourse's stupid/overzealous browser-feature sniffing scripts, which are BLOCKING the UXP-based browsers because they can't detect support for certain features (no doubt present in recent Chromium/Firefox) which are not indispensable for these forums to function as expected... My own solution in St52 since months ago involves: 1. A SSUAO for discourse-based assets (not even sure this is still needed today): general.useragent.override.discourse-cdn.com;Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 2. Blocking those overzealous scripts in your content blocker of choice ; I simply use uBlock Origin "legacy" and in the "My Filters" tab I've added this filter: ! Discourse-based forums ||*/assets/browser-detect-$script,important After that, ALL discourse-based forums display correctly (and this includes vertical scrolling ), e.g. : https://forums.docker.com/c/docker-desktop-for-windows/48
  13. VistaLover
    ... Apparently, even gmail's bare minimum format lies on its deathbed: https://msfn.org/board/topic/183352-proxhttpsproxy-and-httpsproxy-in-windows-xp-for-future-use/?do=findComment&comment=1255546 ...
  14. VistaLover
    The (mediamarkt|saturn).de rendering issue has been already reported here in this thread in late July, by your compatriot @lh2500 : https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1249726 The discussion that followed dissected the problem and the cause was found to be no support for "CSS revert" in UXP ... These two German websites mostly work with the userscript kindly posted by @UCyborg (and linked to above by @nicolaasjan) ; if you want them to display exactly as they were meant, you'd have to use Kafan Minibrowser (Chromium 87-based) with "experimental-web-platform-features" turned on - this supposes you can at least use XP SP3 x86 ... If you don't want to use a userscript in St52/NM28 or can't run KafanMiniBrowser, the UXP "hacks" I posted already do still apply: The same route will render https://www.livefromiceland.is/ mostly operational... And @Mathwiz was quick to post as I was composing mine, so congrats to him!
  15. VistaLover
    Thanks to @AstroSkipper (& @mina7601, who came in second ) for his input on the "blank" applications NM28 preferences window; this led me to further investigation on my system... I discovered that several other portable browser installations on my system exhibit the same bug/issue, including FxESR 52.9.1, so this is probably a system-wide change that causes this... At first I thought something had gone awry in my system, e.g. a registry corruption or some Windows service having been broken/disabled or needing a stop/restart... Then, being more calm, I thought of what applications I installed globally in the recent past and turns out it was an update to Java RE 8 (version 8u391). JRE8 has long been deprecated for the Windows XP SP3 OS, with jre-8u152-windows-i586.exe being the last XP-compatible installer... On Vista SP2 x86, the last version that will install out-of-the-box is jre-8u361-windows-i586.exe; however, I did manage to install later versions 8u361 -> 8u371 -> 8u381 -> 8u391 via a "hack", which is OT for this thread ... JRE8 comes with an NPAPI plugin and its up-to-date version (Next Generation Java plugin 11.391.2 for Mozilla browsers) displays properly inside about:plugins (St52): as well as in "about:addons => plugins"; however, when the state of this NPAPI plugin is set to "Ask to Activate"/"Always Activate", the blank Applications tab issue manifests itself ; switch it to "Never Activate", restart the browser and then the Applications tab will populate with content! I'm short for time now, but I'll have to investigate if previous JRE8 NPAPI plugin versions cause the same problem; @roytam1, given the Error Console I posted above, do you have any remote idea why that issue is caused? FWIW, when the JRE8 plugin is active, test pages like https://javatester.org/version.html https://atcsim.nasa.gov/version/index.html work as intended (the JRE8 version is correctly detected) ...
  16. VistaLover
    ... I'm so frustrated to hear about this ... The issue I reported (empty "Applications" tab/window) happens on ALL of my roytam1 browsers here (St55/St52/NM28); all these are the latest 32-bit releases, OS is (as has always been the case ) Windows Vista SP2 x86; can other MSFN members try this, too? ... "Can get" ? It's always empty for me here Sure; below a screengrab and copied text from latest NM28 (32-bit): Timestamp: 17/11/2023 13:56:21 Error: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIMIMEService.getFromTypeAndExtension] Source File: chrome://browser/content/preferences/applications.js Line: 1064 ... Hope it's useful to you ...
  17. VistaLover
    @roytam1: Possibly related and it is indeed a serious regression: the "about:preferences#applications" internal browser tab ends up empty in latest versions of both St52/St55, thus the user can no longer customise the default browser actions related to the content-type of downloads ; below is a screengrab from a fresh St52 profile: Additionally, though NM28 doesn't have an "about:preferences#applications" internal browser tab, the corresponding "Preferences -> Applications" window exhibits the very same bug : So, this is probably a platform (rather than an application) bug, which has to be identified and mitigated... It's very early in the morning in my timezone, apologies but I can't present to you at this time a regression window ... Hoping for an easy fix (fingers crossed) ...
  18. VistaLover
    Hello ; do you think https://repo.palemoon.org/MoonchildProductions/UXP/commit/e4643f5bed2cdc600fc29900fe3b4d22e25763bc is the culprit, hence you did this: https://github.com/roytam1/basilisk55/commit/9bd1d38f77d2c01548f8802c369368e68ca08911 ? I'm no coder myself (everyone here knows that ) , but I had more time now to study Mathwiz's report, specifically: The issue is specific to the native downloader and the "open file" function - the file here being an "installer" binary which needs to be executed by the browser; the 7-zip installer comes in two varieties, EXE & MSI, so it would be helpful to clarify which - in any case, my own eyes fell on this: https://repo.palemoon.org/MoonchildProductions/UXP/commit/98c3aa57431c4b158c750dfabfd0ab90708ebf16 which you ported both to UXP and Bk55 trees: https://github.com/roytam1/UXP/commit/74a4260ecd6b6e6f40d48d4b181e34127487532b https://github.com/roytam1/basilisk55/commit/a406edc82008cf5b4fba914b73929a9933065319 Both of these first landed on the 2023/10/28 respective releases ... Speaking purely for myself , I think it's a bad practice to let the browser run executables; if it's installer packages, I strongly prefer to first "properly" download to disk and then archive them; many a times I've been bitten by a new application "update" that broke things for me and had to restore the previous version via its archived setup (often times no longer retrievable from the vendor); as for the actual installation step, I tend to exit all not-needed apps (including browsers) and then manually launch the setup - perhaps I interpret the "law" very "strictly" ...
  19. VistaLover
    ... You're welcome ; à propos, you may want to correct that double negative there , else one may assume you do use Vista (joking, ofc) :
  20. VistaLover
    ... This is not a correct assumption , and I think I have mentioned this issue in passing in the past, possibly in another thread (that I'm too lazy now to dig up ); the implementation by cmalex (ProxyMII_v230813) employs a specially crafted/patched edition of CPython 3.7.11 (based on the initial 3.7.1-XP implementation by Dibya), which runs specifically only under WinXP SP3 x86; when the python37.exe binary is launched under Vista SP2 x86, it throws function errors: The DLLs enclosed inside the red rectangles are foreign to Vista and are, in fact, loans from OneCore API, Wine and/or ReactOS projects, while several DLLs/EXEs inside the "python" directory have been HexEdited to point to these DLLs, which, in essence, port some NT 6.0+ kernel functions to XP SP3 (see some analysis here) ... OTOH, default CPython 3.7 x86 (as distributed by the PSF) can run natively under Vista SP2 (but NOT under XP SP3), being, sadly, the last CPython version that works there; default CPython 3.8 requires Win7+, default CPython 3.9 requires Win8.1+, etc. ... Hope it's clearer now (... and since this is an "XP audience" thread , I didn't want to share additional "Vista-details" here, but since you brought it up, I indulged ) ... Happy Thursday evening to you!
  21. VistaLover
    As a FYI , even when using very recent versions of ProxHTTPSProxy, several fields in the https://browserleaks.com/tls detection page apparently don't work with the IEx severely outdated Javascript engine ; I have developed a Vista SP2 x86 targeting edition of ProxyMII (based on the original work by cmalex ), which uses: ProxHTTPSProxyMII-v1.5 (python script) CPython-3.7.17 x86 (EoS for py3.7) cffi-1.15.1 (EoS for py3.7) colorama-0.4.6 cryptography-41.0.5 pyOpenSSL-23.3.0 PySocks-1.7.1 urllib3-1.26.18 (script incompatible with urllib3 >=2.0.0a1) and when IE9 is configured to use it, the sections Protocol Support, Mixed Content Test and TLS Fingerprint remain empty: Best regards
  22. VistaLover
    Greetings ; IMHO, it'd have been a service to this community if you had actually named that "streaming service" for which Mypal68 doesn't work, because you would've saved some other MSFN members the "hassle" you yourself went into ... According to my own investigations, the more prevalent audio streaming services (Spotify, Apple Music, Tidal, Amazon Music) use in-browser DRM (largely Google's WidevineCDM), with the notable exceptions of Youtube Music and deezer (those two use different methods for protecting their audio streams ) ; I'm not very familiar with the codebase of Mypal68, but AFAIAA it doesn't support DRM; even if it did inherit the DRM support extant inside Mozilla Firefox 68, its initial fork point, the Widevine version supported by Fx68 has been long deprecated/blacklisted by Google and their WV licence servers - besides, Google make sure their blackboxed Widevine DLL only runs on Win7 SP1+; and even Win7 is going to be deprecated by Widevine, once Fx115esr reaches its EoS ... As for AstroSkipper , I'm absolutely confident he double- and triple-checked those links at the time his post went live, because that's how much meticulous he is on such matters - it would be unrealistic to expect of him to (occasionally) check the validity of the links post-submission and, indeed, the fact they were removed by Mypal68's author soon after was quite unexpected, TBH ...
  23. VistaLover
    You're welcome ... How so? Aren't you subscribed to this thread? That was my gut feeling, thanks for the confirmation ... The first, older, pref "security.fileuri.strict_origin_policy" was inherited by UXP from Mozilla ESR 52; the second one you cited, "security.fileuri.unique_origin" is a newer one, implemented by MCP in 2019: https://repo.palemoon.org/MoonchildProductions/UXP/commit/33b6f178d16f94df7de98d1316f563f14a2bedd5 with a clarifying comment written in: https://repo.palemoon.org/MoonchildProductions/UXP/commit/408ca49a029efa54d18234288c04944d2905fecb The original PR#1196 that implemented this pref has, apparently, been lost now, amidst their migration from GitHub to Gitea ... It is my conviction that MCP tried to replicate Bugzilla #1500453->#1558299 of that same period, although Mozilla chose a different name ("privacy.file_unique_origin") for the pref: https://hg.mozilla.org/mozilla-central/rev/2ad059cc9e78 That Bugzilla entry aimed to patch CVE-2019-11730 , but the default pref value there was "privacy.file.unique_origin;false", whereas in UXP it's "security.fileuri.unique_origin;true"; I'm not an expert on security, nor a coder, so can't advise you which of the two UXP "security.fileuri.*" prefs to toggle for your use case; from the Pale Moon v28.6.1 Release Notes: so I tend to think toggling only that newer, second, one might be preferable; toggling any of the two (permanently) lowers your browser security; a Mozilla expert advises to create a separate browser profile exclusively for such use cases ; in conclusion, Mozilla have removed "privacy.file.unique_origin" in Fx95+ and "security.fileuri.strict_origin_policy" is also to be axed (if not already); another case of them "foolproofing" their browser, in their effort to save their users from self-harm ...
  24. VistaLover
    @roytam1 : This week, upstream have merged some additional "aspects" of UXP#2346 ; since we've kept EME in our tree, am I right to assume those upstream commits should be exempted from merging? FWIW, some few sites do still use ClearKey (soft) encryption, also part of EME; some other sites delivering both Clear and DRM'd media content would not load at all if they sniff out the browser doesn't support EME/DRM; so, even if used solely as an indication of "sites-requiring-Widevine", I still feel keeping the (mostly broken) DRM implementation in Serpent 52 is a "good" thing... Also, UXP#2281 is being pushed; will that impact buildability/NT<6.1 compatibility for "you"? Thanks for your stupendous efforts ...
  25. VistaLover
    Actually, something relevant was discussed a few pages back: It loads without "an actual web server", if file "Lights.html" is drag-n-dropped on a Serpent 52 New Tab, provided you temporarily disable (from true to false) "security.fileuri.strict_origin_policy" pref: I don't have HTTrack installed here, so can't test now on your behalf ...
×
×
  • Create New...