Jump to content

Mathwiz

Member
  • Posts

    1,836
  • Joined

  • Last visited

  • Days Won

    50
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Probably, the extension uses JavaScript to decode JPEG XL, which is probably a lot slower than a JPEG XL decoder written in C or C++. Yes, 4.3.12 was the version I was looking for. I did stumble across it at portableapps.com, and wondered if they had the full version vs. just an "online" installer that wouldn't work. But portableapps.com has their own "PortableApps Platform" which looked like yet another complication. Turns out you don't have to use it, but I also figured a "portable" app wouldn't upgrade my existing app or keep my settings. After all, by definition a "portable" app is designed to be installed on and run from a thumb drive. Besides, I was already disgusted with dotPDN's attitude. I didn't mind that they stopped supporting Win 7, but what really irked me was that they went out of their way to erase their last Win 7 version from as much of the Internet as possible, so if you didn't upgrade in the days between 4.3.12 and 4.4, you were SOL. Reminded me of too many folks' attitude towards XP/Vista: "We've decided not only to stop supporting it, but that you shouldn't be using it, so we're going to do as much as we can to pressure you to 'upgrade.'" Oh - and Paint.net 4.3.12 doesn't come with the JPEG XL plugin - you have to add that later yourself. Switching to Gimp was a lot less work.
  2. Serpent may be a somewhat different beast. It (well, at least St 55) has a second pref, network.http.accept.image (that I guess MCP added), but I don't know what it does as compared to the pref inherited from FF. But in any case, the FF 52 experiment showed that Bing isn't smart enough not to send WebP to a browser that indicates it doesn't want WebP. Extremely bad practice, indeed. Back to JPEG XL. I tried to update Paint.net on my Win 7 system last night to a version that supports JPEG XL (which happens to be the last Paint.net version for Win 7), and discovered the author meanly removed all but the latest (Win 10+) version from his GitHub page. I tried to find the needed version, but the only installer I could find is an "online" installer and it kept getting a stupid SSL error. I don't have time for that kind of nonsense, so I just uninstalled Paint.net and switched to Gimp. Gimp isn't as user-friendly, but it still runs on Win 7 and it includes a JPEG XL plugin. I loaded in a big 3.3MB .PNG image and exported it as .JXL. The two images look identical to my (admittedly untrained) eyes, but the .JXL one was about 1/4 the size of the .PNG. Wow - no wonder folks want to switch!
  3. It probably works for the very specific case of Bing on IE, because Microsoft wrote IE and knows what will (and won't) work with it. As for FF 52, by default it just sends Accept: */* for images, which just tells the Web page to send whatever it thinks is best, so Bing sends WebP which doesn't work. There's a pref in FF-based browsers to control what image formats it tells the Web page to use: image.http.accept. Perhaps changing the pref from */* to something like image/png,image/jpeg,image/*;q=0.3,*/*;q=0.1 would get Bing to send FF 52 the correct format. In the latest Serpent 55, that pref defaults to image/webp,image/jxr,image/png,image/*;q=0.1,*/*;q=0.1 (Note that image/jxr is JPEG extended range, not a typo for JXL.) So if @roytam1 adds JPEG XL support to Serpent, he should probably add image/jxl to the front of that default value string. Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values#values_for_an_image
  4. Yep - same goes for me. Just as a reminder, the "web" doesn't use JPEG XL because Chrome pulled support for it, and no Web designer is going to use anything Chrome doesn't support. And Chrome pulled support for it because Google has their own alternative they want the Web to use instead. It's the "not-invented-here" syndrome.
  5. To be fair, MyPal 68 is still in beta, and its author lives in a country at war, so I'm not surprised that 68 still isn't very stable. It's stunning that it works on XP at all, given that Rust was supposedly fundamentally incompatible with XP. My comments were merely to express surprise that it's more stable in single-process mode, and to wonder whether that applies to Windows 7 or only to XP.
  6. @chermany4ever said he doesn't have enough RAM for multiprocess mode, so he should definitely make the settings changes to disable it, whichever FF-based browser he ultimately chooses. But my experience with using multiprocess mode in Serpent 55 has been generally positive. Besides higher RAM usage, it does have downsides I mentioned earlier, but instability hasn't been one of them. I haven't noticed an increase in crashes, and if a tab does crash, it rarely takes the whole browser down. Instead, you just refresh the crashed tab. I haven't tried MyPal 68, but I would've expected multiprocess mode to be even more stable by the time Mozilla got to version 68. Perhaps multiprocess mode has grown less stable on XP since Mozilla obviously doesn't test on XP, but I'd expect it to be OK on Win 7 if you have enough RAM. Make sure you get Waterfox Classic. AIUI, at some point "Waterfox" got sold to some corporation that wasn't committed to the original spirit of the project, so fans of the "original" Waterfox resurrected the original project as Waterfox Classic. Where it "comes from" is kind of complicated. AIUI, originally it came here from China - via Russia - but our own @NotHereToPlayGames made extensive improvements, removing telemetry, creating an "unGoogled" version, rebasing to reduce RAM use on XP, etc. It has a pretty good reputation on MSFN.
  7. Good suggestion. Lots of CSP errors helped me figure it out. Github now requires service workers merely to load its CSS! I use CSP to block service workers except when needed for a site to function. Had to add github.com and githubassets.com to the list of exceptions. In some ways I think M$ is worse than Google. Google just provides the rope; M$ actively uses it to try to hang you! Service workers just to load CSS. Sheesh. Could they possibly come up with a more complicated way to perform a simpler task? They must pay their Web developers by the number of lines of code they write!
  8. Well. Setting browser.tabs.remote.autostart to false is the "traditional" (FF vers. 54-67) means of disabling multiprocess mode. In FF 68+ this no longer works (at least not by itself), hence the article I linked to. I can think of a couple of reasons why it may still work in MyPal 68: @feodor2 intentionally re-enabled the setting in MyPal The other settings you listed in your post allow the "disabled" setting to work anyhow. If it's #2, the combination of four settings you listed may work in Firefox itself as well as MyPal 68. Should be worth a try, at least! Of course, if you're lucky enough to have the RAM (physical, or virtual via, say, a fast SSD) you should probably leave e10s enabled for better security and crash resistance. That advice doesn't necessarily apply to Serpent, though, where you have to forcibly enable e10s. (There's a pinned thread explaining how.) Many legacy extensions won't work correctly with e10s enabled, so you need to balance what you gain against what you lose.
  9. ... and/or (as others here have suggested) just switch off multiprocess mode: https://techdows.com/2019/08/multi-process-e10s-can-still-be-disabled-in-firefox-68-or-later-versions-here-is-how.html Mozilla made it harder in FF (and consequently MyPal) 68 and above; you now have to set a Windows environment variable vs. just changing a pref in about:config, but it's still doable. N16s is quite likely correct that forcing single-process mode increases vulnerability to Spectre/Meltdown attacks (and that probably applies to Serpent as much as FF or MyPal); hence the increased difficulty shutting it off. But if the browser hogs too much virtual RAM, it'll start thrashing and end up having to be shut down and restarted, so if you have little physical RAM (regardless of OS) it may be worth the security trade-off. But remember, a major reason for the OP preferring FF-based browsers was to keep as many of his legacy extensions as possible, which I why I suggested Waterfox Classic. If one uses a lot of extensions, switching browser platforms becomes a major hassle.
  10. For legacy extension support, you could try Waterfox Classic. (I've heard good things, but I haven't tried it myself.) For the memory consumption I'd suggest JustOff's "Lull the Tabs" extension, although I suspect it's a legacy extension that'll only run on Waterfox Classic.
  11. You're probably remembering JustOff's "Modify HTTP Response," which is how I initially solved the issue; but I think your user script is a better solution for me since, e.g., ViolentMonkey will run in multiprocess mode, while JustOff's extension won't. BTW has anyone yet noticed similar CSS breakage on GitHub? M$ seems determined to break any browser that won't run on Win 10+. Edit: Well, it works in a clean profile.... I wonder which extension or config setting only breaks GitHub? Edit 2: Well, it's uBO. (Grr.) Strangely, though, when enabled, GitHub breaks - yet uBO doesn't report blocking anything! How am I supposed to tell what to unblock?
  12. DPRK = "Democratic People's Republic of Korea" (known over here as North Korea), correct? AIUI all their Internet connections go through China. All this over a song. Hopefully things won't go that far. Still, it wouldn't hurt to make some contingency plans, just in case. Do we know anyone with the equipment to build Serpent/NM, the expertise to merge GitHub commits into Serpent/NM periodically, and the willingness to respond to issues that occur due to differences between NM and PM, or Serpent and Basilisk? I realize it's a tall order. (@feodor2 would seem an obvious choice, but he has his own geopolitical challenges.) It wouldn't have to be done weekly as @roytam1 has always done, if that makes things easier. It could also help if several folks picked up the pieces. There's no reason one person has to do everything.
  13. Serpent (52 or 55) fares a bit better with outlook.office.com if you enable multiprocess mode. (Can't do that with PM/NM.) Even Serpent will eventually start thrashing though, requiring either a restart, or at least closing and reopening the Outlook tab. Chromium-based browsers work better with Outlook. OTOH, we now have sites that work better on Serpent/NM (see previous page of this thread). So it looks like the ideal of one XP browser for all sites remains a dream.
  14. If so, an obvious thing to try would be Silverlight plus a custom user agent. You could try "Mozilla/5.0 (Windows NT 6.1; rv:45.9) Gecko/20100101 Firefox/45.9", which is what Serpent 52 uses.
  15. Yes, IIRC at the time (Dec. 2021) it was true, and there was some hostility between MCP and users of @roytam1's builds; hence my advice. I wanted to avoid giving MCP's Web site any "clues" (via the user agent string) that one was running an unofficial build. But that's not true any more, so I updated that old post - and thank you for releasing 32-bit builds! Even in the Win 7+ world, 32-bit PCs (and VMs) are occasionally found.
  16. IIRC Widevine 1.4.8 and 1.4.9 are too old and have been blacklisted by Google, so they won't work. Silverlight used to work for Netflix, but Netflix may have stopped supporting it.
  17. You could be right. In theory, I suppose it's possible that some newly-embraced JavaScript feature might confuse the JavaScript parsing code in an old browser like v11 so badly that it crashes rather than just signalling a syntax error. Perhaps one or all of the newly-common assignment operators (??=, &&=, or ||=) throws it for a loop.
  18. Martok is German, it seems; so there shouldn't be a language barrier. Also, just look for BigInt, not Promise.BigInt - BigInt is a data type, not specifically a Promise method. I must admit, I too am a bit puzzled as to why Promise.allSettled returns that message if you block the test script. The Promise class is supported - it's only BigInt that's missing. So I'm guessing the error message is wrong, or at least misleading, and that the true problem is related to needing the BigInt method and type after all. A big(int) problem with polyfilling BigInt, I suspect, would be performance. It might "work" but be too slow to be practical. Depends on just what FritzOS uses BigInts for.
  19. I'm not a JavaScript developer, but to me, both of those functions sound "polyfillable" at first blush. Of course there may be more functions needing to be pollyfilled; it looks to me like the software just checks for "Promise.BigInt" to see if a whole suite of "Promise" functions are implemented (probably because they were all implemented at the same time in Chromium and in Firefox, so checking for any effectively checks for them all). I'd give @martok a few weeks to take a crack at it. He's made great progress in the past few months in getting UXP caught up to Chromium 86 level, but the number of Googlisms to be implemented for full compatibility is evidently quite large.
  20. Oh, thank goodness! You have no idea how often I have the need to watch 3 videos at the same time!! </snark>
  21. It's all over my head. But as long as it works I'm happy. Been kind of quiet here lately....
  22. You might try again with the most recently posted version (2023.05.06) dynamic module imports were added to JS, so there's at least a chance That is incorrect. MITM will trigger a browser warning and DPI cannot decrypt packets encrypted with modern TLS ciphers. Please quit spreading misinformation.
  23. This release fixed Chase.com too! I guess define is defined now....
  24. Finally found the answer: if JS is disabled, HTML within <noscript> tags is executed, and it's properly formatted for our browsers: <noscript><link rel="stylesheet" href="https://support.microsoft.com/SocContent/css" /></noscript> <noscript><link rel="stylesheet" href="https://support.microsoft.com/SocContent/officeShared" /></noscript> <noscript><link rel="stylesheet" href="https://support.microsoft.com/SocContent/articleCss" /></noscript> <noscript><link rel="stylesheet" href="/css/TopNav/top-nav.css?v=y3fVhNR8laayLSfo-P3Q-CBl74RjRTQT6GeXgXCLJoc" /></noscript> <noscript><link rel="stylesheet" href="/css/MeControlCallout/teaching-callout.css?v=690pjf05o15fVEafEpUwgaF8vqVfOkp5wP1Jl9gE99U" /></noscript> <noscript><link rel="stylesheet" href="/css/SearchBox/search-box.css?v=bybwzGBajHicVXspVs540UfV0swW0vCbOmBjBryj9N4" /></noscript> <noscript><link rel="stylesheet" href="/css/sitewide/articleCss-overwrite.css?v=fnFBTMAbM2543ZbkNfpSyKgKIX54uJaVhbeyhZp8Uks" /></noscript> <noscript><link rel="stylesheet" href="/css/glyphs/glyphs.css?v=0Hf7KD3KuarPGDf55g1ICt-VY442qRabqObuIoFb6Bo" /></noscript> <noscript><link rel="stylesheet" href="/css/promotionbanner/promotion-banner.css?v=cAmflE3c6Gw7niTOiMPEie9MY87yDE2mSl3DO7_jZRI" /></noscript> <noscript><link rel="stylesheet" href="/css/ArticleSupportBridge/article-support-bridge.css?v=R_P0TJvD9HoRHQBEdvBR1WhNn7dSbvOYWmVA9taxbpM" /></noscript> <noscript><link rel="stylesheet" href="/css/StickyFeedback/sticky-feedback.css?v=weC9pd2Sy8mevUeLAfDK2H9-VuIOr3CQ8OeyytUpyO0" /></noscript> <noscript><link rel="stylesheet" href="/css/feedback/feedback.css?v=WbIIOpRmxm58LAO8kuENEUDlr_SNhBVl2chWF0yqRcY" /></noscript> Of course disabling JS also disables most of the functionality of the page, so a better solution would be preferred. @UCyborg proposed a solution, but it requires Proxomitron, which in turn requires ProxHTTPSProxy - seems like overkill to me.... So how about using the "Modify HTTP Response" add-on? After considerable frustration, I finally managed to create a filter that seems to work:
  25. Sure enough, Chase lowered the boom last weekend or so, killing Serpent once again. I don't even get a sign-on screen any more. At least MiniBrowser (Cr-87 based) still works (when using a Cr-95 user agent). Edit 360EE v13.0 (Cr-86 based) works too (again with the Cr-95 user agent). FWIW, here's a screen shot of (I think) the relevant portion of St 55's error console: I especially like the error messages that just say Error: Big help.
×
×
  • Create New...