DanR20

Member
  • Content count

    61
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DanR20

Profile Information

  • OS
    none specified
  • Country
  1. You're using Palemoon on w2k? Last I tried it on Win 7 several must-have addons of mine were broke but it maybe I'll download the portable and give it another chance.
  2. There could be other factors involved causing the crashes not related to your hack or possibly conflicting with it that's unique to his setup. All I know is that it's working great here although I agree a more permanent solution would be better.
  3. @piotrhn, don't know if this will help but if you have access to XP's mspaint.exe try replacing that with w2ks in system32. It works great and adds extra converting options. XPs also works in Windows 7 and is way better imo. @mixit, an update on your fix: been running Firefox right along and no crashes yet. Hoping there's no more major breaks from now until v52 goes into esr.
  4. That did the job at opening it at least it, took me about a minute to swap the text strings. Currently running today's inbound build for an hour with no crashes yet, and that includes HTML5 and flash videos. It may not be the most ideal fix but it's working so far, thanks again.
  5. Thanks for the fix, I'm not much into coding but when I get the time I'll try and figure this out. If it works who cares how crude it is? Once I get the fix down it will become easy in 52esr since they don't do anything new just security updates so it's only a matter of replacing the xul file with the custom one on each update. On v2.6 here, I've never updated to v2.8. Firefox doesn't even get installed, it's run either off of the portable or directly out of the app folder from a downloaded extracted zip. So that method might work on v2.8. Could you tell me what hex editor you use?
  6. After reading the changes that was the first thing I tried with no luck. These were added to a new prefs.js: user_pref("accessibility.blockautorefresh", true); user_pref("accessibility.force_disabled", 1); user_pref("accessibility.ipc_architecture.enabled", false); I'm on Windows 7 so there are others that can be tried later but you're probably correct about ole32 not being delay-loaded.
  7. Firefox first broke with build 1471465695 from Mozilla win32 inbound on August 17th. The changes were linked earlier: https://hg.mozilla.org/integration/mozilla-inbound/rev/c9f49a119255 With that change they added a typelib "Accessible.tlb" in the firefox app folder. Deleting that doesn't do anything, it still won't start because CoGetInterceptor was executed and failed. So what has to be changed or reversed back to the previous code in any custom build is the bug related to CoGetInterceptor: https://bugzilla.mozilla.org/show_bug.cgi?id=1263224 This would have to be done on every update, although it would be easier once it got to 52esr, which would keep Firefox going on Win2000 for another year or so. Since I'm not much of a coder maybe someone will chime on with an easier way of accomplishing the same task.
  8. According to the first link it says: CoGetInterceptor requires information from a typelib to be able to // generate its emulated vtable. If a typelib is unavailable, // CoGetInterceptor returns 0x80070002. Would it be just a matter of editing the typelib? Deleting that will probably not fix the error and I'm assuming that 0x80070002 is a stop error that keeps the program from opening.
  9. It's inside XUL.dll so would that have to be decompiled? Do you have a decompiler to look at it?
  10. So Firefox is dead on Win2000 then? We've got 45ESR for now, that's good for another 6 months of updates. Not sure exactly what they did but it's in XUL.dll. The only alternative would be to make a custom Firefox that reverses that particular code change. If you're interested in trying to figure it out scroll down to the changes made by Aaron Klotz on August 17th. There's a total of seven of them that go from 950299252332 to c9f49a119255. One of those is responsible since it was in that range when it first broke. I couldn't do a mozregression to get the precise one because the program won't work on Win2000. Since it's not a problem on XP can't do it there either. https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=15+days+ago&enddate=now
  11. Have you tested it and are you getting the same error? It seems that it could be linked through run-time dynamic linking so fixing it might be possible. Are you able to modify ole32 so it can export the function same as XP? After some testing it was determined to be the result of this change: https://hg.mozilla.org/integration/mozilla-inbound/rev/c9f49a119255
  12. Hello blackwingcat, It's been a while but it looks like they finally broke Firefox in w2k. Can you test the very latest 51 nightly, I'm getting the dreaded error message "couldn't load XPCOM". I thought it might be sandboxing again but that's disabled as are e10s. Another error message I'm getting is this: "The procedure entry point CoGetInterceptorFromTypeInfo could not be located in the dynamic link library ole32dll". The kernelex version I'm using is 2.6b, does a newer version fix that? It's a recent break in the last few days so I'm assuming no. It appears to be a call function in ole and is working in XP. Hopefully something can be done with it.
  13. Working here too using 1. In a recent Mozilla bug they said they planned to remove "security.sandbox.content.level" and hard code it, most likely at maximum security setting of 2. They did mention however the possibility of using environment variables to disable it so we'll just have to wait and see. Lots of big (and unwanted) changes coming to Firefox I''m afraid.
  14. Hi blackwingcat, good news, couldn't figure out why e10s were still working on 45.0 and not 46.0 so I went through and compared the about:config settings. It turns out in 46.0 they added sandboxing. Look for the entry "security.sandbox.content.level" and change it from default 2 to 0 to disable it. e10s are back in business for w2k, although as usual performance isn't that great but that's a browser issue. I'm going to keep e10s disabled for as long as it's possible. Would it be possible to make sandboxing work on w2k because if I know Mozilla they will eventually remove this option as they do so many others.
  15. Hmm, wonder if there's some kind display driver issues? I'm on XP right now using Nightly 46 with e10s enabled and it's working just fine so there's no way I can file a bug with Mozilla because it's not a problem. I'm only seeing it on W2k. If it's broke for you on XP would you consider filing a bug with Mozilla: https://bugzilla.mozilla.org/ It might be the problem is specific to certain systems and not everyone's. There's no chance they will entertain a bug for W2k.