Mathwiz

Well, I'm stumped. I just downloaded and installed FF 52.9.1 and Java works for me, the same as in Basilisk. The only thing I did to the new 8u202 install was to copy jp2launcher.exe from the old 8u152 install. Everything else is exactly as installed. Edit: I'm uploading one more .reg file. It's only needed if the Java applet isn't in your control panel. That happened to me after I uninstalled an earlier Java version. javacpl.reg

New versions of jp2launcher don't seem to be compatible with Windows XP. I've been copying jp2launcher.exe from 8u152 and using that. I'm not sure what, if any, functionality I'm losing, but it seems to work.

For New Moon, there were numerous suggestions near the start of this thread - even some logos IIRC. It started to remind me of the running subplot on Star Trek: Voyager where the emergency medical hologram couldn't come up with a name for himself. At the end of the 7-year series, he finally settled on "Joe." If it were me, I'd just pick one of those and be done with it. We all knew New Moon was only supposed to be a temporary name anyway. As for Serpent, MailNews, and Navigator, I'm sure we can come up with something.

Hmm ... I haven't tried it with FF 52.9.1 yet. I'll download it and give it a try. Perhaps Mozilla broke something....

Wasn't @dencorso working on some artwork of his own for Serpent? Perhaps he'd be willing to share

Both of your test sites use certificates signed by untrusted roots, so you have to add them as exceptions in the Java control panel applet. If you do that the CMU applet still has problems, but the other works fine on Roytam1's latest Serpent build: Oracle's "Verify Java Version" page also works. Did I leave something out of those .reg files? You should see something like this in Tools / Add-Ons / Plugins: HTH

That's very strange. Should work straight off in New Moon (XP), just as it does in FF 52 ESR and SeaMonkey. (Basilisk & Serpent require a little extra work, as @VistaLover explained.) Didn't know Silverlight was available on the Pale Moon (Linux) build but if it is, I'd think it would work there too. Maybe the Netflix SSUAO is missing from the Linux build? BTW, Waterfox sounds interesting, but it targets 64-bit Windows 7. I don't know if it's even feasible to recompile it targeting 32-bit XP (or even Vista) instead.

Sorry @VistaLover; I saw your post as soon as I submitted mine. The S/N ratio on this thread seems to have dropped precipitously today for some reason....

Sounds like you need to install Silverlight.

It works for IE8, but if you want it to work with Mozilla-family browsers (FF 52 ESR, NM, Basilisk, SeaMonkey), you need more entries to register Java as an NPAPI plug-in: DTPlugin.reg JavaPlugin.reg

OK, this is strange. I'm at WMP 9; when I try to install WMP10, I get this error dialog: Clicking "Details" brings up this screen: Clicking the link in that brings me to a page that offers me WMP11. I'm guessing I have something installed that makes WMP10 think I have Windows Vista or 2000 or something instead of XP, but these messages give me no clue....

