Jump to content

Mathwiz

Member
 View Profile  See their activity

  • Posts

    1,867

  • Joined

  • Last visited

  • Days Won

    51

  • Donations

    0.00 USD 

  • Country

    United States

 Content Type 

Everything posted by Mathwiz

  1. Mathwiz
    Roger. Downloading & installing now.
  2. Mathwiz
    Big difference: 15 f/s on XP vs. 93 f/s on 7, using Serpent on the same machine. (I'm a bit surprised that my home machine is almost twice as fast as my work machine at this particular task, but whatever.) I assume most of that is due to not using hardware acceleration.
  3. Mathwiz
    @FranceBB, you should consider Serpent 55 and the Multi-Account Containers extension. Force gmail, youtube, and the like into a "Google" container where you can sign in and stay signed in - but don't force google.com itself into that container. Then sign out of Google in your "default" container, which is where you'll be searching from most of the time. There's no reason to make it easy for Google tie every bloody search you do to your Google ID, and this extension makes protecting your privacy easy and painless. Personally, I'm less worried about the US's NSA and the UK's MI6 than I am about Google themselves. After all, the former two can probably get any info they want about me whether I use Google or not, but Google's entire business model is to collect as much info as possible about their users and sell it to anyone who's willing to buy. You may not be paying for their services with money, but they aren't really free; at least make Google do a little work for their "payment" (your personal info) rather than just giving it to them. As to the original question, I've used Startpage.com as my default search engine for some time. AIUI it's actually a "meta-search" that feeds your searches to several search engines (including Google) and consolidates the results, so you aren't really giving up Google's advantages by using it; but at least you're avoiding "the filter bubble."
  4. Mathwiz
    I have Flash but leave it disabled unless I come across a site that needs it, so I haven't really tested it with e10s. Not surprising in the least. Code-signing certificates cost money and @roytam1 is building these browsers for free. I'm sure he'd be happy to sign them if you ponied up to buy him a cert. Or you could go with MyPal if their .exe files are signed. AIUI there's very little difference between MyPal and NM (mostly just which of MCP's builds are used). BTW I don't think e10s even works with NM; only with Serpent.
  5. Mathwiz
    Well, Silverlight and Java tests seem to run OK; I realize that's not a very thorough test, but all plugins use plugin-container.exe AFAIK. That's weird. I got 181 fps on 32-bit St 55 (which AIUI is basically FF 53) on 64-bit Win 7. I wonder if the older FF might outperform the newer one on Win 10? Next week I'll try it on both the Win 7 and XP "sides" of the same PC and see how much difference HW acceleration makes.
  6. Mathwiz
    Interesting! At first, toggling that pref to true had no effect on my Win7 system; with processCount set to 2 and 2 tabs open, I had 4 processes before, and after, toggling separateFileUriProcess and restarting. But then I read the pref name closely, opened an HTML file on my own PC, et voila! A fifth process appeared. Closing the tab showing that HTML file dropped the process count back to 4. I don't know that it's necessarily worth toggling that pref, even on Win7, but it's another surprising feature of this browser. Yeah, I know; but what I didn't mention originally is that I actually looked at the XP-blocking code at the Bugzilla link you provided earlier: #if defined(XP_WIN) if (Preferences::GetDefaultCString("app.update.channel").EqualsLiteral("release") && !IsVistaOrLater()) { gMultiprocessBlockPolicy = kE10sDisabledForOperatingSystem; return gMultiprocessBlockPolicy; } #endif (This was back around FF 48.) As you can see, it uses an #if defined(...) block to check whether the build targets Win XP, but it does a run-time check of the app.update.channel pref rather than using another #if defined(...) block. Obviously the code has been changed since then - otherwise e10s would work on Win XP in FF 52 ESR since it's not a "release" build - but I figured they probably still did a run-time check, so changing the pref was worth a try. However, it didn't work. Of course I don't know if building the browser as "default" vs. "release" or "esr" would let e10s be enabled the "normal" way. I'll leave that as an exercise for others. As long as there's another way to enable e10s without recompiling the browser, I'm happy; just very curious.
  7. Mathwiz
    It's quite a bit more responsive. With dom.ipc.processCount set to 1, the active tab tended to "hang" when another tab was refreshing in the background. When set to two, it didn't seem to hang. This was on a Win 7 64-bit system (though it was the 32-bit version of Serpent 55). I don't know if it will improve as much with 32-bit Win XP as it did with 64-bit Win 7, but it seems OK on my Win XP VM even with dom.ipc.processCount set to 1. So you should probably just leave it at 1 unless you're having "hangs" like I was. There's probably not much point in setting it higher than 3 unless you have a 64-bit OS with beaucoup RAM. I sort of expect RAM usage to be higher with more processes, but as long as you have enough RAM, I'm hoping you'll find FF / Serpent to be more responsive. Glad to hear it. That's what e10s was supposed to do.
  8. Mathwiz
    Q: A: Yep! Apparently there's always one "extra" process when using Serpent 55 on my Win 7 system at home. Edit: Note that this only happens with Serpent 55. Serpent 52 always gives 2 processes when dom.ipc.processCount is 1, and 3 when it is 2; regardless of OS. BTW, browser performance seems to have improved a lot with that simple change.
  9. Mathwiz
    Well, there is a string pref called app.update.channel. In FF ESR builds, it's set to esr. In "regular" FF builds, it's set to release (I think). In @roytam1's Serpent builds, it's set to default. Note: it doesn't show as boldface in about:config (unless you change the default value); I'm just using bold here to indicate literal values. Originally the code blocking e10s on XP only applied to release builds, but our experience indicates e10s is now blocked in esr builds too. To see whether the block applies to default builds, I changed app.update.channel from esr to default and restarted FF 52. Unfortunately, about:support still indicated 0/1 (Windows XP). So apparently the code was changed at some point to block e10s on XP in all FF builds. My guess is that the code was changed after Basilisk 55 was forked from FF 53, which would have been around the time FF 52.1 ESR was released. I distinctly remember having two firefox.exe processes through several updates of FF 52.x ESR, but I don't remember exactly which version that stopped with. That doesn't explain Serpent 52 though. Basilisk (Serpent) was forked from FF 52, so it would have inherited the same code; so one would expect it to work like either Serpent 55 (where it always works) or FF 52 (where it's only blocked in WinXP). But since MCP eventually intends to remove e10s from Basilisk entirely, I'm guessing that somewhere along the line they changed the code to block e10s entirely unless forced.
  10. Mathwiz
    Unfortunately Python 3.5 isn't a full package, so it's not as user-friendly as the official Python 3.4.4 package is. I think you'll have to create your own Python 3.5 folder in the Start menu. Put two shortcuts in the folder you create: one to <Python 3.5 installation path>\python.exe, named Python 3.5 command line, and one to <Python 3.5 installation path>\doc\python350.chm, named Python 3.5 Manuals. Hopefully that will at least get you started.
  11. Mathwiz
    You mean posts? Just ask a moderator, such as @dencorso. I think we used to be able to delete our own posts but we had some abuse, so that functionality was removed
  12. Mathwiz
    Strange; it now seems to be working for me too, at least on WinXP. (I'm using the 2019-04-05 build of Serpent 55, in case that makes a difference.) I set dom.ipc.processCount to 2 and with two tabs, sure enough; I have 3 processes now. No idea what I did wrong last time. Its behavior on Win 7 is puzzling. I always have 3 processes even though dom.ipc.processCount is set to the default of 1. If I set it to 2 will I get 4 processes? I'll investigate that further tonight after I get home.
  13. Mathwiz
    And it works the same way in St 52: e10s is disabled on WinXP unless you force it (edit) although the about:support message is different: So naturally I had to try on Win 7, and sure enough, it's disabled there too, unless you force it! Methinks MCP slipped some code into St 52 that disables e10s unless forced. St 55, though, lets you enable it the "official" way - even on WinXP. So in summary: On FF 52.9, e10s is disabled on WinXP (unless forced); can be enabled on other OSes On St 55, e10s can be enabled on all OSes without forcing On St 52, e10s is disabled on all OSes, unless forced.
  14. Mathwiz
    I have a few add-ons flagged as incompatible with e10s: Classic Add-Ons Archive (works anyway, via a kludge, but you have to edit a .js file and remove the check for Waterfox first, otherwise it will just display a message telling you to turn e10s off when you click its icon; note that doing this invalidates it signature so you also have to set xpinstall.signatures.required to false to run it with this edit) Classic Theme Restorer (works anyway AFAICS) Version in Add-On Bar (works anyway AFAICS) IE Tabs 2 (rarely used; I set up a "single-process mode" profile with e10s disabled for those rare cases)
  15. Mathwiz
    @Dave-H; it looks as if you'll have to put browser.tabs.remote.force-enable back in. Make it Boolean and set it to true. Apparently this doesn't work on XP unless you force it. Edit: I just confirmed this on my own copy of FF 52. If you don't have browser.tabs.remote.force-enable set to true, FF won't start e10s on WinXP. Note: that pref appears to to have no effect in St 55. I always get 2 processes on XP and 3 on Win 7, regardless of how it's set. On FF/St 52 it appears to be a maximum. If you set it to, say, 2, you don't get 2 extra processes (3 total) immediately after starting the browser, but you will once you open up a second tab (not including about: tabs).
  16. Mathwiz
    Wow - that sounds as if FF 52 specifically blocks e10s on WinXP! To be fair, I've always enabled e10s on FF 52 by creating the browser.tabs.remote.force-enable Boolean preference and setting it to true, which bypasses all sanity checks. Sort of the "if it jams, force it" approach But I tried @VistaLover's way, and it works with Serpent 55 on WinXP. Haven't tried it with FF or St 52 on XP yet. I'll do that tomorrow if I have time. Edit: Well, that's what I get for responding before reading the full thread. @VistaLover beat me to it. Oh, well....
  17. 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.
  18. Mathwiz
    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....
  19. Mathwiz
    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.
  20. Mathwiz
    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.
  21. Mathwiz
    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.
  22. Mathwiz
    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.
  23. Mathwiz
    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!
  24. Mathwiz
    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.
  25. Mathwiz
    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.)
×
×
  • Create New...