Mathwiz

I also had browser.tabs.remote.autostart.2 user set to "true," on two different installations of Serpent. I suspect I inadvertently copied it from my Firefox 52 profile. I reset it on both Serpent installations; resetting it seems to have had no effect, so I don't know why it was ever there in the first place.

I rather expected that. Without WE API support (which PM never had and was infamously removed from Basilisk), there's no way to write many complex add-ons in a way that will work with e10s. (AIUI that's one of the reasons the WE API set was created in the first place.) Thus, e10s is less useful with Basilisk than Serpent (which retains WE APIs), so it makes sense that MCP would want to yank out that code too. We might prevail on @roytam1 to retain e10s in Serpent, as he did with WE APIs, but the former is less important than the latter. E10s mostly just helps to avoid running out of RAM when opening lots of tabs in the 32-bit version of FF/Serpent. (It also makes the browser a bit more responsive, but that may not make enough difference to even notice.) My off-hand guess would be that you have an add-on that's incompatible with e10s, so the highlighted pref is preventing it from starting. AIUI, WE add-ons are inherently compatible, but legacy add-ons are only compatible under certain conditions, so the developer has to explicitly flag e10s-compatible legacy add-ons. You could flip the pref to false just to see - it's possible the "incompatible" add-on(s) are actually e10s-compatible; but weren't tested under e10s, so the developer(s) didn't flag them as such. Or the whole thing could come crashing down. If that happens you'll have to start in safe mode and flip the pref back to true. Thanks! I expected my post to be a one-off, as I only meant to mention an alternative for folks wanting a way around the 2GB barrier but worried about Chrome 360 spying on them - but the post sort of took on a life of its own! Sometimes that happens, I guess....

Having tried both, I agree v0.1.1 is more useful, so installing that version and turning off updates makes good sense. (I do the same with uBO so I can stay on the legacy version.) The only reason I brought it up is that I don't think it has anything to do with unsupported WE APIs in Serpent: Whether or not Tab Tally works as the developer intended, it works the same way in Serpent and Firefox. In fact, in my experience, compatibility between FF 52 and Serpent 52 is excellent. If an add-on works in Firefox, it's all but certain to work in Serpent too. So, I don't generally fear add-on updates from AMO, and only turn updates off if I have a particular reason to stay on an old version of an add-on, as with Tab Tally and uBO.

You can force "multiprocess mode" (aka "e10s") in Firefox 52 or @roytam1's Serpent 52 and 55, by creating the Boolean preference browser.tabs.remote.force-enable and setting it to true. This splits Firefox or Serpent into two processes. To allow more than two, set dom.ipc.processCount to a value greater than one (i.e., setting it to 2 allows 3 processes, etc.) Don't try this in New Moon, though; it will crash! It doesn't work in BNavigator or IceApe either; setting the above preference makes it appear to work in about:support, but Windows Task Manager nevertheless shows only one task no matter how many tabs are open. Edit: Summarizing what was discovered below, this preference is required to enable e10s (multiprocess mode) in FF 52 on Windows XP. But with later Windows versions, or some other FF forks on XP (confirmed with Serpent 55), you can instead use the preferences @VistaLover recommends in the next post: toggle browser.tabs.remote.autostart from false to true, and if necessary (due to add-ons flagged as incompatible with e10s), toggle extensions.e10sBlocksEnabling from true to false. In Chrome, each tab is a separate process; but in FF the maximum number of processes is limited by that preference. If you open more tabs than that value, tabs will begin to share processes vs. creating new processes.

Works in IE 11 too. I haven't tested a Quantum FF version but I bet it works there too. MDN may have the explanation: That would explain why it fails specifically on our UXP-based browsers. I agree someone needs to confirm this with official PM/Basilisk on Win 7+ and report it to MCP. (And this should go without saying, but do not mention New Moon, Serpent, XP, or even Vista, as MCP will simply blame @roytam1's "inferior" code, then Matt will come here and hassle him about "misrepresenting" his builds. We don't want to go through that yet again.) This particular issue is minor, but it's the sort of thing that will continue to bedevil the UXP platform as Javascript continues to evolve.

That's what it looks like before you click the magnifying glass. When you click it, you get the problem @luweitest described in FF 52, St 52, and St 55.

