Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


VistaLover

Member
  • Content Count

    520
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by VistaLover

  1. It's because of the recent change in the hostname; "o.rths.cf" => "o.rths.ml"
  2. ... and I honestly hope that isn't a recent screengrab, because the Engine Version and AV+AM definitions are very outdated ; http://www.microsoft.com/en-us/wdsi/defenderupdates latest Engine Version: 1.1.16400.2 latest defs version: 1.303.1880.0
  3. Hello again ; I have never used the Android (mobile) version of Firefox, Quantum or pre-Quantum, so can't really tell if an import HTML bookmarks feature ever existed there; however, casual on-line searching dictates that the only way to import bookmarks from a desktop (Firefox) browser version is through Mozilla Sync. I guess you can still achieve what you want - if you limit your syncing to only a transfer of Serpent 52 bookmarks to mobile Firefox - if you use Firefox ESR 52.9.x on your Windows XP desktop as a sort of man-in-the-middle; you can still keep Serpent 52.9.0 as your daily browser, but only use Firefox ESR 52.9.x (with a simple default profile, without extensions) when you want to transfer bookmarks... Transferring Serpent 52's bookmarks to FirefoxESR 52 should be a trivial and straightforward process; I think both the HTML and JSON formats are supported (export to HTML file is the obvious route, but you can also create a bookmarks back-up file in JSON format, which can then be loaded/restored in FirefoxESR 52). Once you have successfully migrated your Serpent 52 bookmarks to FxESR 52, you can then use your Firefox Account credentials to log-in to Mozilla Sync, and then selectively sync the bookmarks present there with your Android Firefox version on your phone/tablet - should work! Of course, you are at the mercy of Mozilla, as I suspect at some time not far away they'll disconnect old & unsupported versions of the Firefox browser from their Sync servers... Greetings
  4. Of course @burd is the one to clarify things, but I've seen this orange colouring of the MSE tray icon (in my sister's Win7 x64 laptop) when a System (quick) Scan hasn't been performed for a certain while - in an otherwise fully updated MSE installation; manually initiating the scan and after its successful completion, the icon colour should return to green (barring any issues found) ... Not very surprising if that is just a remnant of a prior Dropbox installation, at a time when the OS was still supported; for a brief period after the end of official support, the following post by @WinClient5270 was relevant: but that hack soon ceased to work ; if you look closely at the screengrab posted by @burd: you'll notice the dropbox tray icon being grey, meaning the desktop client can't connect to the service... But then I could be way-off-base... Regards For reference: https://www.dropboxforum.com/t5/Installs-integrations/When-will-Vista-no-longer-be-supported-by-Dropbox/td-p/261493
  5. VistaLover

    bora virus

    ... Commiserations . Had you taken diligent preventive measures in your OS (e.g. a reputed anti-malware/anti-virus third party suite, coupled with a responsible browsing behaviour), chances are you wouldn't have been infected - but then again, no Security Suite is foolproof... Out of curiosity, was Microsoft Security Essentials (MSE) even installed and updated? Just to get this out in the clear, BORA is a ransonware with very strong encryption, so be prepared to part ways with your personal ENCRYPTED files... Slim chances do exist you can restore at least some of them, but... Every anti-malware software author has compiled at least one remove-BORA-infection tutorial on the net, this is what a simple G-search would reveal: https://www.google.com/search?q=bora+file+extension+virus&ie=utf-8&oe=utf-8 Follow your favourite one - be advised the more you use your infected computer, the less percentage of your original files you'll be able to recover (as they are being overwritten in your HD). Restoring an image back-up of your system and files (should that exist) is your safest bet - as far as I am aware, a simple System Restore (if enabled) won't "restore" personal files (like documents, e-mails, photos, etc...).
  6. What one likes to do and what is actually feasible is, sadly, often quite different things... This issue has been brought up several times in the past, most recently in another XP thread: My own reply there: https://msfn.org/board/topic/180280-automatic-user-agent-spoofing-in-firefox-51/?do=findComment&comment=1171254 TL;DR: if you'd like to sync between the android version of Firefox (now in Quantum version 69?) and roytam1's Serpent 52.9.0 on a Windows [XP] PC, then it simply isn't possible anymore! You can reportedly still sync between Mobile Firefox and Firefox ESR 52.9.1 and, at least in theory, between Mobile Firefox and Serpent 55.0.0 If a mobile version of current Pale Moon 28 were officially available, you could, in theory, sync between Mobile PM28 and official Basilisk (52)/official Pale Moon 28 (desktop) - and New Moon 28; since Serpent 52.9.0 has retained support for WEs, sync between it and PM28 might only be partial ; but official mobile PM28 doesn't exist; please read these following relevant exchanges in the official PM forum: https://forum.palemoon.org/viewtopic.php?p=174199#p174199 (and the posts after that one...) https://forum.palemoon.org/viewtopic.php?f=39&t=21179 Regards
  7. Could you clarify, please? Do you mean it doesn't launch at all under Windows XP with an SSE-only CPU, or that it doesn't offer the option to install the SSE-only flavour of the New Moon 27[9.6] browser? If it's the latter, I'm sure @i430VX will, at least, consider implementing this useful for you option in the near future; just keep in mind this is a volunteer project offered as-is and maintained during one's own spare time - not to mention managing a server to host it and the cost of the associated bandwidth...
  8. Confirmed ; here's what Web Console in Serpent 52 shows: @roytam1, could you have a look?
  9. Actually, I never said that; what I said was: i.e. I couldn't be sure off the top of my head whether VP9 support is present in Fx 48; I had to search about this, Implement VP9 video decoder in Firefox suggests VP9 codec support landed in Fx 28, ergo is indeed present in Firefox 48 . In any case, I've instructed you how to tell the video codec used in the clip reproduced in youtube's HTML5 embedded player; based on your report (and my search), VP8+VP9 ones should be OK; h264 (avc1) wouldn't play How one's own clips have been originally encoded and packaged (in what media container...) prior to uploading them to youtube is kind of a moot point, because once the original encodes reach yt's servers, they are being re-encoded (re-coded and/or trans-coded) to several different formats/resolutions, to be able to meet yt's dynamic streaming requirements; you can easily check this fact by using one of the several "youtube downloading" apps (e.g. the CLI youtube-dl) and see how your originally uploaded video (in a defined resolution, bitrate, container, etc) is now available in several "qualities". Google have recently (Aug 9th 2019) removed their very useful youtube/HTML5 test page, http://web.archive.org/web/20190805082454/https://www.youtube.com/html5 which was invaluable in troubleshooting HTML5 video playback in browsers (they've replaced it with https://www.youtube.com/supported_browsers and I suppose the reasoning behind the original's removal is that Google now only support latest versions of Firefox, Google Chrome, Edge, Opera - all these browsers had been, since long ago, passing the tests extant in that previous page with flying colours; of course, they don't care about older unsupported versions of browsers on unsupported OSes... ). As I said, the procedure outlined in the first post of this thread was tailored, tried, and known to successfully work in Firefox ESR 52, the last released for XP (but with an SSE2 capable processor); Fx 48.0.2 is not Fx ESR 52.9.1, so there might be other factors why the procedure doesn't yield the expected result in your case (???...) Perhaps some of the documented about:config prefs need to be modified for Fx 48? Some other(s) missing? ... Hard to tell; it would help if other SSE-only XP users could test and report back (to rule out it just isn't you..); @looking4awayout, would you possibly care to oblige, please...? Firefox 48 was at a peculiar spot with regards to Adobe Primetime CDM; Adobe had signaled Mozilla that their closed-source module wouldn't be able to be used on XP for its original purpose, i.e. decrypt DRM content, and that they (Adobe) would only continue its development targeting Vista onwards... The module itself had some unresolved bugs on XP machines that Adobe weren't inclined to fix; Mozilla OTOH did not have at the time a concrete plan what to do with it; they swayed between leaving it visible and enabled on XP (and Vista OEM) for MP4 decoding purposes, not downloading it by default on XP, hiding it completely on XP (just like they did with WidevineCDM) etc... So, as to what extent was/is AP CDM supposed to work in Fx 48, I can't honestly be sure... The module was at one stage upgraded from version 15 to 17 (16 was only an interim update for 64-bit Firefox), and then EOL'ed in favour of WidevineCDM; v17 had lesser bugs on XP, Mozilla decided to keep it alive a bit longer, until Fx 51; Fx 52 did not come with official support, nor would it download it by default; finally, the underlying support code was completely removed from the codebase in Firefox 53.0. Pending reports from other SSE-only users, I'd speculate that your failure is caused by the CDM's inferred dependency on a SSE2 CPU; while the browser itself may be fine with just SSE, the module might be needing SSE2 instruction set to function properly... I tried to find documentation to sustain my claim, but, sadly, Adobe have now removed almost everything related to the CDM ("help.adobe.com/en_US/primetime/drm/HTML5_CDM" now redirects to a recent page ); I stumbled upon a blog article by some Russian guy, https://weekly-geekly.github.io/articles/373803/index.html it's quite long, but inside it there's this part ... which I interpreted to mean: "set this pref to false, unless you have an SSE2 CPU and the Adobe Primetime CDM installed" ; so my bet is on Primetime requiring SSE2... It's quite a long shot, but perhaps you might try the previous version of the module, version 15, accessed via https://cdmdownload.adobe.com/firefox/win/x86/primetime_gmp_win_x86_gmc_30527.1.zip (if it doesn't need SSE2, then you might have a chance...) You are not left without other options ; several members here on SSE-only processors use @roytam1's Firefox ESR 45.x.x fork (but I'm not sure whether he has modded it for h264 support under XP) and New Moon 27-SSE; the latter does indeed come with h264+aac support, courtesy of custom LAV files you have to download separately and place inside NM27's main folder - just be sure to download the SSE-only flavour of the LAV .dlls (and I'm sure you know already, but security-wise, official Firefox ESR 45.9.0 is more secure than Firefox 48.0.2 ). Hope I've helped a little...
  10. This assumption couldn't be more wrong... Youtube (i.e. Google) employ a variety of streaming methodologies and combinations of video+audio codecs, there's not a one-size-fits-all philosophy here... The older VP8 video codec is natively supported in Firefox, so is the newer VP9, but I'm unsure about its support in Fx 48 that you're using ; Firefox also supports natively the very widely used h264 (AVC1) video codec, but only on Vista SP2 (with platform update supplement); h264 support in Firefox implies Windows Media Foundation (WMF) framework, an OS feature absent in XP; the use of Adobe Primetime CDM in Firefox under XP is meant exactly to mitigate this missing OS feature, since the CDM comes with its own h264 decoder, which the browser can then use to decode unencrypted MP4 video... Right-clicking the Youtube embedded HTML5 player and then choosing "Stats for nerds" will tell you what codecs are being used in the streamed video; Additionally, MPEG-DASH streaming in Youtube (notably the high resolutions) requires the browser to support Media Sourse Extensions (MSE), but not all Youtube videos use that, some use the older "progressive download" type of streams; OTOH, live Youtube streams (may) use AppleHLS streams; so no, if one clip plays, it's not a given all the rest would also play... @vipejc is correct; YouTube have completely killed their Flash embedded player; I suspect those "older" clips that do play are in the older VP8 codec, supported natively in Firefox... If you head to about:addons/plugins (and even about:plugins), can you spot an entry for the Adobe Primetime CDM? if yes, is it always enabled? If there isn't an entry for it, something's gone awry in its proper installation... Any reason why not using Firefox ESR 52.9.1 (on which the procedure is known to work)?
  11. ... More rather a belated release to patch a vulnerability made public in September! https://borncity.com/win/2019/10/03/internet-explorer-cumulative-update-kb4524135-10-03-2019/ I'd still look out in the Catalog come next Patch Tuesday (Oct 8th 2019) for a newer IE9 cumulative update...
  12. ... A few posts above, this very page:
  13. ... The majority are not! Both New Moon 28 (27 too?) and Serpent 52.9.0 now use the Pale Moon Sync infrastructure (not compatible with latest Mozilla Sync ); I recall official Basilisk was the last to switch to PMS (and this change was decided upstream, i.e. by MCP), because of incompatibilities between UXP and Mozilla Sync; I never use MozSync/PMS, so I might be wrong, but I believe Serpent 55.0.0/Moebius still has the Mozilla Sync functions left intact; if it's now still able to connect to Mozilla Sync servers is another matter, though ( I think Mozilla have hardened their access list (client keys) to limit connection to official Mozilla apps, only...).
  14. Apologies, but I don't quite get the gist of your question... The "Forget about this site" context menu entry in a history entry actually has the following functions: (... from https://support.mozilla.org/en-US/kb/delete-browsing-search-download-history-firefox ) ============================================= Remove a single website from your history 1. Click the Library button , click History and then click the Show All History bar at the bottom to open the Library window. 2. Search for the website you want to remove from your history by typing its name in the Search History field in the top-right corner and then pressing Enter. 3. Then, in the search results, right-click on the site you want to remove, and select Forget About This Site. All history items (browsing and download history, cookies, cache, active logins, passwords, saved form data, exceptions for cookies, images, pop-ups) for that site will be removed. Finally, close the Library window. ============================================= In what way(s) do you want to modify the above functionality? Also, info about a related query: What is the difference between "Delete" & "Forget about this site" when deleting a single item in the 'History'? FWIW, if you don't want NM to store any info about specific sites you visit, there's always a NEW PRIVATE WINDOW (or New Private Tab, if you're willing to install an additional extension) ... Regards
  15. ... It looks as though the BETA channel has lagged behind the stable release one... https://desktop.telegram.org/changelog#beta-version By visiting their official GitHub repository, https://github.com/telegramdesktop/tdesktop/releases the latest stable release posted there is at version 1.8.11 (updated a mere two hours ago...) That same version can be obtained by visiting the main site: https://desktop.telegram.org/ At least on their GitHub repo, https://github.com/telegramdesktop/tdesktop#supported-systems suggests Windows XP as being still supported Though not a Telegram user, I decided to conduct some tests here, on Vista SP2 32-bit; I fetched the "portable" 1.8.10 package from GitHub, it had no issues launching: As you see, I, too, was greeted by the red header with the warning, but the behaviour of the app itself contradicts that warning, as it's automatically downloading (in the background) the update to the newer version; once I click UPDATE TELEGRAM, the app is restarted to latest version 1.8.11: Are you saying this is no longer possible under XP? In any case, if I choose to hide the red header here (by clicking the white X), this option is honoured and it isn't displayed anymore in future relaunches of the app... Generally speaking, when still running XP or Vista, it's a dead certainty that currently working software will cease to function sometime in the near (or, hopefully, not so near) future; this will soon-ish become also true for Windows 7, though I suspect the deprecation of this very popular Win OS will come much slower compared to Vista and, to a lesser extent, XP... OT: I have British and Greek friends in the UK with whom I communicate frequently ; I was under the impression DAB broadcasts used as high a bitrate as 192kbps, but employing the less efficient audio codec MP2... Anyhow, FM analog broadcast in the UK is slated for the ax... WRT Capital London: On occasion, I also like to listen to this commercial radio station (although I shouldn't really be listening from overseas... ); their public online stream is indeed abysmal, only HE-AACv1@48kbps (adequate, I guess, for mobile devices and poor laptop speakers); there's a higher quality - non public - stream of theirs at http://media-ice.musicradio.com:80/CapitalMP3 This is in high contrast to BBC Radio streams which, if inside the UK, are offered as AAC LC@320kbps Cheers
  16. @3dreal: Please UNINSTALL the German language pack first, restart the NM27 browser and then proceed with resetting it! The cause of the error reported is that the last official language packs for Pale Moon 27.9.4 are no longer fully compatible with latest New Moon 27.9.6 Arctic-Fox changes imported by @roytam1 (specifically, implementation of service workers in Tycho, a feature not present in the original platform maintained by MCP) introduced new strings in the about:support internal page, which are missing in official (and no longer maintained) PM27 language packs - in order for the outdated PM27 LPs to be compatible with latest NM27, they have to be updated with the missing strings! Regards
  17. ... What makes you say that, actually? Is there an official announcement to support the claim x86 release builds are to be discontinued? FTR, 1.7.20538 is the latest STABLE release, has been out since Sept 19th, 2019; if you head to vendor's (official) download page, https://potplayer.daum.net/ both links (32-bit DOWNLOAD + 64-bit DOWNLOAD) yield version 1.7.20538 installers... This change has been documented in the latest Release Notes: As you, I don't see the reasoning behind this change ; only fairly recent CPU+GPU combinations support hardware decoding of h265/HEVC (and only on Vista SP2 +) . This, in essence, means downgrading PotPlayer ; another way to tackle this is to install (if not already) the Open Codec bundle and then, via the player's GUI, change h265/HEVC decoder to the one from ffmpeg.dll: Regards
  18. ... Actually, den, we haven't tried to do "that" at all ; what was in fact done, thanks to personal effort by @Mathwiz , was to simply redirect "upstream" references (links, mostly) found inside the forks' (NM+Serpent) interface from the official locations (e.g. support forums) to, as an interim solution, primarily this very MSFN thread, to be replaced in the future by a more dedicated help site, if/when @roytam1 finds personal time to set up such a facility... Those steps were taken as a stop-gap solution to deter "clueless" (this was my own personal characterisation) fork users from (accidentally?) seeking support through the official upstream channels (which is a thing known to vex immensely the upstream devs) ... What Matt A. Tobin has always asked for, from the very start, was proper rebranding of the forked browsers/applications, especially where it concerns the forks derived from the official Binary Outcast repository (i.e. from official Interlink & Borealis Navigator apps); proper rebranding entails the complete change of the "generic" fork names (currently New Moon & Serpent, citing only MCP apps), accompanied by new artwork for each fork, different to the existing "generic" fork artwork currently put in place by the upstream team... More like calling New Moon "Sophia Loren" and Serpent "Marcello Mastroianni" , with appropriate artwork changes...
  19. @Matt A. Tobin: This is the first time I have "liked" one of your posts here, and that was because no "insanity" whatsoever was contained in it, no name-calling, no other profanity, no looking down on unbranded fork users etc. I, for one, have been very careful not to call the "forks" by their upstream names, whenever I mentioned Pale Moon and/or Basilisk here (i.e. official branding), I was explicitly referring to them... Of course, the chasm that exists between this community and you, basically because of "what" was exchanged in the past (from both sides ), will be difficult to bridge, and I am still uncertain whether you have any intent yourself towards this goal... However, at least for me, future contributions like your last one, with insightful and helpful content, will be welcome! Greetings
  20. My suspicion confounded by one (@adesh) of the MCP team of developers: https://forum.palemoon.org/viewtopic.php?p=175532&sid=831a96dffc8894f34347620b222a2c6d#p175532 So, UXP (Fx ESR 52 derived) lacks FUEL (removed in Fx 47), hence the same applies to Basilisk/Serpent 52. Pale Moon 28 carries over FUEL from its predecessor Pale Moon 27, FUEL itself survives the porting thanks to Matt A. Tobin (!): https://github.com/MoonchildProductions/UXP/issues/1083 (deprecate != remove)
  21. Neither do I ; I just pointed out that the most prominent difference between NM28/UXP and St52/UXP is Australis infrastructure (not only limited to the GUI) in the latter . I am/was under the impression FUEL had been a platform-wide "under-the-hood" technology, so that would not explain why WD (web destroyer) works in NM28 but fails in St52... It appears I am at fault and that - in the case of NM28 vs St52 - it's a feature only present at application level (?); no doubt FUEL is still present in NM27/Tycho (FxESR 38 based), most probably it was carried over when Pale (New) Moon was ported to UXP ; I guess Moonchild is the one to confirm this... Perhaps WD can be ported to work in Bk/St52 without FUEL; hard to tell, really (and I'm, most certainly, not the one equipped to do this) ... CAA is not to blame here, the data it archived was all inherited from AMO ; many months before all the "legacy" extensions were exterminated from AMO itself (October 2018?), they were labeled, in a blanket fashion, as being compatible with a maximum Fx version of 56.*, the last non-Quantum release; this move was probably made so as to mark them for their inevitable future deletion from AMO and differentiate them from the Quantum-only compatible WE-format... Of course, no-one within Mozilla did test each and every legacy extension for Fx 56.0 compatibility; taking the extension in question as an example, destroy-the-web-1.2.2.1-signed.1-signed.xpi has an install.rdf file with: <em:minVersion>3.5</em:minVersion> <em:maxVersion>19.*</em:maxVersion> So, the last time its developer was around to properly update it, he marked it as being Fx 19.x compatible, max... ; I haven't checked, but perhaps 19.0 was the then current version of Fx when the extension was released... Of course, thanks to your troubleshooting , we now know that the truly maximum Fx version on which the extension works is 46.*, hence <em:maxVersion>46.*</em:maxVersion> should be the appropriate value...
  22. Unfortunately, this is a known and long-standing issue with @roytam1's browsers on some (luckily few) hardware configurations (probably CPU+audio card) on Windows XP; the root cause is yet unknown, a fix for this issue still pending/improbable... XP lacks OS-provided patented audio decoders to decode the AAC-LC/HE-AAC raw (elementary) audio stream inside MP4 media streams (e.g. twitter & instagram video clips), reproducible via the browser's native HTML5 media player; in NM28/St52/St55, Roy offers ffmpeg audio (and video) decoders inside a custom ffvpx third party library to mitigate this XP shortcoming; it's this audio codec that fails on said configurations, especially in the case of HLS fragmented streams... In the case of Serpent 52.9.0 (and fairly recent builds of Serpent 55), you can try installing the Adobe Primetime CDM and change to that as an audio decoder (details are to be found elsewhere in the forums...); however, this is not a cure-all approach, just a suggestion... Best regards
  23. ... Absolutely NOTHING to be worried about when upgrading, provided you take (recommended) wise & precautionary steps: 1. Locate your existing browser (MyPal) profile, Help -> Troubleshooting Information -> Profile folder -> Open folder and back it up (the whole folder and its contents) in a secure location on your disk. 2. Download the new installer (currently at version 28.7.1) and run it. https://github.com/Feodor2/Mypal/releases/tag/28.7.1 If in the past you had opted for the "portable" installation type (i.e. the profile resides inside the installation directory), then do likewise when updating... 3. Launch and test the new version - settings/configurations inside your existing profile should've remained intact! 4. If you decide to downgrade to your previous version (28.4.0 ?) of MyPal, then locate the corresponding setup from the releases tab: https://github.com/Feodor2/Mypal/releases and install that; just don't launch the browser after the downgrade! 5. Restore your saved profile (from step 1) so as to overwrite the profile touched by 28.7.1 and you should be back at a state prior to the "updating" test!
  24. ... Seems to be the cause of breakage; I fetched the destroy-the-web-1.2.2.1-signed.1-signed.xpi file to disk and extracted it with 7-zip; lo and behold, file "./resources/wdcommon.js" has several references to FUEL: L41-L43 var WebDestroyer = { /* The FUEL Application object. */ get Application() { return this._application; }, L51-L52 /* The FUEL Application object. */ _application : null, L86-L87 this._application = Cc["@mozilla.org/fuel/application;1"].getService(Ci.fuelIApplication); Didn't bother to probe the other .js files belonging to the extension... What begs the question is your statement: since they are both built on the same UXP platform, with the one standing out difference being PM28 uses the pre-Australis GUI, while, of course, Bk52 the Australis one... PS: I see you posted the same query on the official forums, too... https://forum.palemoon.org/viewtopic.php?f=46&t=22996
  25. ... If the CPU there has SSE2 support, you can always try running (if you haven't yet ) the latest New Moon 28 (32-bit/64-bit) / UXP for which, to the best of my knowledge, the officially provided Russian LP should work OK: https://github.com/JustOff/pale-moon-localization/releases/download/28.7.0_RC3/ru.xpi To install it, after saving the XPI on disk, it may be necessary to modify its install.rdf file, from <em:maxVersion>28.7.*</em:maxVersion> to <em:maxVersion>28.8.*</em:maxVersion> (since latest NM28 is at version 28.8.0a1 already...). BTW, did the suggested 27.x ru.xpi work at all in NM27? Greetings
×
×
  • Create New...