DanR20

Member
  • Content count

    57
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DanR20

Profile Information

  • OS
    none specified
  • Country
  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. It's inside XUL.dll so would that have to be decompiled? Do you have a decompiler to look at it?
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Dibya, google the PosReady 2009 hack for XP, it's a simple registry entry that you add. With that, you can go to Windows Update and download all the latest security patches for XP. PosReady 2009 will be updated until 2019 so there's three more years of XP use.
  13. So you tested nightly 46 and are having the same problem on W2k and XP? Is there anything that can be done? It's working for me on XP, only W2k is broke.It appears to be the tabbar that's unresponsive since it's impossible to even create a new tab.
  14. blackwingcat, are you still testing Firefox on W2k? There's a new problem that just started with e10s or multiprocess in the nightlies v46. If they're enabled, Firefox is dead. It will start but nothing loads and the UI is non-responsive. Since e10s use gdiplus I tried different versions but that didn't do anything. Not sure what it could be but it just recently started. With e10s disabled it's still useable but beginning early next year Mozilla is removing the ability to disable e10s so that will make Firefox dead on W2k. I'll keep trying to figure out what update might be responsible.
  15. That did it, shockwave player is coming right in with GDI+ version 5.2.6002.23835. Not only that but the newer quick time player is also still working. Thanks for the fix, it's good to have the latest versions of these files in case of any security threats.