Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,345

  • Joined

  • Last visited

  • Days Won

    102

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    If you must use "html5test.com" on Serpent 52 (and the rest of the UXP-based browsers), you can simply use the plain HTTP version of the test suite ; all connections work via plain old HTTP, even the ones to "api.whichbrowser.net":
  2. VistaLover
    Was that under Windows XP? 360EE variants have known limitations under that OS to verify certificates, associated with the OS's inability to support ECC (Elliptic Curve Cryptography) and SNI, among other ailments... The v13.x variants (Ch86-based) are known to produce the infamous "red X" icon in their URL bar over many HTTPS connections, and such reports are common inside the 360EE subforums ... The fact they do connect implies that secure negotiation is, in essence, broken under XP (it is silently by-passed ) ... The "cosmetic" annoyance of the "red X" icon is usually suppressed by the " --ignore-certificate-errors" flag, indeed present inside the "360Loader.ini" shipped with the NHTPG "mods"; are you using one of these? Exactly!
  3. VistaLover
    GitHub, i.e. Microsoft, are currently "baking" another "royal screw" for "legacy" clients/platforms, in the form of "passkeys" ; it's currently under a "Feature Preview" flag one can opt out of, for now: About passkeys - GitHub Docs According to: https://passkeys.dev/device-support/ this "security" feature (which is based on the Web Authentication API) requires at least Google Chrome 108 and Win11 22H2 ... https://passkeys.dev/docs/reference/windows/ I've resisted 2FA on GitHub with a passion (as I don't own a mobile device myself ), but I sense it'll become mandatory even for "plain" GH users such as I ; earlier in the year, it was shoved down the throats of "repo/organisation" managers, or something to that effect...
  4. VistaLover
    ... Of course I do , I was here for all that period... Hopefully, "these dark times" () are now way behind us, never to be experienced again (fingers crossed) ... Are you referring to @i430VX 's one (and various other, home-made recipes, based on batch files) ? Surely, these "convenience" tools could be adapted for newer, more "accurate", browser-package filenames, especially if a notice was put out a week or two before any eventual changes ...
  5. VistaLover
    1. Go to "about:config" 2. Locate "plugins.always_show_indicator" 3. Toggle its value (from false -> true) From then on, once you visit a site requiring Flash (or other NPAPI plugin), you'll always get the plugin icon at the left of the URL bar; below, a NM28 screengrab when visiting: https://www.ultrasounds.com/US.html
  6. VistaLover
    Pardon me for asking, but is that based on some new "policy"/conviction? Also, hash "d849524bd" corresponds to https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/d849524bd which is from 2 (!) years ago... Current tip of the official PM repo is at: https://repo.palemoon.org/MoonchildProductions/UXP/commit/cd0c08484dd8681e20191592527f8b23a8d3c06c If that string is there inside the NM28 package's filename as a remnant from past times, perhaps it should be removed, to avoid confusion (for the few people like myself who actually check commit hashes/source code ) ... The redownloaded package (Last modified: 2023-Jul-15 08:00:34): "basilisk52-g4.8.win32-git-20230715-3219d2d-uxp-787a64cf9-xpmod.7z" actually corresponds to custom UXP branch snapshot cf35c4742 ... And, like above, hash "3219d2d" corresponds to: https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/3219d2d again from two years ago ; tip of the official Bk repo is currently at: https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/6c67945dafc47792c7028b50405cfd65dab2ff77 If that 2yr-old string inside St52's package filename serves no purpose now, perhaps remove it altogether? AFAIAC, latest St52 package could just be named (for x86, SSE2+) as: basilisk52-g4.8.win32-uxp-custom-git-20230715-gcf35c4742-xpmod.7z Kind regards, thanks for the stupendous work you're doing ...
  7. VistaLover
    Almost forgot ; many thanks for that, too !
  8. VistaLover
    ... Indeed it has been! Many thanks for working overtime this Saturday morning ; hopefully, the rest of your weekend will go by trouble-free ... Cheers!
  9. VistaLover
    Latest St55 32-bit (buildID=20230714155931) also crashes here on Vista SP2 32-bit (real H/W): Problem signature: Problem Event Name: APPCRASH Application Name: basilisk.exe Application Version: 4.0.4.8577 Application Timestamp: 64b170e7 Fault Module Name: mozjs.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 64b0ca02 Exception Code: c0000005 Exception Offset: 002de536 OS Version: 6.0.6003.2.2.0.768.3 Locale ID: 1032 Additional Information 1: a67f Additional Information 2: 8e4200aa8f905f18ee13983f66c7e8f4 Additional Information 3: 2966 Additional Information 4: cc936d54cf49a4d8fef1526ed26d9dc2 Possibly a conflict with latest UXP-stuff ported to [what-used-to-be]moebius : https://github.com/roytam1/basilisk55/compare/fe0a96a...ff2d9bb
  10. VistaLover
    ... And yes #2 : https://forum.palemoon.org/viewtopic.php?f=3&p=241116 which concerns the native download manager of UXP applications and where I first witnessed the oddities/bugs (in St52) ...
  11. VistaLover
    https://support.mozilla.org/en-US/kb/control-whether-firefox-automatically-fills-forms
  12. VistaLover
    Please, kindly edit that link to not include the "," at the end, because currently it leads to:
  13. VistaLover
    @roytam1 : As promised : https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/d94b1a31eea71816f2ffbc2593dab09339d8585d https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/19fb10aabcb848ff70bee17a9b8275b6d071e6c8 https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/5c1cad1353778d85c39743bfb07fa840020c8581
  14. VistaLover
    ... I've been following that report , thanks, but as of yet, despite a "complaining" DownloadUtils.jsm file, @martok, the author of the culprit Intl code, still can't reproduce ... Perhaps it'd be wise to point him to the recent, relevant, posts here, affecting NM28 and St52's native download managers ...
  15. VistaLover
    Complete about:buildconfig from latest St52 x86:
  16. VistaLover
    Thanks for that info and much obliged in advance ; waiting hasn't hurt anyone, I guess ; thanks in advance to Roy , too, for when the backport gets merged "here"... OT1: Today's Bing Search homepage image was a dense set of buildings/flats, the info about it told it was a night view of Hong Kong: https://www.bing.com/th?id=OHR.WorldPopDay_ROW3908629060_1920x1080.jpg @roytam1, are you able to spot your own flat there ? OT2: @basilisk-dev : I honestly hope you're not located in those parts of The States afflicted by record high temperatures... If you are, I can surely empathise, since from July 12th a very intense and prolonged heatwave, originating from Northern Africa/The Sahara Desert, will find its way towards my area of the world... Anyone still thinking "Climate Change" is safely many years to come?
  17. VistaLover
    https://repo.palemoon.org/MoonchildProductions/Pale-Moon/releases/tag/32.3.0_Release This was actually PM#1925 (and PM#1926) ; could this be, hopefully, backported to also cover Serpent 52.9.0, please?
  18. VistaLover
    ... Thanks for the confirmation!
  19. VistaLover
    ... Just a short while before you posted this, I had finished applying your fix locally ; unfortunately, this, again, involves messing with the omni.ja archive... The file to be patched according to the GitHub commit resides in: "<St52-appDir>\!omni.ja\modules\DownloadUtils.jsm" (! = expanded) After you've finished patching the file, locate "<St52-appDir>\!omni.ja\jsloader\resource\gre\modules\DownloadUtils.jsm" and DELETE it; this is a compiled version of the (original) file in the previous location; by deleting it, you'll force St52 to load the edited raw source file rather than the compiled one (minute performance degradation to be expected ). Once finished, repack (and re-optimise) to an omni.ja file, overwriting the original... So far, so good ...
  20. VistaLover
    Laptop was waken up from sleep, another vicious circle happened in latest St52, this time trying to download an .EXE file : The same display as above, but with the Downloads Window extension disabled: This is extremely frustrating for me, to the point I'll downgrade to previous weekend's St52 - but, for how long ? Is no-one else seeing something similar? Later addition: FTR, I have below, downloads-related, prefs modified from their default values: browser.download.panel.shown;true browser.download.saveZoneInformation;0 browser.download.useDownloadDir;false privacy.cpd.downloads;false
  21. VistaLover
    Hi @Proteus ; let me assure you you're not imagining things here ; there's definitely something broken in the downloads API of the latest batch of the UXP releases , as I've found myself when updating to the latest St52 (32-bit) ... For starters, something has reset the user-set default download action based on file-extension ; clicking on a link to a zip file, I was presented with below "choose window": For years, my default DL action was "Save File" ; I had to set this anew ... I'm also using the "Downloads Window" legacy extension, which approximates the old, Fx24-era, "toolkit" DL window, but that shouldn't matter, because the extension hooks directly to the "Library=>Downloads" interface... Immediately after saving the zip file shown above, the DLs Window appears completely empty (as reported): When I invoked that window a second time (via the toolbar DL button), only the latest DL entry of the session appears, and even that without its details (size, domain, time): Scrolling down in that 1-entry window makes previous entries magically appear, again without their DL details: The only way to fix those DL "oddities" is a browser restart, after which things return to a "normal" state: Previous St52 x86 build did not suffer from these bugs... @roytam1 , in your "DL-manager-extensions" related post you cited the new IntlAPI commits as the probable culprit, do you think that: [network] Prepare for requiring Authorization in CORS ACAH preflight and: [XPCOM] Win: Update executable extension list could have also played a part towards the DL breakages? Thanks in advance for any insight ...
  22. VistaLover
    ... Thanks a lot for your test ; this, in turn, "pushed" me to run a second set of testing, this time with fresh/clean St55 profiles... TEST 1: Latest St55 x86 package, i.e.: basilisk55-win32-git-20230708-fe0a96ad1-xpmod I loaded a pristine St55 profile and then visited the DRM test page, i.e.: https://bitmovin.com/demos/drm I let St55 "download and install necessary components" (ca. 5min, for good measure ), then I restarted it; result: The Widevine CDM populates the plugins list inside "about:plugins", as well as the plugins list in "about:addons => plugins": This means I have to debug my current St55 "dirty" profile as to why WV CDM is absent in both these lists ... However, the end result is the same as reported by @Mathwiz ; EME/DRM/Widevine doesn't work as intended on the browser side: NB: On that screengrab above, I have also highlighted the "glitches" the default theme exhibits under Vista's Aero... TEST 2: Downgrade St55 x86 to the March 30th 2019 package, i.e.: basilisk55-win32-git-20190330-09b851794-xpmod Load with it the same clean-ish St55 profile created in TEST 1 and, again, visit the same DRM test page; the "story" now is very different: 1. The "DRM" icon does appear in the URL bar 2. EME/DRM/Widevine work as intended on the browser side, but DRM licence acquisition fails on the WV server side, because the CDM version requesting it has been revoked... NB2: One can also visually confirm in the screengrab above how "well" the default St55 theme blends with the Vista OS and its Aero feature ... ... Not "moot point" for me though , because when the Widevine implementation in Serpent works (it currently does in 52, does not in 55), it will alert me that the media service visited employs DRM, thus I'll have to view the content on a sanctioned browser, on a sanctioned OS... If I had to put my money on it, I'd claim: 1. St55's default theme under Vista has been broken by: port most of XP related hunks from iceweaselXP-53 2. As posted already, Widevine in St55/Vista+ has been broken by: ported change from iceweaselXP-53: Restored eme-adobe plugin support for Windows XP systems. Do you see it? It was "iceweaselXP" (Widevine wasn't "meant" to work under XP, and, likewise, XP doesn't support "Aero"...). Probably very difficult to fix both now...
  23. VistaLover
    ... I don't even have Adobe Primetime CDM installed in my Serpent 55 profile - never needed it on Vista SP2, TBH ; but, I do have the Cisco Systems OpenH264 video codec v1.6 installed (and disabled), which correctly displays inside about:addons and about:plugins; widevine doesn't in either ; in my St55 profile, I have: media.eme.enabled;true media.gmp-widevinecdm.autoupdate;true media.gmp-widevinecdm.enabled;true media.gmp-widevinecdm.visible;true and the CDM correctly installed. When I downgrade St55 to a build before Apr 2019, in that same profile, then WV CDM is correctly recognised and additional prefs: user_pref("media.gmp-widevinecdm.abi", "x86-msvc-x86"); user_pref("media.gmp-widevinecdm.autoupdate", true); user_pref("media.gmp-widevinecdm.lastUpdate", 1549772952); user_pref("media.gmp-widevinecdm.version", "1.4.8.903"); appear inside my profile's pref.js file... Update St55 and these prefs are NOT read! Am afraid I've given all pertinent detail I found at the time; FWIW, I suppose you can troubleshoot DRM/Widevine issues in St55 on a Win7 OS too, probably no immediate need to install a Vista VM (a necessary step to troubleshoot the default St55 theme issue reported though, because under Win7 all looks fine); might be worth to inspect how St52 does it, as there both Adobe Primetime and Widevine can happily coexist... (Apologies, it's finally bed time here, so I'll be unavailable for quite a while ...) Edit: See further tests and discussion here ...
  24. VistaLover
    ... This is not accurate, though, because roytam1 did restore the bits of code that implement native Vista SP2 WMF support that Mozilla (and MCP) had originally removed... Yes, that's true, support for patented decoders aiming the XP OS (and Vista without PUS[Platform Update Supplement]) had been realised via modifying the ffvpx library, which uses ffmpeg code... Latest St55 (32-bit) comes with both media.wmf.enabled;true media.ffvpx.enabled;true and if I disable ffvpx, the app can still play back MP4 files via Vista's WMF ; the only major advantage of Vista's WMF over the ffvpx lib is that WMF allows for H/W decoding of h.264 video, provided your GFX card supports it; mine doesn't , so ffvpx stays turned ON... On the Vista side of things, however, two "things" at least remain broken ... a. The default St55 (complete) theme renders unsatisfactorily in the caption buttons (minimize/maximize-restore/close) area; it was all fine in the first St55 builds, below is a snapshot from a March 2018 St55 build: (which shows good rendering around the caption buttons area), but at some later point (I think it was one tenfourfox backport?) it broke in the same manner the default St52 theme renders under Vista: b. While St55 is still being built with "--enable-eme=widevine", its EME/WV implementation has been broken since many years ; by "broken" I don't mean that the WV CDM "can't properly decrypt DRM'ed content", this is to be expected if Widevine worked in the first place , because St55 inherited WV v1.4.8.903 from Mozilla, and that very old version has been deprecated by Google many years ago ... The actual problem/bug is that currently St55 doesn't even recognise the WV CDM when correctly installed and it doesn't display it at all inside the about:plugins list (provided "Play DRM content" has been enabled in preferences); this is a long standing issue I never bothered to report, because I normally use St52 to detect DRMed online media content ... Unlike the default theme issue above (a), I had kept records of the manifestation of this bug, here it goes: Last GOOD build: basilisk55-win32-git-20190330-09b851794-xpmod (buildID=20190329133942) First BAD build: basilisk55-win32-git-20190406-4d70836fa-xpmod (buildID=20190405065215) Regression window: https://github.com/roytam1/basilisk55/compare/09b851794...4d70836fa Probable culprit: ported change from iceweaselXP-53: Restored eme-adobe plugin support for Windows XP systems. So, in order to supply Windows XP users with an additional way to play-back MP4/m4a files in St55 (via the Adobe Primetime CDM, already familiar with in FxESR 52/St52), Widevine CDM became broken for Vista+ users ... Widevine CDM v1.4.8.903 for St55 (32-bit): https://www.mediafire.com/file/jrjkcqazh1xz6ce/gmp-widevinecdm.7z/file (The file should be extracted as a "gmp-widevinecdm\1.4.8.903\*" dir tree and placed inside your St55 profile directory); testing should be done on, e.g., https://bitmovin.com/demos/drm on fully updated Vista SP2 onwards, with up-to (and including) "basilisk55-win32-git-20190330-09b851794-xpmod": Later versions of St55 will just report:
  25. VistaLover
    It wasn't like that at all, actually ... The Mozilla "plans" had been laid out long before, and it was to ape what Google had done already: Remove Vista support at the same time Windows XP support was to be removed ... Some sane voices at the time did point out that Vista support could well have been extended at least up to Firefox v54.0, but Mozilla devs were adamant: Vista was to be taken, alongside XP, to the FxESR 52 update channel when Fx53 was ready for general release, and then be left to rot after 52ESR becomes EOL; FWIW, it was Fx55 that contained lots of compiled Rust code, that required Win7+ to run on... The story is now repeated: Win7/8/8.1 will be soon moved to the FxESR 115 update channel and then be done with ... ... The deprecation of XP+Vista happened early on during the Fx-Nightly 53.0a1 development cycle, in mid-November of 2016, and it was then and there my Firefox Nightly Tester "days" abruptly ended ; I don't want to relive old history, I think I have detailed this somewhere inside the Vista subforums (so an advanced Forum search might yield relevant results ); from faint memory, I recall that the fork-point for Moebius was a Feb/Mar 2017 53.0a1 code snapshot; final 53.0 was released on Apr 19th, 2017 (as linked already...) .
×
×
  • Create New...