I'm not sure that's right. I just loaded Tab Tally v.1.4.0 in FF 52, St 52, and St 55, and AFAICS it works identically in all three versions. I don't think it works correctly; the total number of tabs doesn't update when you close a tab until you click it. But at least it messes up the same way in FF 52 as in Serpent. I suspect it's just buggy in older FF versions, and that affects Serpent as well as "genuine" FF. Also, according to the page above, the change in v1.4.0 was to expand compatibility down to FF 42 and above. (V1.3.0 worked in FF 48 and above.) I find it hard to believe Serpent 52 lacks WE APIs that were present in FF 42!

First try a SSUAO to spoof FF 52: something like general.useragent.override.earthcam.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.9) Gecko/20100101 Firefox/52.9 It could be the same problem as Instagram. NM 28 and Serpent 52 spoof FF 60.9, but don't support some of FF 60.9's Javascript, so a few sites see the "60.9," feed NM/Serpent incompatible Javascript, and break. Moebius works because it spoofs FF 55, which predates Quantum. If that doesn't work, try the previous version of NM 28; it's not uncommon for one of the weekly updates to break some sites. If that's the problem, it'll probably be fixed by next week.

Disappointing if true (and I have no reason to doubt it), but not surprising; I'm surprised Amazon has supported Silverlight even this long. (OTOH, Netflix apparently still supports it ) That essentially kills Amazon Prime on XP, unless a newer Chrome (maybe that Chrome 360?) can support the new Widevine 1.4.10 when it comes out. Thanks; I added that to my file. (Don't forget to enable Flash if, like me, you normally keep it disabled!) Try general.useragent.override.netflix.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Firefox/45.9 and general.useragent.override.netflximg.net;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Firefox/45.9 You need both. (And of course, you need to have Silverlight installed.)

You're right, of course - I should have tested that - although it "breaks" in a smarter way than I expected. For the uninitiated: "Shell integration" occurs when you make NM your default browser: it updates several registry entries so you can open links, .htm or .html files just by entering them at a command line, the Run... dialog box, double-clicking a file or Internet shortcut; that sort of thing. It's not something I (or, I suspect, most folks) do a lot, but it does come in handy, particularly when clicking a link in an email, Excel/Word doc, etc. So when you said that, I thought "oops; MCP hard-coded 'palemoon.exe' as the program name, so it will idiotically write registry keys to launch 'palemoon.exe' even if it's been renamed, causing all of the above functions to break." As it turns out, though, it's a bit smarter than that: it simply won't make itself your default browser if it isn't named palemoon.exe! You can click on the "Make New Moon my default browser" button - it's not disabled - but it doesn't do anything. Your previous default browser remains the default. Of course, if they made it smart enough to do that, they could've made it smart enough to write registry keys with the actual renamed file; alas, they didn't make it quite that smart. Oh, well; you can still name the folder anything you want; NM's smart enough to write the correct path name, at least. (I tested that and it does work.)

A quick test indicates that you can rename the .exe file post-build (from, e.g., palemoon.exe to New Moon.exe) and it still works fine. Of course that goes for the folder name in the .7z archive too. I realize that may not be enough.* There are a couple more files in the archive that include "palemoon" in their names; those probably cannot be renamed unless the code is changed. Same goes for the default profile folder names, not to mention the numerous built-in default preferences that include the words Pale Moon. *After the latest blow-up, we have to consider the possibility that nothing you do will ever be enough. If anyone who has ever downloaded your code ever contacts the Pale Moon team for help, it seems you'll immediately be accused of "misrepresenting" your builds as theirs, and nastiness and threats will ensue no matter how many disclaimers you post. But at least this is something that can be done easily post-build; or it could even be added to @i430VX's installer!

