Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,307

  • Joined

  • Last visited

  • Days Won

    97

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    ... Well then, here you go : https://www.intel.com/content/www/us/en/support/articles/000005602/wireless/legacy-intel-wireless-products.html A SSUAO for "intel.com" might be needed - YMMV ... OT: "Intel® PRO/Wireless 3945ABG Network Connection" is the one my 2008 Vista x86 (then OEM) laptop came with...
  2. VistaLover
    Actually, the default (global) UA string of St52 does NOT advertise it as Fx52, but as Fx102 (the previous ESR branch/channel, current being 115); this UA string does contain an end "Basilisk/52.9.0" slice but, judging from past experience using the browser , UA-sniffers either silently ignore it or outright block it altogether (not the case with "www.intel.de"; the block stays put if I remove the Bk slice) ...
  3. VistaLover
    ... Yes, it's an arbitrary, unjustifiable, artificial block imposed by © Intel, based solely on UA-sniffing ; I'm still on St52 v52.9.0 (2023-11-10) (32-bit), i.e. only one month old, and I, too, get the "Access Denied" (Web Console reports: [HTTP/2.0 403 Forbidden]) block at the door ; guess what? Create a SSUAO with just the string "Chrome" in it and... you're in: general.useragent.override.intel.de;Chrome ... This has gotten ridiculous, if you ask me ...
  4. VistaLover
    Festive greetings Dave ; I can reproduce the initial loading and subsequent (tab) crash of the referenced TrendMicro link with my 360EEv13 (Ch86-based) copy (NOT a build made by NHTPG, BTW ) ; the error generated is identical to the screengrab posted by Skorpios ; however, I have more to report, see below: Somehow , I'm not able to reproduce here; my Kafan MiniBrowser (Ch87-based) "dirty" profile is able to load in a "rock-steady" fashion Dave's link, both in a "normal": as well as in a private window (with uBO enabled): Proof of browser used (Greek locale): uBO-v1.54.1b9+Privacy Badger v2023.12.1 installed; plus, several "experimental" flags enabled (inside chrome://flags ) ; FWIW, that same link loads OK in the UXP-based browsers (NM28/St52) and even in FxESR 52.9.x, so XP users aren't left without options beyond 360EE ... Cheers !
  5. VistaLover
    1) The last MV2 release of "Who Deleted Me" Chromium extension is v2.0.16, from 2020/04/09: https://www.crx4chrome.com/crx/344799/ 2) The last MV2 release of "Fluff Busting Purity" Chromium extension is v35.0.0.0, from 2022/10/08: https://www.crx4chrome.com/crx/297286/ In both cases, click the links labelled: "Download Crx File from Crx4Chrome" and save the .crx files to disk; open the chrome://extensions (or chrome://myextensions) tab in 360EE, enable developer mode and then drag-n-drop there one of the .crx files; a prompt should appear, asking you whether you want to proceed with the extension installation, etc. - do the same with the second of the downloaded .crx files... DISCLAIMER: While these older extension versions are compatible with/will install in Chrome < 88.0, their actual functionality might be impaired and/or flawed (as subsequent, MV3, versions were released after them, "presumably" to fix bugs/add more features) ... Regards ...
  6. VistaLover
    Top of the morning to you ; I'll be traveling soon 400km away from home, won't be back until Monday ; I had only a cursory look at your posted details (thanks!), it is now evident your CPU lacks the SSE2 instruction set by the mere fact you've installed the "-ia32" & "-sse" variants of the UXP browsers (I presume the default "-xpmod" varieties can't run on your setup ...). Success reports thus far had to do with the "normal" SSE2+-capable NM28/St52 builds, on at least WinXP SP3 32-bit systems; your system is indeed quite old, TBH (and I have 0 experience with a Win2k+KEx system) ... WebGL errors aside, I think the crux of your predicament is: Given that you have already tried fresh profiles, the about:config pref below should be at its default value of true: javascript.options.wasm;true It is my belief/educated guess that the WASM code inside the Anti-Bot-Verification test emits SSE2 instructions, that your very old CPU (P3) is incapable of executing ; am afraid nothing can be done to mitigate this; I must go now, forum experts like @roytam1 or even @UCyborg are free to chime in with additional info/details, if known to them ... Kind regards ...
  7. VistaLover
    ... Of course you're correct , I mis-pasted the version details of the latest NM28 release, its package filename being palemoon-28.10.7a1.win32-git-20231202-d849524bd-uxp-aa8671dc1b-xpmod.7z In fact, "(2023-11-17)" was the version prior to me updating to the "true latest" one, (2023-11-30), for the sake of testing; my daily UXP-based "driver" is St52, I update my NM28 copy less frequently; actual test mentioned in my previous post was performed on the (2023-11-30) build ; I don't expect noteworthy differences in the test results across recent NM28 builds - as the relevant discussion has revealed already, the deciding factor here seems to be H/W (how powerful your CPU is) ... Am not surprised, the underlying platform being common ; and you do possess a powerful recent machine, so, just like UCyborg reported, you achieved < 10s in test completion time... However, we've not heard back from @anton12 yet ...
  8. VistaLover
    Hi ; are you just referring to the "zipped" distributions: https://github.com/win32ss/supermium/releases/download/v119/supermium_119_32.zip https://github.com/win32ss/supermium/releases/download/v119/supermium_119_64.zip or is it you are employing some kind of portable launcher with these ? AFAIAA, even the "zipped" version would write its profile (aka "User Data") in %LOCALAPPDATA%, is this not the case? FTR, I'm on Vista SP2 32-bit and would like to test the freshly implemented Vista x86 support, but am not really comfortable with a "proper" installation ... Cheers.
  9. VistaLover
    Returning, hopefully, on topic , I tried your "problem" in a quasi-fresh profile in latest NM28 [28.10.7a1 (32-bit) (2023-11-30)]; only extension installed is uBO-legacy v1.16.4.31b2 ; I first disabled it fully and then acquired a German IP address via VPN; when I accessed https://www.huk24.de/zugang/registrierung/anmeldedaten an overlay appeared that asked me to consent to their cookie-setting in my browser (I didn't read it all, I just pressed the "Zustimmen" blue button), then the "Registrierung" page loaded; as soon as I accessed with my cursor the "E-Mail-Adresse" input field, the "Anti-Roboter-Verifizierung" process auto-kicked-in (alternatively, I guess, you can skip the two input fields and go straight to the "Hier klicken" button); in NM28 it took ca. 85s for the process to complete successfully and yield the "Ich bin ein Mensch" result... All I can tell you is that the process is CPU/RAM-intensive, for the duration the bar moves to the right (towards completion), my CPU was constantly at 100% (2009-era Intel Core2 Duo); I conducted several additional tests and by exiting all unneeded running applications and having only this one tab open in NM28, I achieved a completion time of just 39s ... What you need to concentrate on here is the fact the anti-robot-verification did complete successfully! How old exactly is your CPU? Does it support the SSE2 instruction set? How much RAM do you have available for the browser? If the process does require an SSE2 CPU, then you'd be out of luck if your CPU can't cope ... In your initial post you said i.e. you did not say "it started but takes an awful lot to finish" - as AstroSkipper wrote, even with a very old CPU, the process would ultimately finish (though I do agree 5-6min is way too much ) ; my advice to you is to try again with a fresh NM28 profile (I assume you have updated to the latest NM28 release ) - give it the 5min reported here and see how it goes... I, too, ended up on that "Registration is currently not possible" webpage during my testing; clearing browser cookies and trying anew several times did finally yield the proper "Registration" page (the one inside AstroSkipper's post) - however, for the sake of just this test, you can click on the "Zur Anmeldung" label and be served another page which also contains the ""Anti-Roboter-Verifizierung" test/button ...
  10. VistaLover
    Both of you are GitHub account owners , there's a comment section at the bottom of the userscript's homepage (it's being hosted on GitHub Gist), so, perhaps, if the author was made aware, he could investigate and, hopefully, accommodate it for Google's Advanced Search ... Just saying ...
  11. VistaLover
    Many thanks for this ; in the end, I used your hint and integrated there (inside the userscript) the uBO cosmetic filter I posted earlier ; it saves slightly more vertical pixels than your code alone; since I'm on a small laptop screen, any vertical space saved counts! #restored-pagination .YyVfkd { color: ${isDarkMode ? "#bdc1c6" : "#202124"}; font-weight: normal; } + + #cc, .w7LJsc.WZH4jc { + display: none !important; + } </style>
  12. 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 ) ...
  13. 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 ...
  14. VistaLover
    Fixed (initially, only "link text" had been edited, while the URL itself was not, sadly - old age is a b***h ) ...
  15. 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...
  16. 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 ...
  17. 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) ...
  18. 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
  19. 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 ...
  20. 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...
  21. 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 !
  22. 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 ...
  23. 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
  24. 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 ...
  25. 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!
×
×
  • Create New...