Jump to content

Mathwiz

Member
  • Posts

    1,838
  • Joined

  • Last visited

  • Days Won

    50
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Will we 360EE users have a fix for the libwebp vulnerability? I suspect not. The "big boys" are only fixing the latest versions of their browsers - and they all require Win 10 now. Edit: Despite lack of official support, this vulnerability is so bad that Edge and FF (and Chrome, I suspect) have published fixed versions of their last Win 7/8/8.1 versions. Thorium (for Win 7/8/8.1) will probably get a fix, but XP/Vista users are SOL. Edit: NHTPG noted that Supermium runs on Vista and is at the current version (117) so Vista users will probably get a fix too. Edit 2: Sure enough, version 118 is out now with the fix. There's no "unGoogled" version of either browser yet, though. An alternative might be to disable WebP images in the browser entirely. That's possible in FF but not in Chromium; WebP is Google's own creation (and not a bad format, despite this vulnerability in their decoder). And I bet a lot of Web sites would look terrible without WebP image support anyhow! A better solution would be to scan downloaded WebP images and block any that would overflow the buffer. That would slow things down, but wouldn't block legit WebP images. Maybe Proxomitron could be leveraged somehow?
  2. Hmm ... looks like GIMP is likely affected too - I'd better check for an update. BTW the above link does not open correctly in my browser (St 55). St 52 didn't work for me either. I just get a pageful of Javascript source code in both browsers.
  3. It does work with St; I use it myself. PM/NM will require the legacy version, of course. Straw man! You know that's not the same thing. The idle loop is there because the CPU has to be doing something even when there's literally nothing to do, so the lowest-priority process is a simple loop that doesn't take cycles from anything else running. Your Web browser isn't the lowest-priority process in the system! Even if animations are (hopefully) the lowest-priority task within the Web browser, they still take CPU cycles away from non-browser tasks. Your computer does more than just run a Web browser, right? Chromium can get around that (don't know if it does, but it can) by creating a low-priority process for animations, but FF 52/53-based browsers like PM and@roytam1's are stuck. Even e10s doesn't create a separate, low-priority "animations" process. To be fair, there are negative "side effects" from setting layout.css.animation.enabled to false, but they're mostly minor. Spinning "wheels of death" don't spin while you wait, for instance. I can live with that.
  4. Although I'm not very concerned about the lack of sec fixes, for me the bigger concern is, as we go forward, further breakages like the one in the 20230902 build. Since e10s is a "relic" that hasn't been part of "official" UXP in ages, MCP obviously won't be testing their changes in that environment! This time, it was easy to revert the change that broke e10s. Next time we might not be so lucky, and I'll have to start running the 64-bit version so I can have one gargantuan process....
  5. Good to learn that GPU acceleration works, but "little below 70%" is still super high for something purely cosmetic! Luckily we now have: To clarify, the new prefs @roytam1 added are: layout.css.animation-long-names.enabled layout.css.transition-long-names.enabled It appears these prefs are the equivalent of MCP's prefs (setting them false breaks MSFN), and the prefs with the original names: layout.css.animation.enabled layout.css.transition.enabled ... are @roytam1's from the 20230825 version of Serpent that have a narrower effect (MSFN basically OK). So good work! Now we can have either, or neither, as preferred (which is what prefs are supposed to be)!
  6. Well, I stayed on 20230825 for reasons unrelated to e10s, so I didn't realize that e10s is essentially broken in 20230902 - at least if you want to upload files. I thought it was specific to the web site @Mehmed mentioned initially - and I thought that site was broken on all browser versions if e10s was active! I did suspect @roytam1's fix would cause a memory leak - I didn't realize he's reverting not only his own fix but also the change that made a fix necessary in the first place (well, since I didn't realize the breakage was specific to 20230902). Moonchild has strong opinions, one of which is that e10s is always a bad idea. And, to be fair to him, it's not particularly necessary if you're running 64-bit code on a 64-bit OS, where your address space is essentially unlimited. But I suspect most users of @roytam1's browsers are running the 32-bit versions, and e10s is much more helpful in that environment, at least if you have lots of RAM and/or a fast swapfile device. (It does have its downsides though.)
  7. Of course MCP hasn't bothered porting e10s fixes to UXP. It would obviously be a pointless waste of time for them to do so, since neither Pale Moon nor official Basilisk (no longer a MCP property, but still dependent on UXP) supports e10s. As a satisfied e10s user, I'm not terribly worried about the security concerns; UXP browsers using e10s are a pretty tiny target for hackers! But that (and Mypal 68) aside, @Mehmed appears to have discovered the first Web page that out-and-out crashes UXP under e10s. @roytam1's unsuccessful fix attempt suggests to me that the Web site is causing UXP code to run that destroys an object in use by other processes. I'm guessing a true fix would require maintaining a count of processes using the object in question so that only the final process calling that code would actually destroy the object. That may require more extensive surgery on UXP than we were hoping for. As a workaround, since the problem currently affects only a single Web site, how about a bookmarklet? It's quite a bit above my level of expertise, but the Classic Add-Ons Archive has some Javascript code (intended for Waterfox Classic) that I think could be borrowed to open the problem Web site in a single-process browser instance.
  8. Thank you! I think you got it right, and upstream got it wrong, in this case. I wouldn't be surprised if they get complaints, since users can't reasonably set to false the way they implemented it. What's the point of a pref you can't change?
  9. But - but - but GitHub's site was written by professional Web developers! It has all those CPU-gobbling transitions! How could it not be interesting? Yes It has become a self-licking ice cream cone! Look at the massive boost in PC horsepower since 1980 or so. Back then, a 10 MB HDD was top-of-the line; today, it's more like 10 TB - a millionfold increase. RAM on the original IBM PC topped out at 640 kB, and some joker named Bill Gates said that was all anyone would ever need. Now, even a modest PC comes with maybe 8 GB - a several-thousandfold increase. The CPU clock in the original IBM PC ran at under 5 MHz; now CPUs are clocked at around 2 GHz - nearly a thousandfold increase. But are you getting a thousand times more work done on your PC now than you did 40 years ago? Is it 1000x faster or more responsive? Of course not! You have gotten more productive, but by nowhere near that much. I'd guesstimate that I'm about 10x more productive on today's PCs than I was back then. Maybe some of you are 20x or even 30x as productive, but nobody is 1000x more productive! So where did all that extra horsepower go? It's as if we took a cheap automobile and replaced the 4-cylinder engine with a nuclear thermal rocket - yet it only accelerates a little bit faster than before!
  10. Yes I do, but I never needed service workers for MSFN before Again, yes I do, but those prefs exist in the 2023.08.25 version too. So I will test these suggestions, but even if enabling service workers and/or animations works around the problem, what changed between 2023.08.25 and 2023.09.01 that caused this problem to surface? Edit: layout.css.animation.enabled was the one. Enabling service workers and/or layout.css.transition.enabled had no effect. I still want to know why it's necessary in the current St 55 version but not the previous one. Edit 2: OK, I must be losing my mind! In the 2023.09.01 changelog, there's this entry: - Issue #2293 - Add preferences to disable CSS animation/transition props. (f4cc47c049) ... but I know those prefs appeared in the 2023.08.25 version and they worked in terms of stopping the CPU-hogging animations we were all up in arms about a couple of weeks ago, but didn't break MSFN: I tested them myself! Nothing makes any sense any more.
  11. @roytam1: newest (9/1) version of St 55 has an annoying problem on MSFN: pop-up windows won't go away. Examples: Click the + sign on any post. A pop-up with a button reading "Quote 1 post" appears. Click that button: the pop-up remains on screen but the text changes to "Quote 0 posts." Click the number next to a "liked" post to see who "liked" it. A pop-up appears listing the "likers." Click the X to close it: it doesn't close. You must refresh to remove the pop-up. On the topics list page, hover over a topic. A pop-up appears showing the first post. Move the mouse: the pop-up doesn't fade away. Again, you must refresh the page to remove it. The 8/25 version of St 55 works correctly in these cases, so I'll be sticking with the 8/25 version for now.
  12. Folks, be nice. The author clearly isn't a professional Web developer, and for that we should be grateful! A Web site can still be useful without all that "flash" and "sizzle" and the CPU/GPU-sucking CSS and JavaScript that goes along with it. (I agree with NHTPG about the ridiculous anti-Wikipedia rant, though.)
  13. Don't know of any (other than test Web sites) myself, but HEVC is the video compression algorithm used by ATSC 3.0 (an over-the-air TV standard used in North America and South Korea). So it's a good bet HEVC will be coming to the Web soon as well. So HEVC support in UXP isn't an urgent need, but wouldn't it be good to get ahead of an upcoming standard for a change, instead of waiting for folks to start complaining that they can't watch videos on some Web site?
  14. Probably not very useful, but better than a 404: St 55 goes to https://addons.mozilla.org/en-US/firefox/collections/4757633/webdeveloper/ which is still active. I'm sure St 52 could be changed to point there - or to get the URL from a pref and default the pref to the above URL.
  15. Do you know how much the last computer I bought cost me? $10.41 in 2020. It was a Raspberry Pi 3B+. Heck, the cost of a keyboard, monitor and mouse (especially the monitor) would dwarf the cost of the computer itself. It was so cheap I "splurged" and got a case for it for another $11. Sure, it doesn't run Windows - it runs (free) Linux - but it's amazingly powerful! So I really think the cost of new hardware is a complete red herring. The real reason folks stick with their "favorite" Windows, be it 7, Vista, XP, or even 2000, is that M$ has made it a royal PITA to "upgrade." First, you usually need a new PC. You might be able to upgrade one time "in place," say, from Windows 7 to 8, but why would you want to? And to go from 7 to 10, you're probably gonna need a new PC. Then, how do you get all your apps and everything off your old PC and onto your new one? Gone are the 9x days when you could just pull the HDD out of the old PC. plunk it into the new one, and install the new Windows version. In fact, in all likelihood, the new PC won't even run the old Windows version! No, instead you need to buy special software to move everything over - and even then, it usually fails on at least a few of your apps. And even if you get all that done successfully, M$ always manages to screw up something that was working fine in the previous Windows version. Did anyone really like the "Metro" UI that came with Win 8? Heck, you can make Win 7 look just like Win 98 if you want, so why did M$ forget that lesson and make that Metro monstrosity mandatory on Win 8? And with Win 10/11, it's the same story: you're gonna get the new UI whether you like it or not. Not to mention M$ dropping WMC with Win 10 (yes, I'm aware there's an unofficial way to keep it during an upgrade). To be blunt, if you're gonna "upgrade" to Win 10/11, you ought to at least consider a Mac or Linux. Both offer a Windows environment that's probably as easy to port your apps to as the latest/"greatest" Windows.
  16. I tried 360EE and sure enough, the HEVC clips do play, but I have an older APU without built-in HEVC decoding, so the video playback is unsatisfactorily choppy. So even if it worked in UXP, you'd probably need a reasonably up-to-date graphics card for it to be worthwhile. OT: I suspect that's a deal-breaker for ATSC 3.0 on this old PC, unless I buy a new graphics card for it. (And the card would need Win 7 drivers, so it couldn't be too new....)
  17. (Showing my ignorance here.) I would naively think that on Vista+, WMF would support HEVC. (I suppose you'd have to install a codec for it first.) But evidently there's more to it than that. Wouldn't help XP users anyway.
  18. https://tools.woolyss.com/html5-audio-video-tester/?u=woolyss.com/f/caminandes-2-gran-dillama-x65-aac.mp4 https://tools.woolyss.com/html5-audio-video-tester/?u=woolyss.com/f/caminandes-3-llamigos-x265-aac.mp4
  19. As I also reported in @roytam1's browser thread, for the second time this year Chase.com has upped their minimum required browser version. The first time, they raised it to Chrome 95, but our browsers based on Chromium 86/87 still work as long as you override the user agent. Now, they're raising it again. A trial-and-error search indicates the new requirement will be Chrome 109. That cuts out my old Android 6 phone, which topped out at Chrome 106. But they haven't done it yet (it's just a warning at this point), so I can't yet say whether our browsers will fail or work if we override the user agent.
  20. Is that on your "loved" St55 ? Because St52 (2023-07-31) (32-bit) has below SSUAO: general.useragent.override.chase.com;Mozilla/5.0 (%OS_SLICE% rv:112.0) Gecko/20100101 Firefox/112.0 I don't think it's a 52 v. 55 thing; it's just a matter of how obsessively you install @roytam1's weekly updates. The Aug. 18 version of St 55 spoofs FF 102, but surprisingly the July 28 version specified FF 112. Both work, but produce a warning, on the current Chase site. Edit: I see you discovered the same weirdness in St 52 almost a week ago. So far, so good; but I don't expect that situation to continue for long. From the linked PM article: Actually, from the examples the poster gave, I don't think that's the whole story, since she reported: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.2 Firefox/102.0 PaleMoo/32.2.0 did not work, while Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.2 Firefox/102.0 PaleMoo32.2.0 did work. The only difference was the slash between "PaleMoo" and "32.2.0," so it's not at all clear to me what Chase is doing.
  21. Noticed a couple of things there: first, But later: So I guess you were one of the "lucky" ones that got "selected" well before the end of 2023. Second, here's the excuse they gave: I don't think for a minute that Micro$oft cares one bit about "protecting developers." If that were the case, they could've made this optional, perhaps with a banner on your page so visitors would know whether you'd enabled 2FA. No, I think this has to be about protecting Micro$oft. I think they're worried that someone will upload bad software (buggy, or conceivably even malware) to GitHub, the guilty party will claim that their account was hacked, and Micro$oft will get sued for lax security. Making 2FA mandatory is intended to remove the "my account was hacked" excuse. Which, I suppose, is fine; if that's what they feel they have to do to protect themselves from legal liability, so be it. I just wish they'd drop the "we're trying to protect you" malarkey. Third, I see they do support 2FA via SMS, but.... I don't know why it doesn't provide "the same level" of protection, but that makes me worry that other sites requiring 2FA will soon stop supporting SMS as well, so even non-GitHub users may soon find themselves in the same boat. So thank you for the advice on KeePass. XP/Vista users may soon need it, GitHub or no GitHub! Seriously? I couldn't possibly care less how Mozilla prefers I abbreviate the name of their product. It's clear what "FF" means in context! But at least they didn't suggest "F5x"....
  22. Well, that didn't last long! Built-in SSUAO pretends to be FF 102; guess that's no longer good enough! Edit: FF 113 is the minimum to avoid the warning, but I wonder what new Googlisms (or conceivably Mozilla-isms, but I'm still betting on the former) will be needed in order to access chase.com, once "soon" arrives?
  23. Well, there's 2FA, and there's intentionally annoying 2FA. Only form of 2FA I've ever used is the kind where you log in and they send you a OTP, via either text (so you need the cell phone it gets sent to - doesn't have to be a smart phone though) or email (so you need to prove you have access to your email account). Those aren't too bad, and a lot of sites will set a browser cookie so you don't have to do it again, at least for a while. No "special app" needed! But from what you're saying, it sounds like GitHub will require a special app just to generate the OTP. I can't see any reason for such a requirement, other than to discourage folks from logging into GitHub unless they have to! 30 seconds to key the darn thing in sounds awfully tight too. (That may be the reason you need a special app - text or email would often take longer than that.) GitHub isn't a banking or financial site - or even your email account! Why are they doing this?
×
×
  • Create New...