Jump to content

Mathwiz

Member
  • Posts

    1,788
  • Joined

  • Last visited

  • Days Won

    49
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Did you intend to link to an ht-tp instead of to an ht-tpS? I don't think it was @Dave-H's intent; it's just how MSFN works. If you type in a host name starting with "www.", MSFN will automatically make it a link, and add http:// (without the s): <a href="http://www.bbcpa.org.uk" rel="external nofollow">www.bbcpa.org.uk</a> No real harm done, since like most modern sites, bbcpa.org.uk redirects to an https: site immediately.
  2. Yes, that is best, but it's not really practical! Two of anything, even from the same manufacturer purchased at the same store at the same time, won't always be from the same production run. Just try to get the ratings the same; that's often the best you can do.
  3. C'mon; I meant Chrome 110 requires Win 10 OOTB and you know that. 99% of Chrome users wouldn't know how to redirect or stub a Windows API if their lives depended on it. Even Win 7 users turn to Supermium/Thorium where that work has already been done for them. Why do people have to be so argumentative?
  4. I couldn't resist (cue basso profundo voice with reverb): 110 is also the first version to require Win 10. Probably not a coincidence.
  5. I would try to find out what specific commit was added between 3.0a2 and 3.0a3 that caused the problem. Either start with 3.0a2 and add commits or start with 3.0a3 and revert them. You don't have to rebuild and retest after every individual commit - you could take a "binary search" approach, adding or reverting a bundle of commits, building, then going backward or forward depending on whether the problem is there or not. You'll probably also have some idea of which commits are less likely to be related to the problem and which are more likely. It would take a lot of patience but eventually you should be able to identify the commit that causes the problem. Then you could revert that problematic commit in a release version and see what other issues you need to deal with. (Ideally you might even be able to rewrite the changed code in the problematic commit to work correctly with Win 98.) I fear if you try to jump too far ahead, you'll run into so many problems at once, you'll just be overwhelmed and not have any idea where to start making fixes. But if you're patient, you can eventually work your way up to 3.5 or even 3.6. You could probably omit the commit that removed that support, once you find it.
  6. As far as choosing between @roytam1's 32 and 64 bit browser versions goes, my general advice would be to use the "bitness" that matches your hardware. After all, if you have a 64-bit processor, you probably have more RAM anyhow. But not necessarily; I ran my 64-bit PC with only 4 GB until last year. So I usually wasn't giving up much by running 32-bit apps on it. Maybe a little speed, but I scarcely noticed. And browsers can make things more complicated. For example, if you still use old plug-ins, doesn't the "bitness" of the plug-in have to match the "bitness" of the browser? So you may want a 32-bit browser even on a 64-bit PC for plug-in compatibility. (That said, I think that when plug-ins were more of a thing, most were available in both 32 and 64 bit versions.) I'd like to re-frame that a bit. I don't think it's so much that XP (or any OS) just "can't do" certain things; it's more a matter of XP only having "certain ways" to do things, and M$ has added different (arguably better, at least in some cases) ways of doing those things; M$'s development tools now use those new, different ways to do those things, and therefore browsers and other apps built with those tools need access to those new, different ways of doing things. It takes a lot of hard work to bridge the gaps between older OSes, development tools, and application code, as I'm sure @roytam1, @Nicholas McAnespy, and @win32 can all attest; and to be blunt, most developers won't bother. They'll just make it easy on themselves and say "Win 10 required" whether we like it or not.
  7. These days, about the only reason for a SSUAO is to avoid "update your browser" pages. YouTube on Serpent works with a Mo 64 override, so St must support enough "modern" crap for YouTube to work, but any SSUAO with a lower version just gives you the "update your browser" page anyway. I brought up the subject here because Serpent has a built-in SSUAO for YouTube, but it no longer lets YouTube work. I expect @basilisk-dev will update the SSUAO in official Basilisk soon, after which YouTube will again work with both Basilisk and Serpent OOTB, but in the meantime, folks need to put in an updated SSUAO themselves. All of that said, YouTube may not work if you use an override that's "too" new either, since it may then expect, and try to use, modern features that Serpent doesn't support. YouTube seemed to come up OK with version 90, but I didn't test it beyond just seeing the correct page come up.
  8. BTW, if you follow the YouTube link above in St 55, all you get is a "please update your browser" page. The SSUAO built into St 55 for YouTube is for Mo 60. The St 52 version from Feb. 23 is the same, so I suspect they both need updating. The minimum version YouTube now allows appears to be 64 (which is still surprisingly long ago!) So St users should update the general.useragent.override.youtube.com pref to spoof Mo version 64 or later instead of 60.
  9. Another CSS oddity: text at https://freetvnetworks.com/press-releases is barely legible (very light on white, or very dark on black if selected) in St 55. You have to copy and paste to read the text. In Edge it looks like just a normal Web page. There's no clear "cool" CSS factor here that would have required breaking older browsers; the breakage seems to be completely egregious.
  10. Since the question was asked as a "philosophical" one, I think the best answer is here: https://en.wikipedia.org/wiki/Parkinson's_law#First_meaning
  11. That's the advantage of the 64-bit version: it can actually address all the memory it uses (even if most of that memory is virtual/slow). With the 32-bit version, you just run out, whereupon bad things happen. Serpent adds the option of multiprocess mode. The support is primitive and insecure (especially St 52), and a lot of legacy extensions won't work - but it does keep the browser alive and somewhat responsive even when pressed to the limit. And if a crash does happen, it's often (not always) just one tab instead of the whole browser.
  12. If one finds this problem particularly vexing, I think it makes sense to report it to MCP again. If the same problem keeps getting reported, it might get bumped up in priority. Heck, I even identified a probable fix, although porting it to UXP may be tough: ... followed by a rather long digression on just what "upstream" means in the context of UXP....
  13. I think the phrase you intended is "the end is nigh" (sort of archaic English - even native speakers may not be familiar with it) It's fine to post Serpent bug reports here, and this is the correct place for them. It's just that we have no answer for you yet. For the most part, @roytam1 is mainly taking browsers written for Win 7 and making them work with Win XP and Vista. "Upstream" for Serpent is @basilisk-dev, but even he is "downstream" from the UXP project, the browser engine behind Serpent, Basilisk, New Moon 28, Pale Moon, IceApe and others. For what you're asking for, you probably need a UXP fix, which would have to come from Moonchild's team. Moonchild has made it abundantly clear that users of @roytam1's builds are unwelcome in his forums. So to even report the problem, you'd need to: Get your hands on a Win 7 or greater system Reproduce the problem with the latest version of Pale Moon on that system Report the problem on the Pale Moon forum, making no mention of @roytam1, New Moon, Serpent, Win XP, or Vista Be patient because yours is only one of scores of Internet compatibility problems created by the Google/Microsoft/Mozilla goalpost-moving triopoly (and probably not the biggest one).
  14. @Dave-H I think you can just report your own post to have things like that taken care of.
  15. The pixai issue looks like a longstanding Firefox bug, finally fixed in Mo 93. CreateImageBitmap is supposed to take 1, 2, 5, or 6 parameters, but the 2-parameter case throws this error. This appears to be the fix: https://hg.mozilla.org/integration/autoland/rev/426b58b5faa1. Not sure if it can be backported to UXP; we may need to wait on an upstream fix.
  16. Fixed!! AVSForum renders correctly again. I haven't tried it, but suspect that the wrestling forum will be fixed too. Techradar.com is still screwed up though. Clearly a separate issue.
  17. I know this was asked and answered on @roytam1's thread but it makes sense to post that problem and the workaround in this thread too, since others may have the same question and his thread is cluttered with so many unrelated things. So, here's the backspace key fix:
  18. ... or it could be "Modern Firefox" (as distinct from FF versions <= 56) ... or even "Molybdenum" (right below Chromium in the periodic table, so it's similar, but heavier) That's why I left off the z. For me, it has more associations that way. (I like yours too!)
  19. OK, this is off-topic, but things are getting weirder.... There is something on my system blocking me from launching any application named "firefox.exe." I have to rename Firefox to, say, firefoxx.exe for it to run! If I don't rename it, when I try to launch it, it says it doesn't exist! Anyone ever heard of such a thing? Edit 3: OK I found that problem. At one point I was experimenting with trying to run Mo versions >115 with VxKex (a Win 7 kernel extender). I had no luck, so I uninstalled VxKex. Unfortunately, the uninstall did not revert a registry key, so anytime I tried to run firefox.exe, Windows tried to load VxKex and of course, couldn't find it. That was the real missing file. Deleting the registry key fixed it. That said, I can confirm that Mo 68.9 ESR does not render AVSForum correctly. Same bug as Serpent. Clean profile. Edit: OK, getting closer. Mo 78.9 ESR does render AVSForum correctly. So Mozilla's fix was between 68 and 78 (and presumably backported to MyPal). Edit 2: OK, got it. Mo 68.9 ESR doesn't work, but Mo 69 does work. So Mozilla's fix landed in version 69. The date of the fix appears to be circa Oct. 2019. At least, that's the date on all the files in the Mozilla Firefox folder. Hmm.... Perhaps this? The SVG geometry attributes (such as width and height) can now also be defined as CSS properties (Firefox bug 1383650). Edit 4: The fix appears to have landed in official Pale Moon somewhat later: version 29.1.1, dated 26-Mar-2021. Version 29.1.0, dated 1-Mar-2021, does not render AVSForum.com correctly. So I have it narrowed down to one month. Edit 5: On a hunch, I checked @roytam1's St 52 build from March 2021. And sure enough, that same CSS fix landed in the last week of that month. So, I downloaded the St 52 build - and it does render AVSForum correctly! (Well, not quite; as feared, there are other issues, but at least those giant graphics aren't present.) So, it's a regression: been fixed, but somewhere along the line, it broke again. It's getting awfully late here, though. I'm going to bed now.
  20. Well, I tried to narrow it down on the Mozilla side by downloading FF 60 Portable from PortableApps - but I couldn't even get it to start up! I'll keep trying but I'm afraid I'm going to need some help with this.
  21. Well, how about that? I guess it's a recent change on these sites that just started triggering the old bug. But at least now, we have someplace to start looking. So Mozilla must have fixed it somewhere between FFs 53 and 68, and (assuming MyPal 29.3 was based on PM 29.3) it appears MCP incorporated the fix long ago as well; yet somehow the fix still hasn't make it into any of @roytam1's browsers (well, to be fair, no one has tried NM 27 yet). Does that seem reasonable, and does it help us find the issue?
  22. I frequent AVSForum.com, and they made a change today that's resulting in insanity on St 55. See attachment. (There's also a link you can use for testing at the bottom of the image.) That used to be a tiny icon in each post. Now it's giant sized and overlays the post text, making it unreadable. (I already tried a clean profile. No difference.) I've seen this on a few other sites and assume it's some newly-popular CSS Googlism. Anyone know of a workaround, other than "switch to the latest Chrome version?"
  23. The only reason I knew about it is that it came up a few months ago when St started doing it in single-process as well as multiprocess mode, and someone came up with that setting as a workaround and posted it in this thread. I guess St was fixed later on, but the fix only works in single-process mode? Edit: It was actually in the previous "generation" of this thread: https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1228833
  24. There's a fix for that. Set dom.keyboardevent.keypress.dispatch_non_printable_in_content to true in about:config.
  25. Google brought me to that page even before you did, but I swear I tried disabling everything that the article said "safe mode" disabled, and I still couldn't get it to work! BTW there's a contradiction between the St 52 dialog box and the Mozillazine article: The dialog box says custom settings are disabled, the Mozillazine article says they are not. My experience tells me the Mozillazine article is correct, at least for St 55. (Don't know if MCP changed that in UXP.) At any rate, I just gave up. I copied my St 55 profile from work to my home PC with the help of a thumb drive. That fixed several of my problems; e.g., M$'s Windows Update Catalog works again. Chase.com is very cantankerous, but can be made to work with enough patience (although TBH, I usually just go to Edge for that site now). I'll probably never figure out the core issue. I can only tell you it isn't multiprocess mode, nor is it most of my add-ons.
×
×
  • Create New...