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. They fixed it in their code tree before you posted about it here. ... For those members that have not been following this, the reference made is to the "GitHub-vanishing-timestamps-bug" I first reported here, with further instances of it reported here and here ... Affected Serpent 52 versions in my case were 32-bit builds with BuildID=20230302072906 and BuildID=20230310123711; the second one was less tested, because of it being crash-prone ... The bug manifested itself when (martok's) palefill extension was disabled and native WC+SR support left at its default "enabled" state; throwing palefill into the mix resulted in adverse effects , sadly, as far as that bug was concerned... I could easily and reliably reproduce the bug, both in "dirty" and "fresh" St52/NM28 profiles; rather unfortunately, others here could not (not their fault, obviously ), so I got the sense my bug report was being doubted/disputed ... Many thanks @UCyborg for posting about it in the official Pale Moon forums; in your screengrab: one can witness the bug present in latest PM 32.1.0b3 (64-bit) ... For "closure", the bug was fixed (many thanks conveyed to the upstream dev, @FranklinDM) via merging PR #2152 in MoonchildProductions/UXP/commit/4c4bc3c, which landed in "our" tree as roytam1/UXP/commit/18e6934 ... I have been running the latest St52 (32-bit) build (ID=20230315155040) for close to 7hr and can verify that (annoying) bug as fixed ! Additional thanks for your words of wisdom below, on why running official (martok's) palefill (enabled) alongside the native WC implementation should not be encouraged:
  2. You can always go to about:config and toggle "dom.enable_performance_observer" to "true"; the reason it's not true by default/already is Moonchild's objection to it ... EDIT: My post is probably redundant now , because of this ; but I hadn't got to it by the time I hit the "Submit" button (always lessons to be learnt) ...
  3. "Segrite" is the brand name of the corporation that targets the Enterprise market ; Home Users are being targeted through Quick Heal: https://www.quickheal.co.in/home-users All these are paid-for products, because dedicated coders do need to make a living ... Some free tools are also offered: https://www.quickheal.co.in/free-tools Best regards
  4. ... And I never implied you did anything wrong (thought to self: Why "web people" of this "era" are so "touchy" ? ) - I was directly replying to @Humming Owl, but I neglected (/deemed it superfluous) to tag him - well, now I have ...
  5. ... I used it there in the sense of "Opening/Original/First Post"; see e.g.: https://www.businessinsider.com/guides/tech/op-meaning
  6. ... And his "Notice" writes: https://github.com/abbodi1406/vcredist#windows-vista-notice ... And he's actually right; the last standalone file "VC_redist.x86.exe" provided by MS that will install out-of-the-box on Vista SP2 32-bit is of version 14.31.30919.0: https://download.visualstudio.microsoft.com/download/pr/8c1c2dbb-0856-4dc3-b863-b16c637bc245/E55681B9E07A58F7143E5AB5941F45DE0B485E0C9933B0CB6B702D3921F48527/VC_redist.x86.exe Subsequent versions 14.31.31005.0, 14.31.31103.0, 14.32.31302.0, 14.32.31326.0 and 14.32.31332.0 had their installers blocked from launching under Vista SP2, but their "payload"/content (various DLLs) continued to remain Vista-compatible ; next version 14.34.31823.3 had several of its DLLs contain Win7+ function calls ... So, the last of abbodi1406's vcredist AIO custom pack with full/proper Vista SP2 support is v0.6.1 (2022-06-21): https://github.com/abbodi1406/vcredist/releases/download/v0.61.0/VisualCppRedist_AIO_x86_x64_61.zip What point would there be in doing so ? Its VS2022 DLLs are incompatible with Vista and, if force-installed, would fully break all apps requiring the VS2015-2022 runtime ...
  7. ... Can confirm ; the page does load, but clicking any of the download options (buttons) doesn't initiate a download ; it's JS related: What's worse, I couldn't get a download to happen with any of 360EEv12/13/13.5 and KafanMiniBrowser, so I'm not able to fetch the Edge files under this Vista SP2 x86 laptop; any working workaround will be appreciated ...
  8. True, but not in the sense discussed here; in 360EEv11, navigate to "chrome://settings/advanced", then scroll further down to "HTTPS/SSL": If you press the top first button (Manage certificates...), you are presented with an OS window: a clear indication it's using the OS cert store... Now, if you click the third bottom button (with Chinese characters), you do get access to its built-in cert store, but that is only meant to be used within China, for mainly Chinese sites: What's more, the user has no edit access whatsoever to that cert store, i.e. expired certs can't be deleted, nor new ones be imported... FYI, all variants of 360EE (v11/12/13/13/5) have the same cert stores structure (access to the MS cert store + QiHoo provided one); more info about the QiHoo/360 cert store can be found at below link: https://caprogram.360.cn/#plan (in the header, select "English") Regards.
  9. ... First press "Apply", then "OK", maybe?
  10. ... Additionally, your OP contains below link: https://xpforever.miraheze.org/wiki/360_Extreme_Explorer which now, sadly, returns : Regards ...
  11. ... How so? When you selected win2k compatibility mode in 360Loader.exe's Properties window, did you click "Apply" before clicking OK? That window looks as below under Vista (should be similar on XP): In any case, can't reproduce this here ...
  12. @Chuck : Also take note of the "workaround" posted by @rereser: https://www.xpforums.com/threads/360-extreme-explorer-chrome-69-for-windows-xp.934574/page-3#post-3269734
  13. Elliptic Curve Cryptography (ECC) is NOT supported by Windows XP SP3, has never been, even with the POSReady updates... But some POSReady update(s) did implement native TLS v1.1/1.2 support in XP - don't ask me for further details, running Vista SP2 here... To update your XP Microsoft Store certs, see below: https://msfn.org/board/topic/183352-proxhttpsproxy-and-httpsproxy-in-windows-xp-for-future-use/
  14. ... Another villain is below "Notifications wizard": to be found in the right GH "sidebar"... It's akin to the "Assets wizard" under GH releases page that you described; when you load a GH page containing either one, the wizards display (in the background) a constantly spinning circle, which consumes many CPU cycles ; the wizards don't display fully until you scroll past them (downwards or upwards), thereafter the CPU consumption drops (until you have to reload the page, that is ...) - this behaviour doesn't change whether you use the native WC implementation (palefill disabled) or palefill standalone (native WC disabled) ... NB: The Notifications wizard pictured above does not display at all when you browse GH being logged-out; the "Assets wizard", however, will still cause the heavy CPU usage until scrolled past... As one would expect , I haven't experienced such heavy CPU usage when using 360EEv13.x to browse GH pages containing those two wizards ... Regards.
  15. ... For starters, you shouldn't do that (when testing), as palefill conflicts/interferes with native WC: https://forum.palemoon.org/viewtopic.php?p=237202#p237202 From Moonchild himself: Second, I have always been talking about Serpent 52 (actually, its previous version of 2023-03-02); but just to humour you and be on the same ground as you, I did launch a quasi-fresh profile of latest NM28 [v28.10.6a1 (32-bit) (2023-03-10)], where I installed and enabled palefill-v1.26 and then restarted it, for good measure... My GitHub testing repo this time is https://github.com/violentmonkey/violentmonkey/commits/master At first load, the relative timestamps do appear (in the "hours" range) - this is now with both palefill+native WC enabled, as you suggested; now try and continuously soft reload that page (by clicking the "reload current page" toolbar button); soon enough you'll get (I did, on my 5th attempt ) the missing timestamps bug: If, like me, you spend hours inside GitHub, then you "can't miss it"; this bug exists, as I've tried in fresh profiles (mainly St52, but lately NM28, too) and combinations of: a) native WC+SR enabled, palefill disabled (recommended by Moonchild) b) native WC+SR enabled, palefill enabled c) either of the two above, being c1) logged-in to GH or c2) logged out from GH The only combination (for me) where the relative GH timestamps remain permanently fixed is d) native WC+SR disabled, palefill enabled FWIW, with the above combination, the (latest) NM28 with fresh profile used to generate above screengrab consumes virtually 0 CPU when being minimised here: Conclusion: Everyone's setup may behave slightly differently, in a stochastic fashion , and this makes troubleshooting and fixing bugs quite a daunting task on the part of the devs ... Best regards.
  16. ... The GH timestamps bug isn't limited to commits view/issue comments etc., and when "minutes" only; e.g. I just loaded https://github.com/gorhill/uBlock/releases/tag/1.47.5b13 and tada : ... Reminds me of palefill issue no. 60 (different but related, sort of ): https://github.com/martok/palefill/issues/60 ...
  17. Hi all ... Over the last 7 days or so, I have been browsing GitHub with the palefill extension disabled, thus making use of the recently corrected+improved native Web Components + Shadow Root support (i.e. "dom.webcomponents.enabled;true"+"dom.getRootNode.enabled;true); this is with previous Serpent v52.9.0 (2023-03-02) (32-bit), because with latest I get xul.dll crashes on GH 404 pages (see previous posts of mine). With native WC I get overall better performance on GH compared to when using palefill (both the prefs I mentioned above should be toggled to false when using palefill, BTW), an added bonus is Turbo (aka "soft navigation") is now working on GH (palefill specifically disables it/is incompatible with it ) ... But I've stumbled upon an irritating bug: GitHub timestamps ; when those are in the "minutes range" (e.g. 20 minutes ago), they pull a disappearing act ... Several minutes ago I loaded https://github.com/roytam1/UXP/commits/custom and took below screengrab: These timestamps are (or should be) dynamic, i.e. after 1 min has passed, their values should increase by 1 (so the one on latest commit should read "16 minutes ago"); give it a minute, boom, all timestamps vanish : To make the timestamps display in their updated state/values, you have to hard-refresh (CTRL+F5) the page (and even that occasionally fails) ... The same thing happens with comment timestamps inside a GH issue tracker; I can't hard-refresh the page while in the middle of writing a comment myself, yet I still need to have a way to tell how back (in minutes) the recent comments above (the one I'm about to submit) were posted ... Can someone with access to "upstream" (e.g. @UCyborg ) relay this bug to them, so, perhaps, it could be investigated and, hopefully, remedied? Many thanks
  18. which is: https://www.superguidatv.it/canali/ My version 360EEv12 (build1592) has no issues loading/displaying those thumbnails/images... But I'm on Vista SP2 32-bit... The images are being served securely from an "api.superguidatv.it" hostname, e.g. for RAI 1: https://api.superguidatv.it/v1/channels/217/logo?width=120&theme=light Perhaps this is a certificates issue in OP's setup? Some other "privacy" related setting and/or extension? If you notice closely, even the images under "GUIDA TV" aren't being displayed, e.g. https://www.superguidatv.it/wp-content/themes/SGTV-Newspaper/img/ic_accesstime_56px.png
  19. ... Not entirely true : https://www.guidingtech.com/best-android-browsers-with-extension-support/ ... and that article doesn't even mention bromite mobile browser ...
  20. ... Tab Mix Plus Hmm..., if you had been closely following the discussions in this thread for the last 2 weeks, then you'd have remembered that tab-affecting extensions (notably TMP and TUP - Tab Utilities Phoenix) had been broken by a tab-related change that landed in previous Serpent 52 - start [re-]reading from here) ... Greetings
  21. ... The Release Notes for your preferred version 1.26.2 clearly state that no code changes exist between it and previous version 1.26.0; the whole purpose served by that .2 release was to address an Easylist-related fonts issue, affecting ONLY Firefox, not Chromium-based forks... You can safely use the .crx file of v1.26.0 hosted on crx4chrome and be done with; it doesn't need "developer mode" enabled and it's just an archive of the very same file as it was available in CWS... Life is hard as it is, one need not make it even harder ... Regards
  22. ... FWIW, it doesn't cause an instant crash if on previous Serpent v52.9.0 (2023-03-02) (32-bit); like my friend (I hope ) @NotHereToPlayGames wrote in the past: "Latest isn't necessarily greatest"; but that's to be expected in St52, on a de facto "unstable/weekly" distribution "channel" ... Actually, this issue was discussed in the official PM Forum; their fix did not make it into last weekend's UXP releases by a matter of just a few hours, but has since been ported to Roy's UXP tree ... To add to that, I have been suffering myself from instant crashes in xul.dll (presumably attributed to the same root cause ) when the below combination is met: a) a WE userscript manager is installed and enabled (in St52), such as Violentmonkey b) the GitHub download zip userscript has been installed and enabled c) when browsing GitHub in general, you (unexpectedly) arrive to a GH 404 page, e.g. https://github.com/ytdl-org/youtube-dl/issues/31950 When on GH, I need that userscript enabled, so I've now gone back to previous St52 build (I don't use TMP), because I spend lots of time there and one never knows when a GH 404 page may come up on you ; hopefully, next weekend's build will relieve me from those crashes ...
  23. ... FWIW, with JS disabled, the top drop-down menus are "unresponsive" (and with it enabled, their content becomes just links) :
  24. Many thanks @UCyborg , much appreciated! So, it wasn't actually "new and exotic", just "old and exotic (Googlism)" ... Interestingly/funnily enough, Mozilla were quick to concoct their own implementation in Fx 56.0, which turned out to be problematic and had to be retracted in v57.0: ... Yes, as early as version 50 (!) of Chromium ... ... What I still don't get (being a non-coder) is why disabling JS works around it - and any answer to my uBO-related "plea-for-help", please ?
  25. ... Reading a certain MSFN post , it contained a link to below MS support article: https://support.microsoft.com/en-us/topic/microsoft-net-framework-repair-tool-is-available-942a01e3-5b8b-7abb-c166-c34a2f4b612a My (main) browser is (latest) St52; the page requested did not render properly : I toyed a bit with disabling recently implemented WebComponents support and restarting the browser, same thing ... Tried Safe Mode, a fresh St52 profile, both to no avail ... Upon further troubleshooting, it emerged ALL UXP-based browsers (+St55) suffer from this "ailment" ... Below is latest NM28 in an almost fresh profile, when displaying: https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392 OTOH, the very OLD 360EEv11 (Ch69-based) has no issue displaying that URL properly: My troubleshooting skills are failing me today , I couldn't get anything meaningful from St52's WebConsole... @roytam1: What is exactly the problem here? Since Ch69 renders "support.microsoft.com" properly, surely it can't be something new and exotic devised by Google that causes the breakage in UXP ... Workaround: While dealing with this, it emerged that my St52 copy can, indeed, render that site OK, provided I disable the JS served; I just used uBlock Origin for convenience, disabling "scripting" selectively on that site alone: Plea for experts' help: I'm not that proficient in uBO's advanced features, can someone among you pinpoint the exact script responsible for the breakage? I spent ca. 30min with uBO's logger trying to identify it, but was not successful (not myself today ...) ; the logic here being to selectively block that script with a custom filter, instead of a blanket "no-scripting" rule on "support.microsoft.com"... Thanks in advance ...
×
×
  • Create New...