Mathwiz

One problem introduced by the PM team's change is that Basilisk will will now accept add-ons that won't work anymore since it identifies as 52.9.something. So to keep Basilisk from auto-updating legacy add-ons to now-incompatible WE add-ons, the PM team changed the "get add-ons" site from AMO to a new one they're setting up (not ready yet) for Basilisk: http://addons.basilisk-browser.org. But @roytam1's builds retain Basilisk's original WE support , so the change to "get add-ons" keeps any WE add-ons from auto-updating properly. But I think this can be fixed by just changing these about:config prefs: extensions.update.background.url and extensions.update.url, back to addons.mozilla.org.

That sort of sounds like what Google is saying about the API that uBO uses. Of course, restricting that API happens to benefit Google financially, so there's reason to distrust Google on that. But I can't see how removing WE APIs would benefit the PM team. So I have to take MC at his word that he at least believes that. Which makes me wonder: does he have a point? Could a malicious WE add-on do more damage than a malicious legacy add-on? Seems unlikely, but I don't know enough to say for sure. Edit: Even if MC is right, I'd still prefer to take my chances. Just make WE a Boolean in about:config and let users decide for themselves; I wouldn't force my own paranoia on everyone else. (BTW, looks like Schmaif made the same point on PM's forum.) Edit 2: MC's post on the question is quite vague: Point 1 seems to be "we don't intend to expand WEs because we think doing so is unnecessary;" that's fine, but it hardly seems like a reason to remove them. Just leave them as they are. Point 2 is, you can "steal browser data through WEs." But is there data you can steal through WEs that you can't steal through legacy APIs? And my previous comment still stands, in any case: let end-users decide. Default it to off but if folks are willing to take their chances, let them turn it on. The benefits, although limited, still seem to outweigh the risks to me. Point 3 does make a bit of sense to me: even if they never expand WE functionality, it would be irresponsible not to address and fix security bugs in the existing APIs as they are identified. But I can't imagine that implementing security patches to the limited WE APIs in FF 52.9 and Basilisk has been a significant burden to the PM team. Points 4 and 5 seem merely to expand on point 1: it's not practical to expand WEs given the XUL code base, and it's not necessary anyway because the legacy APIs provide all the same functionality. To be blunt, these don't seem like compelling reasons to remove the existing WE functionality, even when taken all together.

The most charitable explanation I can think of is that they're trying everything they can to, uh, "encourage" add-on developers to maintain legacy add-ons, since PM/NM doesn't support WE at all, and the Basilisk support they keep trying to remove is limited. If that's the explanation, though, I think it's a losing battle. Add-on developers aren't going to start maintaining their legacy code again just because of Basilisk, so this would just make Basilisk a less useful FF 52 fork. @roytam1 is correct to revert these changes. It seems unlikely, given how "ideological" MC et al. can be, but maybe they'll figure that out one day, and put the limited WE code from FF 52 back in to not only Basilisk but also PM.

I think the idea is, it's supposed to update you to the next legacy version whenever gorhill releases one. If you just use Basilisk Serpent's own auto-update it will keep updating you to 1.17.4 (Baslisk Serpent 52) or the current WE version (Basilisk Serpent 55), so you just have to turn auto-update off. It may not be needed in PM/NM/Basilisk because those browsers only support legacy add-on versions anyhow, but it's useful in FF 52 ESR or Serpent, where some WE add-ons are also supported.

Thanks. I never could get version 1.6.5 to work; I just had to check and update uBO manually. I hope this version works better.

Yes they're old. Did you pull them from the server for some reason?

Oops: two more just appeared today: Are either of those installed? I'm testing KB4018313 now. Edit: KB4018313 seems safe. But KB4462174 updates mso.dll so it may have the same problem as KB4462157.

Ironically, for me IE8 is the only browser where the Version Information window DID work. Didn't work in Basilisk, Opera 12.18, or IE 11 on Win 7.

Well just uninstall KB4462157 again. You don't need the Japanese calendar in Lithuania do you?

Links are now getting 502 errors

