Jump to content

VistaLover

Member
  • Posts

    2,307
  • Joined

  • Last visited

  • Days Won

    98
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... Well, just for the heck of it , this afternoon I decided to revisit, more than a year ago since the last time, e10s on my St52 copy, putting to the test the most up-to-date release, i.e. v52.9.0 (2023-03-30) (32-bit) ... First, I made a full backup of my current, single-process, St52 profile; then, in about:config, I enabled below (hidden) pref: browser.tabs.remote.force-enable;true and toggled/modified prefs below: browser.tabs.remote.autostart;true extensions.e10sBlocksEnabling;false dom.ipc.processCount;2 After a proper browser restart, multiprocess was ON, with a maximum of 3 "basilisk.exe" processes inside Task Manager ; I used it that way for more than an hour, no dramatic changes in my configuration here (3GB of total RAM, 2 core CPU, 2007-era...), the browser was rock-steady overall ; but then I stumbled on a show stopper ; once inside an online post editor, like the one here on MSFN (I'm typing this on) or GitHub's issue/comment editor, the DEL and BACKSPACE keyboard buttons no longer work as expected there ... Say I type the word "test", and the caret (aka text cursor) is after the last "t": test| If I press BACKSPACE once, nothing happens; I would expect "t" to be deleted instead... Worse, if I press (inadvertently) the BACKSPACE button once more, the whole tab changes to the URL previously visited (in that tab), possibly resulting in typed content loss in the editor ... If I use the left arrow key (<-) to place the caret after "s": tes|t and then press the DEL button, again, nothing happens; I would expect "t" to be deleted instead, too... Both these annoyances can be worked-around via selecting the characters to delete with the mouse and pressing DEL button, but one has to be careful with the BACKSPACE button, plus one has to modify one's workflow (of years) to accommodate these e10s "bugs"... Are these shortcomings known to those that prefer multiprocess? Can they be mitigated? I've gone back to my single-process profile now, where both buttons in question behave as expected, still curious though ...
  2. ... Apart from dynamic module import that you referenced already, in my casual browsing I now find the most "mean" UXP villain to be nullish coalescing assignment ("??=") operator , for which UXP issue #2097 has been opened ... This is what causes discourse-based forums to break under UXP, and a "filter" for the "Modify HTTP Response" extension (by JustOff) has been kindly published by Pale Moon Forums member Kris_88 there ; however, you need to know both Javascript and RegExp to manually formulate such a filter, so this solution isn't for all ... I have a vested interest in opening https://venomissimo.notion.site/venomissimo/FFmpeg-86-3b484982448b485eaed6b687b2f67047 https://venomissimo.notion.site/4473a6dcc8494218be42fc504f67d5e0?v=7acc381ce8ef4a16bb95f14db710588e https://www.notion.so/34dc4ddf501a4b98b46ea9fb4f3470af?v=878345c5d88f4d21a6520db752b5c29f in St52, but all these URLs end up in blank tabs currently, because "*.notion.(site|so)" use the despicable "??=" operator since mid-January ... Can a kind heart offer some solution/filter for "Modify HTTP Response", please?
  3. ... Oh that ... I did pass by this post in the thread you linked originally, but must have not put 1+1 together at the time: In any case, I lost interest in whatever additional Artem had to say in that post, once the dreaded "WinXP is dead" was brought up ; which might be a true thing according to Microsoft, but, at the same time, gives out a lot about the app author's intentions towards EoS'ed WinOSes ... At the end of the day, hooray for WINE (on Linux) ! Of course, and no need to get defensive (if you did) ; I just pointed out that "I" can't read Russian and also included the "whatever" I used to translate it... All's fine ! Best wishes.
  4. You might want to read this thread on AIMP Forum. ... Thanks, I can't read Russian , so I used: https://www-aimp-ru.translate.goog/forum/index.php?topic=69488&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=el&_x_tr_pto=wapp Having read the translation, I did not find answers as to why Vista SP2 support has been reinstated (but I'm not complaining, obviously ); the thread basically talks about AIMP-v5.x's inability to integrate with the OS under WinXP (i.e., establish 1) media file associations and 2) access to Windows Explorer's Context Menu ); and I was also reminded of XP's excellent file association editor, one thing I strongly lamented when I moved to Vista (on Vista+, it's quite a PITA to remove/delete already established file associations; I had to resort to a third party app ...).
  5. ... I acknowledge this thread has a broader focus on "Software Running on XP", so it's still fine by me , however, since the last two posts seem to pertain specifically to Anti-Virus software (and in particular to ClamAV), perhaps further discussion on these should be better continued in "our" specific thread below: https://msfn.org/board/topic/177099-which-antiviruses-are-known-for-a-fact-to-be-working-on-xp-sp3-as-of-2019/ ... where I believe ClamAV was also recently mentioned ... Just my 2c, ofc ...
  6. The download page still says Windows Vista - Windows 11 for current version 5.11.2427. Is that an error? Missing APIs? If you navigate to AIMP's Old versions page for Windows, you'll hopefully see that Vista SP2 support was withdrawn, starting with v5.01.2358 (Release date: 28.12.2021), so @WinClient5270 was right to pick out v5.00.2344 (Release date: 09.11.2021) as the Vista EoS one ; however, in a move quite rare these days, Vista SP2 support was re-instated, starting with v5.10.2418 (Release date: 21.12.2022) ...
  7. ... Well, e10s is a numeronym; "10" denotes the number of letters omitted between the first one, "e", and the last one, "s"; see also this article; for similar numeronyms i18n and L10n, Wiki has a separate entry here ...
  8. ... Yes, I've been following this in the upstream repos ; it's part of their struggle to split large DLL files (e.g. xul.dll and icudt63l.dat) inside the platform/application core into smaller ones... ... The numbers below refer to comparisons between last Saturday's and today's St52/St55 (32-bit) released builds: Serpent 52, buildID=20230324153850: xul.dll sized 44.8 MiB icudt63l.dat sized 11.4 MiB Serpent 52, buildID=20230330030628 (xul.dll split into:) xul.dll (32.5 MiB) gkmedias.dll (6.48 MiB) mozjs.dll (5.57 MiB) (icudt63l.dat exchanged for:) icu63.dll (13.9 MiB) If you do the math, we actually end up with an increase in total filesizes of +2.50 MiB (!) Serpent 55, buildID=20230324154343 xul.dll sized 64.6 MiB Serpent 55, buildID=20230330025402 (xul.dll split into:) xul.dll (40.9 MiB) gkmedias.dll (6.46 MiB) mozjs.dll (5.60 MiB) icu63.dll (13.9 MiB) Again, if you do the math, we actually end up with an increase in total filesizes of +2.26 MiB... I guess Lavoisier's (chemistry) law of total mass conservation doesn't apply here ...
  9. ... That MB Forum poster never mentioned WinXP himself, TBH , but he did write: in his original post; "legacy systems with Never Expiring License" do comprise WinXP, though, hence the rise of interest here ... In one of his subsequent posts, "he" made it clear "he" was running 3.5.1. on Vista and Win7; it's relatively easy to tell from the screenshot in his OP that it's been taken from one of his Win7 systems... ; I wouldn't do that myself; for all they know, the admins of that support forum live under the impression "That version (i.e. 3.5.1) no longer has updates."; tipping them that their impression is not true currently will only result in them tipping, in turn, those involved, who, no doubt, would turn a (perhaps forgotten?) switch to OFF even sooner ... BTW, I see no reason now for further posts about MBAM Legacy updating its definitions/pattern signatures on either XP or Vista ; ; what would be "post-worthy", no doubt, is the time it stops doing so permanently (on either OS) ...
  10. ... Like I said: "We" have built resilient communities here at MSFN, consisting of people on, so called, "legacy" Windows OSes their vendor no longer supports (or, even tries to sabotage nowadays ), but outside of such communities hostility, FUD, fake facts, etc. is the rule ... That's why I find it useless now in 2023 to "argue" with app authors about extending/continuing their support on older OSes; I did do it in the first years after Vista's EoS (2017); even at that time, most of them (especially on GitHub) were under a firm conviction my Vista laptop had already become part of the botnet... And, as you said, there's no way you could talk them out of such convictions... Alas, we have to help each other now ...
  11. @lmacri: At the time of this writing, MBL 3.5.1.2522 can still successfully update its malware definitions on-line, both when installed on WinXP SP3 ("Premium" version, see here, here and here), and Vista SP2 ("Free" version, see here) ...
  12. ... "They" seem to have moved your post to its own standalone thread now: https://forums.malwarebytes.com/topic/296406-windows-xp-does-not-have-lifetime-support/ You should probably edit that first post, to include a link to the originating thread, so it doesn't look out of place on its own ; truth be told, I don't think you can achieve much there, except for venting a bit ...
  13. ... Many thanks for testing this ; so, it proves it can still successfully update its definitions, the same way as on WinXP ... But this finding of yours contradicts with the linked discussion in the MB Support Forum ; not that sterling of a "support", is it? I bet no-one there actually tried that "legacy" 3.5.1 version on either XP/Vista - yet, they were quick to disseminate what they were probably trained to say: "Every WinOS below Win10 is a security menace" (and what I found particularly distasteful was their suggestion below: ; I'm not a native English speaker, but, surely, "by crook" doesn't imply pirated versions, does it? ) ...
  14. XP (and Vista) users should really keep an eye on that thread ; things look grim ... The opening post there displays a picture of what Dave described in a previous post here: However, this time the MB staff aren't interested in "resolving it"; according to the reporter (and confirmed by a staff member), Malwarebytes Premium Legacy 3.5.1.2522 can no longer receive def updates under Vista/Win7 - thanks to user feedback in this thread, we do know XP installations still receive these ; but all the MB staff can, apparently, do is endlessly recite ad nauseam the "inherent perils of running Microsoft unsupported Windows versions like XP/Vista ; as per @lmacri's post 3hr ago, MB staff have started wiping out Forum references to "Malwarebytes support for legacy Windows XP and Vista Operating Systems"; what comes next ? OT: @mina7601; Since you seem to have a Vista SP2 VM installed, could you be so kind as to try MB Legacy 3.5.1.2522 there and check whether its defs can be updated? Thanks in advance ...
  15. ... Yes, I've been following this in the upstream repos ; it's part of their struggle to split large DLL files (e.g. xul.dll and icudt63l.dat) inside the platform/application core into smaller ones... A propos, I want to ask you a relevant question: Issue #61 - Reinstate buildability with shared gkmedias dll Issue #61 - Place Skia in libxul Unlike the platform's default setting (and the obvious selection on WinXP), under Vista SP2 32-bit I prefer content to be rendered by skia, not cairo, thus I have the below user-set pref: gfx.content.azure.backends;direct2d1.1,skia,cairo (FWIW, "direct2d1.1" requires Win7+); does this new "moving around" by upstream still allow my current setting, or will it break once skia has been moved out of xul.dll? Upstream say they're only using skia "for canvas anyway", so they're probably not checking scenarios where skia is used for content, too... Any additional insight will be highly appreciated ...
  16. Hi Nico ; I run St52 as my daily driver basically, "File upload" via the VT modern GUI works fine here in my "dirty" profile: I then launched latest NM28 in an almost fresh profile (no extensions, only slight GUI customisation ), and "File upload" via the VT modern GUI also works as expected there: So I believe it's something in your current NM28 configuration that prevents the VT File upload from functioning as expected ... Kindest regards
  17. ... Noted and original post of mine edited accordingly... It was just the level of your coding expertise that probably made me think you're coding for a living ... This thread (and the forums in general) needs more "coding-apt" members, beyond the "average mass" of just "browser users", of which mass I, too, constitute a part ... Hence, your erudite contributions are always welcome here ...
  18. ... Dear Astroskipper , my true goal was not to prove you were wrong, especially on such a trivial matter, what good would that do in the broader scheme of things? It was more a proof to myself actually , because (I thought) I had a very vivid recollection of your post in question... As I wrote recently, "I may be wrong as much as anybody else", and I have been wrong in the past, and, no doubt, I'll be wrong again in the future - it's human nature, of course, to be wrong sometimes ("errare humanum est"), more so as age progresses , and it's something I deal with constantly in real life; errors/misjudgments committed either by me or my immediate circle (of relatives/friends, etc.); as long as someone else, preferably impartial, exists to point us towards the "right", we should learn from our mistakes, philosophise a bit and move on ... But I'm going off-topic... Cheers
  19. No worries here, too ; but I can assure you it did not contain that screenshot "when it went live the first time"; as I've posted in the past in this thread, I'm subscribed to this thread and have the MSFN forum software configured in such a way so as to send me e-mail notifications whenever new posts are being published in this thread - the software sends an initial e-mail ONLY when a post goes first "live", later edits by a post's author do not trigger further e-mail notifications ; thus, I have to visit the thread through my browser to become aware of additional in-same-post content... FTR, below is a screenshot of your post the very first time it went live, as it appeared inside my e-mail client: That e-mail was received at 202303280017GMT; and I'm extremely lucky, dare I say , that Bing's cache has saved your initial post just two minutes after it went live, https://cc.bingj.com/cache.aspx?q=https%3a%2f%2fmsfn.org%2fboard%2ftopic%2f184051-my-browser-builds-part-4%2fpage%2f74&d=3263078889977&mkt=en-WW&setlang=en-US&w=ur8pG3tLReOOvMj2Ov9a9kvf_SOCrEvI and it indeed first appeared without an image attachment: "Case closed" for me ... As ever, best wishes!
  20. ... Well, I commented very shortly after your own post went "live" , then put the laptop to "Sleep" and went myself to bed ; when I first read your post and composed my own comment/reply to it, your post hadn't been edited yet, no screenshot had been attached at that time ...
  21. ... Did you remember to also toggle "dom.getRootNode.enabled" to "true"? These prefs are actually a "wedded couple", so to speak - if one is set to true, the other has to be set to true, too - and vice versa ... ... FWIW, both I and @UCyborg mentioned, here in this thread, it's not the case ; my own advice came after the recommendation issued by upstream not to simultaneously enable both (i.e. palefill+nativeWC): UCyborg (a "hobbyist" coder, BTW by profession ) later posted additional input: ... He specifically cites GitHub above, but palefill does also include code pertaining to VirusTotal, e.g.: https://github.com/martok/palefill/commit/657b2b1 https://github.com/martok/palefill/commit/6001e31 Kind regards
  22. Thanks to extensive coding work carried out by upstream developer FranklinDM, "Web Components Slots" are now supported in UXP natively ; last Saturday's UXP-builds by Roy come with that support backported ; as such, now the "modern GUI" version of VirusTotal can be successfully rendered and used in NM28/St52 without disabling the native WC implementation and without excessive CPU consumption (YMMV, here it was OK ) : https://www.virustotal.com/gui/home/upload
  23. I have been running last Saturday's St52 (32-bit) build (BuildID=20230324153850) for a whole 3 days now and can confirm that the "xul.dll" crashes I first spoke of here no longer happen ; so it was indeed Bugzilla #1440809 (landing first on Fx60) that had to be applied to "our" UXP tree to get those crashes fixed... Many thanks (FWIW, don't "upstream" also need this fix, or is it specifically tied to WebExtensions ? ). Speaking of "xul.dll" crashes, another type of them (see #2176) was addressed by upstream in PR #2178, that fix has already been transferred to "our' tree and will be included in the next UXP-based releases (Sat, Apr 1st 2023) .
  24. If one site hosts multiple domains, the certificate will typically include a Subject Alternative Name for each domain hosted at that site. As long as the domain you're accessing is one of the certificate's SANs, the browser shouldn't give a warning. But if the domain isn't listed as a SAN, a warning should appear. @luweitest : Mathwiz is right ; below is a capture of the "SAN field" of the server certificate on "forums.internetfreedom.org":
  25. Sounds to me like another genius move by Micro$oft: make sure even fewer folks use Bing! ... It's actually their new "offspring", OpenAI-based, supposed to be "more powerful" than ChatGPT: https://blogs.microsoft.com/blog/2023/02/07/reinventing-search-with-a-new-ai-powered-microsoft-bing-and-edge-your-copilot-for-the-web/ ... And Roy's choice is: https://github.com/roytam1/basilisk55/commit/babf7e8e5c79cab7ea504f16fab609253e047ce8 => https://msfn.org/board/forum/201-browsers-working-on-older-nt-family-oses/ Quite right ; at that time, Fx did support both XUL+WE extensions, and while WE are inherently e10s-compatible, not all XUL ones had been rewritten to support it; their authors became less "enthused" (to put it mildly ) when Mozilla announced XUL support would be axed in "Quantum" (Fx57+) ... Being on Vista SP2 x86 myself, e10s is enabled in my Fx-52.9.1 (32-bit) "nostalgia/test" copy, however I don't use nor recommend myself e10s on St52/St55; the platforms (UXP Take 2 / UXP Take 1 = moebius) were significantly modified by upstream compared to their respective Mozilla forkpoints (52.6.0/53.0a1), not taking at all the underlying (but dormant) multiprocess support code into account; as posted already by others, that support was later excised completely from the "official" UXP code; "we" have kept these e10s vestiges inside "our" UXP tree, but no-one upstream (of course) or downstream (Roy) checks how well/bad these vestiges behave now, when enabled, with current UXP platform snapshots; St52 has also kept vestigial support for Fx52-level "Container Tabs" (off by default) and WEs, but, like e10s, those platform features, no longer present in official Basilisk, aren't being maintained at all by Roy... All these extra features are in a "Use at your own risk" status; for e10s specifically, you should definitely back up your profile (to have a single process one to revert to if/when things turn sour ) before enabling it, and making frequent profile backups once on e10s isn't a bad idea either ... To give credit to people requesting e10s in their browsers, it's mostly due to the way website design has grown to become over the last years : the major league of browsers, Chromium-based ones and Firefox, have, since long ago,, native multiprocess support, and it's those browsers that are being targeted by web devs and web frameworks; this has resulted in the current web abomination where every independent browser tab runs a "web app", downloading tens of MiBs of JS code that has to be rendered locally by the browser's engine; this is especially true on "popular" social media portals (facebook, instagram, twitter, etc.) and "chat" apps (e.g. Discord), exacerbated by the concurrent use of a multitude of rich media (HD images/GIFs, HD video, audio, WebRTC video+audio, etc) ... While single process engines were "fine" a decade or more ago, they're more likely to "run out of O2 and choke to death" when asked to deal with the modern web, especially on our older H/W and OSes - but do also note that e10s works best on more recent H/W, where ample RAM and CPU is being made available to the multiprocess-enabled browser core ...
×
×
  • Create New...