Since the system boots in normal mode, but not safe mode, presumably it's either: A bad driver or service loading in safe mode that isn't loaded in normal mode (shouldn't happen, but something to look for), or A needed driver missing from safe mode. I don't think it'll be easy to troubleshoot.

That sounds like overkill to me. They only signed one DarkMatter certificate; presumably the vast majority of certificates signed by QuoVadis are fine. If DarkMatter makes it into Microsoft's, New Moon's, or Basilisk's trusted root store, you could start deleting their certificates. (If DM makes it into Mozilla's trusted root store, presumably it would have no effect on XP users since we aren't getting updates from Mozilla anymore anyway.)

From the article: On FF 52 and its forks, the Certificates tab is on Advanced preferences, not Privacy or Security preferences. You would then click "View Certificates," select the one(s) to be distrusted, click "Delete or Distrust," and confirm your choices. Of course, if you use @roytam1's builds of New Moon or Basilisk, you'll have to repeat this process each time you update (or else convince him to remove the certificates from his builds preemptively). That's not correct. If that were the case, a big CA like DigiCert could decrypt half the Internet! A root CA generally cannot decrypt traffic of the certificates it signs. Each certificate contains only the public key, not the private key needed for decryption. The real concern is that a root CA could sign certificates of sites that haven't kept their private key secret (due to carelessness, theft, or coercion from the UAE), thus causing Mozilla browsers to trust those sites to be secure, when in fact they are not. I suppose a rogue CA could be an agent of such coercion, but I'd think whistle-blowers working for the certificate owners would soon expose such a scheme. From the EFF article: That's true as far as it goes, but issuing a fraudulent certificate is only part of what's required. It would also be necessary to redirect, say, google.com to a phony website using the fraudulent certificate. That might be doable if, say, your ISP was also compromised, but you're starting to involve a lot of actors to pull off such a scheme. I could see that in China, the UAE, or Saudi Arabia, where all the ISPs are pretty much inherently compromised in order to do business in those countries at all, but it would be a lot harder to pull off in Europe or America.

Good grief. Hyperbole much? An anti-vaxxer? Because, I guess, "everyone knows" computer viruses are still written and tested to target the 3% or so of Windows users still running XP, and "everyone knows" none of those users ever update their AV software What an ignorant statement. That quote wasn't from Matt Tobin, by any chance?

To test what would happen in this situation, I modified the start of @Dave-H's original HTML email to look like this: <BASE HREF=HTTP:><HTML><HEAD><STYLE> BODY {font-family="Arial"} TT {font-family="Courier New"} BLOCKQUOTE.CITE {padding-left:0.5em; margin-left:0; margin-right:0; margin-top:0; margin-bottom:0; border-left:"solid 2";} </STYLE></HEAD> <BODY> <Span CLASS=EUDORAHEADER> Date: Sat, 2 Feb 2019 05:07:12 +0100 (CET)<br> </Span> <Span CLASS=EUDORAHEADER> From: Sky Community &lt;mailer@lithium.com&gt;<br> </Span> <Span CLASS=EUDORAHEADER> To: dave_hawley@yahoo.co.uk<br> </Span> <Span CLASS=EUDORAHEADER> Subject: Sky Community Community: Daily Digest<br> </Span> <br> <div> <br> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head><BASE HREF=HTTPS:> Note two BASE tags: one specifying HTTP: at the very beginning, simulating a prepended tag, and one specifying HTTPS: after the email's <HEAD> tag, as it might be if the email had been sent with a BASE tag included. (Confusingly, Eudora wraps the entire HTML email with its own HTML so it can display the email's headers; thus the first HEAD and BODY tags in the file were added by Eudora and weren't part of the email that Sky sent.) The results were mixed. The email still opened without delay, and the toolkit.css file was still downloaded twice, but this time it was downloaded once using HTTP: and once using HTTPS:. Since the LINK tag near the top of the email explicitly specifies HTTP: and was not redirected, the HTTPS: download was apparently triggered by the @import rule near the bottom of the email. So in this case, the second BASE tag seems to have been used, which is what we want. However, the two @font-face rules near the bottom still triggered (buggy) HTTP: downloads as before. So in these cases, the first BASE tag seems to have been used! Conclusion: prepending <BASE HREF=HTTP:> is probably fine for the vast majority of emails one might receive, but to be safe, one should first scan the email for a BASE tag, then only prepend <BASE HREF=HTTP:> if another BASE tag weren't found.

MC's post is a lot less hostile than Tobin's, and it sort of makes sense: if you're going to develop add-ons for PM, you need to test your add-ons with the "stock" PM build, because that's the version 99% of PM users will use your add-on with. And that, of course, means testing on a Win 7+ system, so that "stock" PM will run on it. It doesn't mean you have to prefer the stock build - only that you have to test with it. It's Tobin who seems to blow a gasket anytime he sees the letters "XP" together. Chill out, man! Whatever your feelings about XP, and however justified you believe them to be, it's not worth having a heart attack over. Let other folks make other choices for their own reasons. Freedom! As for MC's sig, I sort of sympathize; I often find myself rewriting some program that was cloned from another program, and in the rush to get it running, a lot of unneeded code from the "original" source code was left in. Or the programmer used a generic structure better suited to a much more complex program than the one she actually wrote. Either way, you can make the program much easier to read, understand, and debug by removing all that extra code. Where MC takes his sig too far is when he decides to remove functionality just for the sake of removing code, as in his recent decision to remove working WE APIs from Basilisk. Sure, that too can make your program easier to read, understand, and debug; but it also makes your program less useful!

This is typically done using code that looks like this: Content-Type: multipart/related; boundary="------------090303020209010600070908" This is a multi-part message in MIME format. --------------090303020209010600070908 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#ffffff" text="#000000"> <img src="cid:part1.06090408.01060107" alt=""> </body> </html> --------------090303020209010600070908 Content-Type: image/png; name="moz-screenshot.png" Content-Transfer-Encoding: base64 Content-ID: <part1.06090408.01060107> Content-Disposition: inline; filename="moz-screenshot.png" [base64 image data here] In this case, the src attribute of the image tag is a cid: (content ID) reference to the embedded MIME image. It doesn't look like a <base ...> tag would interfere with this method, so it should be safe to use with emails with embedded images, but the only way to be sure is to try it out. Unfortunately, I don't see how this method can be tested by opening the HTML portion in IE8. One would probably need to test the effect of a <base ...> tag on this method in Eudora itself. Another possible problem I can foresee is that there could be a <base ...> tag already in the email. In that case I don't know if prepending another <base ...> tag would just be ignored (which would be OK), or if it would override the one in the email, causing problems.

Just tested, and it works; apparently mshtml.dll is a bit more "forgiving" than the IETF standards supposedly allow. Yes, but that's not really necessary. Due to an IE8 bug, the .woff font files aren't downloaded anyway. Take a look at this ProxHTTPSProxyMII log: [13:23] 021 [BP] "GET http://helpforum.sky.com/html/assets/toolkit.css" 304 - [13:23] 022 [BP] "GET http://helpforum.sky.com/html/assets/toolkit.css" 304 - [13:23] 027 [BP] "GET http://www.sky.com/assets/fonts/sky-medium.woff%22)%20format(%22woff" 301 0 [13:23] 028 [BP] "GET http://www.sky.com/assets/fonts/sky-regular.woff%22)%20format(%22woff" 301 0 [13:23] 026 [BP] "GET http://assets.sky.com/fonts/sky_medium.woff%22)%20format(%22woff%22),%20url(%22//assets.sky.com/fonts/sky_medium.ttf%22)%20format(%22truetype%22),%20url(%22//assets.sky.com/fonts/sky_medium.svg" 404 18 [13:23] 025 [BP] "GET http://assets.sky.com/fonts/sky_regular.woff%22)%20format(%22woff%22),%20url(%22//assets.sky.com/fonts/sky_regular.ttf%22)%20format(%22truetype%22),%20url(%22//assets.sky.com/fontssky_regular.svg" 404 18 [13:23] Using Proxy - http://127.0.0.1:8080 [13:23] 024 [P] "GET https://helpforum.sky.com/i/smilies/16x16_smiley-happy.gif" 200 414 [13:23] Using Proxy - http://127.0.0.1:8080 [13:23] 029 [P] "GET https://www.sky.com/assets/fonts/sky-regular.woff%22)%20format(%22woff" 404 24353 [13:23] Using Proxy - http://127.0.0.1:8080 [13:23] 030 [P] "GET https://www.sky.com/assets/fonts/sky-medium.woff%22)%20format(%22woff" 404 24353 This is with <base href=http:> prepended to Dave-H's "OriginalSource.htm" file, so the protocol-relative URLs use the http: protocol. The first two lines show the toolkit.css being downloaded, twice. (The first download comes from the <link ...> tag in the header of the .htm file; the second comes from the @import rule near the bottom. Toolkit.css only needs to be downloaded once; the @import rule is redundant and unneeded in this particular email.) The next two lines show IE8 trying to download the .woff font files as result of the @font-face rules. Notice the extra garbage following the characters ".woff": %22)%20format(%22woff. This garbage is already preventing the files from downloading. The http: requests are first redirected to https: requests (server returns 301), then retried (see the text at the bottom), at which point the server returns a 404 error for each. Finally, IE8 tries to download both .woff files from a different server (assets.sky.com) specified within toolkit.css itself, and again gets 404 errors due to (a lot of) extra garbage that was added to each file name. In the case of this particular email, this would work because the style sheet was already downloaded by the <link ...> tag. But that may not be true of other emails, so that probably isn't the best option. All things considered, it appears prepending <base href=http:> is the safest option. It prevents the delay without breaking anything that wasn't already broken

They said they were using New Moon; can't be sure, but it seems likely that refers to @roytam1's fork. But then the wrong word was mentioned: WindowsXP. That pretty much cuts off any discussion with Tobin. "New Moon is not Pale Moon!" Geez, Matt, no one said it was; will you help me port my add-ons to PM or not? Does the add-on developer follow this thread? Tobin et al. may not be interested, but I bet folks here would be and many of us could help.

Checked an old Basilisk version and I believe you can restore auto-update of your WE add-ons by changing both prefs above to https://addons.mozilla.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% (Note: the "Get Add-Ons" page will still go to the new Basilisk add-ons site.) It's not a perfect solution: since AMO has removed all legacy add-ons, those won't auto-update. But legacy add-ons aren't getting a lot of updates these days anyhow. The main exception is if you're using the legacy version of uBO like me; hopefully JustOff's uBO Updater should take care of that one.

At the risk of repeating myself: Perhaps these two threads should be merged, since they both seem to cover the same topic.

I like this idea; it seems to fix the delay with minimal fuss. But keep in mind the <base ...> tag must appear between the <head> ... </head> tags, so you can't just prefix it; you need to insert it in the proper place. And some emails may already have a <base ...> tag; you need to insert it only if it doesn't exist. Could scan up to </head> and insert a <base ...> tag in front if none were found

Your reversions seem to be working; thanks! All my add-ons still seem to work (both legacy and WE) at least on Win 7. Will test XP Monday. Hopefully this will be enough for the PM team and they'll finally stop throwing monkey wrenches into Basilisk's ability to support WE add-ons.

I know, but that's not the issue @Dave-H was complaining about. And I don't know of any way to change IE8's behavior without breaking its normal handling of style sheets.