With that thought in mind, I created a myuseragents.js file. I started with the built-in prefs from NM 28 and unbranded them (except in a few cases where a PaleMoon user agent was required to avoid stupid "out-of-date FF version" messages - obviously if a Web site works under PM/NM, it should work under FF 52 as well, but some Webmasters don't seem to understand this), then added a few of my own. These show up in about:config as "default" preferences; of course you can override any of them with your own user-set preferences as needed or desired. They should make a good starting point for FF 52 or any of its derivatives, but I haven't tested most of the ones from NM (I went on the assumption that MCP knew what they were doing when they created them) so feel free to post any needed corrections. Edit: Added (hopefully) future-proofing SSUAOs for instagram.com (FF 56, courtesy @mixit) and github.com (native Basilisk, courtesy @VistaLover and @mixit again). Future-proofing is by nature an imprecise art, but these stand the best chance of resisting future breakage IMO. myuseragents.js

These prefs are only used if you don't have a general.useragent.override configured. They are used to build up the user agent string from its components. For me, it's easier to just specify a general.useragent.override string.

Mine too. In fact it looks like the errors go all the back to Jan 22 on mine, although @heinoganda's definitions updater kept it up-to-date anyway.

This is a long shot, but could 4494528 have changed how the installer detects XP, so now it thinks it's running on Vista+ and makes a Vista-specific call? They bumped the msi.dll version from 4.5.6002 to 4.5.6003; maybe if it sees anything > 4.5.6002 it assumes Vista. That'd be a stupid thing for Canon to do but I've seen weirder code. Have you tried removing 4494528 and seeing if the printer driver will then install? If so, it's easy enough to reinstall 4494528 afterwards.

Well, at least we know it's possible to port Chromium 69 to XP, even if it takes a boatload of manual work to do it. @FranceBB's getting frustrated with a similar project, but he showed that even one person can make a lot of progress. As for the HTML5test, most of the stuff it tests for is good, so for the most part, higher scores are still better. Just not in every case. As with any benchmark, you should read the results carefully and not obsess too much over an overall "score."

Nor do New Moon and Serpent - except Moebius (Serpent 55). Need to toggle the dom.serviceWorkers.enabled pref to false, or use the uBO rule, in that version.

A word of caution about HTML5test.com: Many of the points awarded by that site are for features that have privacy and/or security concerns: e.g., 15 points if your browser supports geolocation; 10 points for "service workers," a point for the "ping" attribute, etc. A very high score may not be the best news about your browser.

It needs to be general.useragent.override.whatismybrowser.com. Is that just a typo in your post, or did you enter it into about:config that way?

Seems to be in the same place in NM28: C:\Program Files\palemoonx86\palemoon\browser\omni.ja\defaults\preferences\palemoon-branding.js (with i430VX's installer) But I guess that proves your point: it's hard to find, even if you know where to look!

And of course it won't work with the lighter-weight NM/MyPal browsers.... Maybe it'd work a bit better on Serpent; IDK

And it's not just XP/Vista compatibility either. We went through the same thing when MCP yanked out Basilisk's WE APIs, for "security" they said (ironically that's what Mozilla said about the "legacy" APIs too), and more recently their decision to yank out container tabs support since there's one buggy add-on that tries to duplicate that function. This isn't about "misrepresentation;" that's a red herring. This is about ideology. I disagree with Mozilla's decision to yank out the "legacy" (XUL/XPCOM/etc.) APIs too; to me, that's exactly the same thing: intentionally making your product less functional just to make it harder on folks running software you don't approve of.

Thanks, @siria; that's a good start. But let me flesh things out a bit: for FF/PM/NM/Basilisk/Serpent, the preconfigured SSUAOs are found in <browser installation folder>\browser\omni.ja\defaults\preferences\<browser>-branding.js. The precise path is important because these browsers include two omni.ja archives, each of which contain too many paths to manually search. The branding file for FF 52.9 contains no SSUAOs, of course, since SSUAOs are disabled by default in FF 52.9. Oddly, the branding file for Serpent 55 is named firefox-branding.js, not basilisk-branding.js. I guess MCP dropped the Moebius branch before they got around to renaming the files. As with FF 52.9, Serpent 55 comes with no preconfigured SSUAOs.

The above applies even on Windows 7, if one's favorite browser happens to be Basilisk (or @roytam1's Serpent. You may recall I switched from Basilisk to Serpent - even on 7 - when MCP removed all WE support from Basilisk and we persuaded roytam1 to retain that support in Serpent). If MCP fails to pull off another miracle with Widevine 4.10 in the next five weeks, Vista users will presumably, like XP users, have to fall back to reliance on Silverlight. Windows 7 users do have other browser options, but it's annoying to have to change browsers, or to use different browsers for different Web sites. So here's hoping MCP does it again.

Wouldn't you know that the XP and Win 7 versions of these games use different servers and different protocols. It's almost as if M$ planned this from the very beginning