Jump to content

Mathwiz

Member
  • Posts

    1,873
  • Joined

  • Last visited

  • Days Won

    51
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Come to think of it, I had a similar experience recently. I had to work on an old XP system that was in bad need of updating. One of the updates I performed was FF; I took it from version 26 up to 52.9.1 - and then I started experiencing freezes just as you describe. Yet, my VM, which also runs XP and uses the Basilisk browser had no such issues. Basilisk is very similar to FF 52, so that didn't seem likely to account for the difference in performance. But now that you mention Google, it occurs to me that my Basilisk installation is equipped with an armada of add-ons that block a lot of Googlebloat. Primarily for privacy, but I bet it also improves performance. I'd probably start with uBlock Origin. I think you can install add-ons in a portable installation, although I haven't tried it myself.
  2. I'll try that tomorrow. But interestingly, I can (sort of) reproduce the problem in IE 11 on Windows 7! If opened in IE, the original source locks up for several seconds and cannot be scrolled. Also, the "loading" progress bar never indicates loading is complete. The edited source works normally. The original source also works if I delete out the code for that second style sheet; by progressively deleting more and more of the second style sheet, the problem does appear to be coming from the downloaded Web fonts. The font files are .WOFF format. Support for .WOFF files was added to IE in IE9; that may explain the warnings in IE8. At this point, my best guess is that Eudora (and IE8) are new enough to understand the @font-face CSS rule, but not the .woff file format (which was invented in 2009). But I don't know why IE 11, which does understand .woff files, also has trouble with your emails. I did run one of sky.com's .woff files through a validator and it found no problems with the file. Edit: Figured out the problem with IE 11. There's a slight syntax error in the URLs for the .woff files: they start with a double slash instead of a single slash. Doesn't bother Basilisk (or FF I presume) but IE 11 can't handle it. Either adding https: in front (making it a full URL) or removing one of the slashes lets the fonts load as intended. Nor am I sure what can be done to fix it yet. Perhaps merely blocking the download of .woff files would be good enough. (That could be done with the Proxomitron, which ProxHTTPSProxyMII was written to work with.)
  3. Well, I don't see anything obvious.... Editing the message seems to have reformatted the HTML a bit and removed some redundant tags; in the original source, an entire HTML document - presumably the original email - is embedded within another HTML document - presumably one Eudora builds to display the email headers. Thus there are redundant <html>, <head>, and <body> tags, as well as a <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> that identifies the HTML version, which are in the original email but not the edited version. Both versions download two images from helpforum.sky.com (the logo and the happy face), and a style sheet; but at the end of the original source there's another complex style sheet that's missing from the edited version. That style sheet downloads a couple of fonts from www.sky.com; that probably explains the slightly different font weights you see between the two versions. I suppose downloading those fonts might be what's causing the delay, but both fonts downloaded quickly when I pasted their URLs into my browser. The only other difference I saw was that your cut-and-paste operation moved the "sky community" logo outside the hyperlink, so in the edited version you can't click on it to go to helpforum.sky.com in your browser.
  4. It's a newer version of it. His is based on v1.4.
  5. Seems likely Eudora is trying to download the logo from a Web server somewhere, which accepts the HTTP request but doesn't respond (not even with 404 Not Found), so Eudora has to wait for the connection to time out. Not sure why the requests aren't showing up in the ProxHTTPSProxyMII window though. Have you tried setting its logging to DEBUG level in config.ini? Interestingly, both www.eudora.com and www.eudora.org redirect here: https://www.computerhistory.org/atchm/the-eudora-email-client-source-code/ Apparently Qualcomm has released the Eudora 7.1 source code (BSD license). I thought about downloading it myself, just to search for the logo URL, but it's HUGE: 458 MB of C++ code according to the page at the link above. Maybe one of the other regulars here is willing to give it a go?
  6. Sounds to me like Eudora is trying to connect to "something," and timing out. When it times out it closes the connection (producing the above error) and goes ahead with displaying the email. We need a way to figure out what server Eudora is trying to contact.
  7. New one today: KB4462172 File Oart.dll was updated. Seems harmless, albeit probably pointless since KB4462157 can't be installed on XP.
  8. Come to think of it, I remember @VistaLover mentioning that too. (The drawback is, you have to redo that for every new update.) But I rolled back to legacy for other reasons anyway.
  9. The quickest solution is probably ProxHTTPSProxyMII v1.5: Works for IE8 and Chrome. @Thomas S. has made an updated version of the above; PM him if interested.
  10. 1.17.4 is also the latest for @roytam1's Basilisk 52 build. (Basilisk 55 went up to 1.18.2 last I checked.) But I downgraded to 1.16.4.7 (for reasons I explained in the New Moon thread). I also had to disable automatic updates to keep Basilisk from updating uBO again. I'll give 1.16.4.8 a try. Edit: Looks like the only difference is the addition of Spanish. Everything else still working as before AFAICS.
  11. How do you enable WebGL compatibility? I only see gecko & firefox
  12. New version (1.5) of ProxHTTPSProxyMII released by the original author: The full version, compiled with Python 3.4, is at http://jjoe.proxfilter.net/ProxHTTPSProxyMII/files/ProxHTTPSProxyMII 1.5 34cx_freeze5.0.1urllib3v1.22Win32OpenSSL_Light-1_0_2o-1_1_0h.zip. (Whew; what a file name) I'm running it now; seems to work fine. I can access Wikipedia from IE8. (I know; why would you want to? But it's a good test due to Wikipedia's ECC cert. )
  13. So you need a legal bcrypt.dll that runs on XP. ReactOS? Wine?
  14. Have you tried YouTube without the spoof? Since it thinks you're Chromium 71 it may send incompatible code.
  15. The versions of ProxHTTPSProxyMII we've been using all derive from version 1.4 of the original, but apparently it's still being maintained by the original author, and last June a version 1.5 was released with some changes: Edit: The link @-SnooPY- provided had Python code only. I guess that's what @-SnooPY- is trying to get working with Python 3.7. The full version, compiled with Python 3.4, is at http://jjoe.proxfilter.net/ProxHTTPSProxyMII/files/ProxHTTPSProxyMII 1.5 34cx_freeze5.0.1urllib3v1.22Win32OpenSSL_Light-1_0_2o-1_1_0h.zip. (Whew; what a file name)
  16. Darn: WebRTC option still greyed out on uBO 1.18.2 on Basilisk 55. Apparently, enabling that option requires a FF version > 53, which makes it a no-go for XP. I'm switching to the legacy version of uBO in Basilisk 55 too....
  17. Evidently it works; all my WE add-ons are still enabled.
  18. I'll have to try the WE version of uBO on Basilisk 55 just to see what happens.
  19. Cool! Keeping WE was as simple as specifying a build option?
  20. That put my mind somewhat at ease, although I'm not directly affected since I don't use modern Firefox anyway. BTW, I think this statement was wrong: As you know, I just switched to the legacy version of uBO because it has a capability the WE version doesn't have: blocking WebRTC from leaking your local IP address. Of course the WE version probably has some capabilities the legacy version lacks too, but it's not as clear-cut as Handsome_Jack implied.
  21. I don't think folks should have to click through to see what's being discussed, so TL;DR: So, it's still just a proposal, but I'd bet on more Chromium forks like Advanced Chrome if it goes through. And Mozilla following suit would be MC's wet dream. The popularity of PM & especially Basilisk would increase tenfold overnight. But since neither Chrome nor FF supports XP or Vista any more, none of this matters to us anyway.
  22. Try the following registry entries: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000
  23. So for WebRTC protection, I too ended up going with uBO 1.16.4.7, for the following reasons: Been using uBO anyway Gorhill still maintaining the legacy version (1.16.4.7 was released 2 days ago) No need for separate WebRTC add-on No need to modify anything to allow installation (which would need to be redone for each update) No need to disable WebRTC entirely in about:config Edit: I should have known this, but didn't realize it until now. If you downgrade to 1.16.4.7 you need to turn off automatic updates, or Basilisk will just re-update you to 1.17.4.
  24. OK.... Hid that one too....
×
×
  • Create New...