Jump to content

VistaLover

Member
  • Posts

    2,100
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... 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 ...
  2. 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.
  3. 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 ...
  4. 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 ...
  5. 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>
  6. ... 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 ) ...
  7. ... 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 ...
  8. Fixed (initially, only "link text" had been edited, while the URL itself was not, sadly - old age is a b***h ) ...
  9. 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...
  10. 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 ...
  11. 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) ...
  12. ... 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
  13. ... 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 ...
  14. ... 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...
  15. ... 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 !
  16. ... 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 ...
  17. @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
  18. ... 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 ...
  19. 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!
  20. 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) ...
  21. ... 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 ...
  22. @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) ...
  23. 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" ...
  24. ... You're welcome ; à propos, you may want to correct that double negative there , else one may assume you do use Vista (joking, ofc) :
  25. ... 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!
×
×
  • Create New...