Microsoft's version numbers make no sense. Vista is 6.0, "7" is 6.1, "8" is 6.2, and "8.1" is 6.3. With Win 10, they put the numbers back in sync, so 10 is indeed 10.0. But at present there's not much reason to spoof a later version of Windows than 7, er, 6.1. That may change, though, when Win 7 EOS arrives next year :(

It was removed from their nightly builds a few weeks ago, but this is the first "official" release since that happened. NP; I just switched to @roytam1's build on my Win 7 home system. Everything seems to be working exactly the same.

Thanks; looking at it now. It looks a lot like an old program I used to use for ad-blocking called DNSKong. But it's not a Eudora plug-in, so it doesn't help here. (Incidentally, it's "incontrovertibly" English can really suck at times.) Something must have gotten lost in translation. The only reason I mentioned ad-blocking is that you mentioned: I didn't even know Eudora supported plug-ins! But if it does, your idea sounds good to me. I'm aware of .woff files, and it's true that, as of IE8, mshtml.dll didn't support them: But that's not the only problem with sky.com's HTML emails! To prove this, try editing @Dave-H's original HTML, changing url("//www.sky.com/assets/fonts/sky-regular.woff") format("woff") url("//www.sky.com/assets/fonts/sky-medium.woff") format("woff") to url("//assets.sky.com/fonts/sky_regular.eot?") format("embedded-opentype") url("//assets.sky.com/fonts/sky_medium.eot?") format("embedded-opentype") Those .eot files do exist on sky.com's servers - I checked - and .eot is supported; but IE8 will still open it with a progress bar that "stalls" for several seconds. But if you instead change @import "//helpforum.sky.com/html/assets/toolkit.css" url("//www.sky.com/assets/fonts/sky-regular.woff") url("//www.sky.com/assets/fonts/sky-medium.woff") to @import "https://helpforum.sky.com/html/assets/toolkit.css" url("https://www.sky.com/assets/fonts/sky-regular.woff") url("https://www.sky.com/assets/fonts/sky-medium.woff") merely adding "https:" in front of each double-slash, IE8 will now open the file without the progress bar stalling, even though you loaded unsupported .woff files! Seems obvious that the delay is caused by protocol-relative URLs, not by unsupported font files.

I'd probably be a bit less aggressive in my spoofing. The ESR release of FF should be supported for several more months, so try: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 That way, you won't have to update it every month or two. (You can change 60.0 to 60.5, the latest ESR version, if you wish.) Whatismybrowser.com may not like it, but it should work pretty much everywhere else. But, don't be totally surprised if it still doesn't work with Amazon. There are other ways besides the user agent string that Web sites can use to ferret out your browser version. In the case of Amazon Music, I bet there's third-party DRM code Amazon's looking for, and it may not even be possible to get that code working on FF 52.9.1 or earlier, or any of @roytam1's forks either for the simple reason that it's likely not XP-compatible. DRM is the one area where pretty much every XP-compatible browser disappoints nowadays. But if anyone can do it, I'd bet on @VistaLover

Didn't know plug-ins were an option for Eudora. Sounds like that's the way to go - in fact, while at it, it could even, you know, block ads.... But actually the problems IE8 has with that .css code snippet above go way beyond not being able to handle .woff files. It doesn't even manage to download them because of a bug: it tries to download something named "//www.sky.com/assets/fonts/sky-regular.woff")%20format("woff")" which obviously doesn't exist and would trigger a 404 error - if it used http: or https: to try to download it to start with! (You can prove this by editing the email, adding https: in front of the //'s, and monitoring what IE8 requests when it opens the edited file with ProxHTTPSProxyMII.) But actually it uses file: instead, which is unlikely to work because there's probably no NFS server named www on your home network, and your network probably isn't using a domain of sky.com either....

So go ahead and try the latest version and it should be OK now.

I realize we've gotten rather OT, but I can't help one more observation: Proxomitron and ProxHTTPSProxyMII may see a resurgence among Chromium users (Chrome, Edge, etc.) if Google follows through on their plans to cripple uBlock Origin and similar ad-blocking add-ons. Hey, Google: (Apologies to Queen) Anyhow, back to the question at hand: my original thought was to use Proxomitron to intercept the download of sky.net's toolkit.css and redirect it to a "fixed" version that would load the correct fonts. (I even figured out how to fix the .css myself!) But now I doubt it'll solve @Dave-H's original problem (long delays before the emails appear), because I'm pretty sure it only intercepts http: (and https:, with the help of ProxHTTPSProxyMII) requests, not the UNC network requests those emails cause Trident to attempt.

Actually I think the fault is in neither Eudora nor IE, but in the email! When I open your original email file in IE8, it does display quickly, but if you look at the bottom, there's a "progress bar" showing that it's still trying to download "something." Eventually that process times out, and the font changes somewhat (apparently from Arial to Sky's font). It looks to me like the difference is simply that Eudora waits for IE8's engine to finish rendering the file before it displays it, while IE8 itself displays a "draft" while it waits. It's probably a rather minor difference in how Eudora and IE8 call mshtml.dll (the Trident rendering engine). In the original (unedited) email, there's a second style sheet at the bottom that contains protocol-relative URLs: an @import rule to bring in toolkit.css (which is redundant because it was brought in at the top of the email already), and two @font-face rules that try to download the font files (which are also redundant because toolkit.css already does that). This second style sheet is thus totally redundant and unnecessary, but it appears to be where IE and (probably) Eudora run into trouble. The problem is, the email file was loaded from disk, not downloaded from the Internet, so the protocol IE tries to use is "file://". I (finally) found an explanation of what's going on at Wikipedia. Most of us have seen the file: protocol used with three slashes, to load a file from our own PC into the browser. But there's another, seldom-used variation: "file://hostname/share/path/to/file". The protocol-relative URLs get turned into this variation, so IE interprets www.sky.com and helpforum.sky.com as local network hosts and tries to download files from them using SMB or some such instead of https:. (I suspected this was what was happening last night, but wasn't sure until I did a lot more research today.) The good news is that protocol-relative URLs should become less common as https: becomes more and more standard for all web requests. There's less and less need for URLs that will work with either http: or https:. So I don't think you'll see this problem get worse over time.

The "browser" is actually the Eudora email client - we're trying to debug delays in certain HTML-formatted emails appearing - but I'm guessing it's using Microsoft's rendering engine under the covers. (@Dave-H tried installing Google Chrome Frame and making it the default for IE8, but it didn't affect Eudora.) The HTML source that Dave uploaded (for one of the troublesome emails) contains a few problems for IE8: There are three URLs that start with // instead of https://. According to Google these are "protocol-relative URLs" that point to an address, keeping the current protocol. Unfortunately in an email, there is no current protocol, because the HTML wasn't downloaded from a Web server. IE8 doesn't appear to handle these URLs correctly anyway. This appears to be what causes the delays in the email being displayed. IE8 has a bug in handling @font-face CSS rules that causes it to include extra garbage characters after the URL, so it doesn't find the .woff files even if you fix #1 by adding https: in front of the URLs. The usual workaround for #2 is to append a ? to the font URL, so the extra garbage gets ignored by the Web server. Unfortunately, IE8 doesn't support the .woff font files that these emails use anyway. Ironically, helpforum.sky.com's toolkit.css file specifies .eot fonts (which work in IE8) as well as the same .woff files that don't work, so the .css code in the email (that causes the above problems by trying to load the .woff files again) isn't even needed at all! Unfortunately, toolkit.css repeats IE8 problems #1 and #2, so you continue to get delays even after fixing its URL So lots of little problems, but I think #1 is the important one since it's the one that seems to be slowing everything down. Also, I think IE8 (and presumably Eudora) are misinterpreting those protocol-relative URLs as UNCs and trying to find local network servers called www.sky.com and helpforum.sky.com and since those obviously don't exist, it just sits there until it eventually times out. Anyone know of a way to terminate unwanted UNC requests quickly?

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.

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.)

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.

It's a newer version of it. His is based on v1.4.

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?

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.