Issues with Firefox 24 and latest daily version of UURollup v11

[ppgrainbow]

Hey there, I'm running into problems trying to install a add-on under Firefox 24 when running under Windows 2000 with UURollup v11 2013-09-02d installed.

For example, when I try to update the latest version of GreasyMonkey (v1.12), I'm getting a error message that "There was an error installing GreaseMonkey". When I try again, the error message repeats.

Also, when I try to download a add-on from Mozila's Add-ons extensions website, I get a error that "(add-on) cannot be installed because Firefox cannot modify the needed file".

And when I updated my machine to UURollup v11 2013-09-02d, the installation did not complete successfully with the Event 4373 error message in the EventLog:

"Windows 2000 UURollup-v11-d20130902 installation failed. Access is denied."

And here's the full log for complete details:

As far as I know when I tried to reboot my machine, I ran into a BSOD that the login process failed. I don't clearly remember which STOP error it was though, but I managed to go into the Recovery console to revert the botched update that caused Windows 2000 to not operate correctly, if not at all. And since I removed the uninstallation for UURollup v11 2013-09-02d, I can't uninstall it now.

Is there a way to fix this mess that I gotten into and is there a good update to UURollup v11?

Edited October 5, 2013 by ppgrainbow

[GaryMX]

@ppgrainbow, I am having the same problem since upgrading to FF24 (SeaMonkey 2.21). I installed my UURollup (v10d) in April, and have been running GREAT since then, until now. I couldn't update NoScript, FlashGot, and the SQLite Manager. However, another addon, Flagfox, updated fine. I saw somewhere (I think in MozillaZine) that it was something about the path being too long. But, nothing's changed in my FF/SeaMonkey installation (except the version!) I even tried going directly to the noscript.net website and installing the addon from there. I got the "needed file" error message like you saw. I was on the NoScript forum and left a message for Sergio Maone, who hopefully might have some insight. It would be disappointing to not be able to update the addons. The plugins (such as Shockwave Flash) update successfully, except with an Adobe warning that the OS is not supported.

[ppgrainbow]

@ppgrainbow, I am having the same problem since upgrading to FF24 (SeaMonkey 2.21). I installed my UURollup (v10d) in April, and have been running GREAT since then, until now. I couldn't update NoScript, FlashGot, and the SQLite Manager. However, another addon, Flagfox, updated fine. I saw somewhere (I think in MozillaZine) that it was something about the path being too long. But, nothing's changed in my FF/SeaMonkey installation (except the version!) I even tried going directly to the noscript.net website and installing the addon from there. I got the "needed file" error message like you saw. I was on the NoScript forum and left a message for Sergio Maone, who hopefully might have some insight. It would be disappointing to not be able to update the addons. The plugins (such as Shockwave Flash) update successfully, except with an Adobe warning that the OS is not supported.

Thank you very much for telling me.

It seems that we're in the next round of ESR (which is Firefox 24 ESR) It would be very disappointing to see that we will be unable to update the addons due to this change.

I sure hope that TomaszW and/or Blackwingcat makes any investigation regarding Firefox 24/Firefox 24 ESR with UURollup. I probably will need to test Firefox 24 in a VM to see if the problem can be reproduced there as well.

[GaryMX]

@ppgrainbow -- I found the answer in the NoScript forum (I think.) This verifies what I had seen in MozillaZine about the path of the profile being "too long." But why wouldn't it affect my Win XP computer also? Anyway, I copied his info about using FEBE to backup your profile, and create a new profile in a folder closer to the root of C: (or whatever drive your FF is on:)

Re: NoScript and FlashGot won't update

Postby access2godzilla » Sun Oct 06, 2013 4:34 am

Try moving your profile upwards in the following manner:

Install FEBE and take a backup of your extensions, themes, bookmarks etc. If extensions have some native method to take a backup of their individual settings (like NS has), take a backup using those options. (Do not select "Backup preferences" or "Backup Profile" in FEBE, since this will cause problems).
Type "firefox -p" (or "seamonkey -p", as the case may be), without the quotes in the Run dialog (Windows key + R) to start the Profile Manager.
Uncheck the option "Don't ask at startup" and create a new profile. Select a short profile location like "C:\firefoxprofile\" instead of something like "C:\Documents and settings\<username>\Application Data\Mozilla\Firefox\Profiles\<profilename>" (the long path is actually at the root of all this), and a profile name preferably without spaces.
Start Firefox with the new profile. Restore all your extensions, themes, history etc.

Automatic updates (as well as manual updates) should work now.
Let us know how it goes.

[GaryMX]

Or: View this: http://kb.mozillazine.org/Profile_backup (backing up profile) and then this -- "Moving your profile folder"

http://kb.mozillazine.org/Moving_your_profile_folder. You would have to create the new profile folder first, I would assume, then point the "switch profile" to the new folder. I wonder if you could just copy everything there from the current profile folder? If this is the root of the problem, then one of the two approaches should work.

[ppgrainbow]

Thank you so much for the help.

The only add-on that I could not reinstall was FireFTP. It's telling me that there was a error installing FireFTP. I'm guessing that it's probably because it has a "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.xpi" which is 38 characters long for a XPI extension.

[blackwingcat]

Does anyone know what are changed XLU.DLL from 20130611203132 to 20130612031138 ?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/06/2013-06-11-20-31-32-oak/

This is no problem lastest version.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/06/2013-06-12-03-11-38-mozilla-central/

This is first problem version.

I can not find from bugzilla.

https://bugzilla.mozilla.org/buglist.cgi?resolution=---&chfieldto=2013-06-30&query_format=advanced&chfieldfrom=2013-06-01&component=Extension%20Compatibility&product=Firefox

Edited October 7, 2013 by blackwingcat

[GaryMX]

Well, everyone, the shorter path name and moving the profile didn't work for me. Still having problems updating NoScript, FlashGot, and the SQLite Manager.

[ppgrainbow]

Well, everyone, the shorter path name and moving the profile didn't work for me. Still having problems updating NoScript, FlashGot, and the SQLite Manager.

That doesn't sound good.

[GaryMX]

I posted the following on the NoScript forum after someone asked me about the "missing file:"

Well, it's all moot. I uninstalled SM 2.21 (FF 24) and reinstalled SM 2.20. And, guess what? The updates were successful. ALL of them. So, it must be an issue with the newest release of the Mozilla platform. I did see somewhere in one of the Mozilla forums how they were changing the installed addon database from SQLite to .JSON format. I'm not sure that it said that exactly, but something like that. I think the "missing file" was an inaccurate warning. I think that it has to do with XPIProvider.jsm. That file is not on my PC. The following is an extract from the error log (see the attached text file, as I can't seem to "cut and paste" the information here:)

I looked at the code for the routine that calls this error -- it is a general "catch" error module. I don't really care; it just would be nice if they would quit tweaking these things in the product, and just improve security, speed, and memory usage. Why mess with something that can affect SOME of the addon updates? And, if XPIProvider.jsm is a "needed" file, why didn't the installation update routine (v2.20 to v2.21) install it where it was supposed to be??

addon_update_error.txt

Edited October 7, 2013 by GaryMX

[ppgrainbow]

I posted the following on the NoScript forum after someone asked me about the "missing file:"

Well, it's all moot. I uninstalled SM 2.21 (FF 24) and reinstalled SM 2.20. And, guess what? The updates were successful. ALL of them. So, it must be an issue with the newest release of the Mozilla platform. I did see somewhere in one of the Mozilla forums how they were changing the installed addon database from SQLite to .JSON format. I'm not sure that it said that exactly, but something like that. I think the "missing file" was an inaccurate warning. I think that it has to do with XPIProvider.jsm. That file is not on my PC. The following is an extract from the error log (see the attached text file, as I can't seem to "cut and paste" the information here:)

I looked at the code for the routine that calls this error -- it is a general "catch" error module. I don't really care; it just would be nice if they would quit tweaking these things in the product, and just improve security, speed, and memory usage. Why mess with something that can affect SOME of the addon updates? And, if XPIProvider.jsm is a "needed" file, why didn't the installation update routine (v2.20 to v2.21) install it where it was supposed to be??

The XPIProvider.jsm isn't found on my PC either and neither in a Windows XP VMware VM. While maintaining the latest workable version of Firefox (which is Firefox 24 and Firefox 24 ESR), Firefox 23 (at the end of the previous ESR) might have been the last version that worked perfectly.

I was wondering how changing the add-on adatabase from SQLite to .json format would break add-on installations and updating. And since XPIProvider.jsm is a needed file, how can it be obtained? :\

[GrofLuigi]

Just passing by... XPIProvider.jsm is inside omni.ja, which is a .zip archive with renamed extension.

GL

[ppgrainbow]

Just passing by... XPIProvider.jsm is inside omni.ja, which is a .zip archive with renamed extension.

GL

Thank you for telling me. What's obvious is that omni.ja cannot be opened as a ZIP archive at all. But if you copy the omni.ja file outside the Firefox directory and rename it to omni.zip, you'll see the XPIProvider.jsm which will reside in the \modules directory.

I extracted the XPIProvider.jsm looked at lines 5203 to 5221 to see what could be causing this error:

try {

// First stage the file regardless of whether restarting is necessary

if (this.addon.unpack || Prefs.getBoolPref(PREF_XPI_UNPACK, false)) {

LOG("Addon " + this.addon.id + " will be installed as " +

"an unpacked directory");

stagedAddon.append(this.addon.id);

if (stagedAddon.exists())

recursiveRemove(stagedAddon);

stagedAddon.create(Ci.nsIFile.DIRECTORY_TYPE, FileUtils.PERMS_DIRECTORY);

extractFiles(this.file, stagedAddon);

}

else {

LOG("Addon " + this.addon.id + " will be installed as " +

"a packed xpi");

stagedAddon.append(this.addon.id + ".xpi");

if (stagedAddon.exists())

stagedAddon.remove(true);

this.file.copyTo(this.installLocation.getStagingDir(),

this.addon.id + ".xpi");

}

"this.addon.id + ".xpi");" line is located on line 5221 which is what could be causing this error that fails to install add-ons in the first place. I will probably need to compare that to a Firefox 22 installation to see what changes were made that caused the error.

If for some reason, I'm missing anything, please let me know and I'll get back to you.

[blackwingcat]

It causes stagedAddon.exists() error

perhaps it fails to do this.addon.unpack"

I have researched yesterday.

http://blog.livedoor.jp/blackwingcat/archives/1817059.html

It shows some information in firefox > tool > web developer > browser console.

Just passing by... XPIProvider.jsm is inside omni.ja, which is a .zip archive with renamed extension.

GL

Thank you for telling me. What's obvious is that omni.ja cannot be opened as a ZIP archive at all. But if you copy the omni.ja file outside the Firefox directory and rename it to omni.zip, you'll see the XPIProvider.jsm which will reside in the \modules directory.

I extracted the XPIProvider.jsm looked at lines 5203 to 5221 to see what could be causing this error:

try {
// First stage the file regardless of whether restarting is necessary
if (this.addon.unpack || Prefs.getBoolPref(PREF_XPI_UNPACK, false)) {
LOG("Addon " + this.addon.id + " will be installed as " +
"an unpacked directory");
stagedAddon.append(this.addon.id);
if (stagedAddon.exists())
recursiveRemove(stagedAddon);
stagedAddon.create(Ci.nsIFile.DIRECTORY_TYPE, FileUtils.PERMS_DIRECTORY);
extractFiles(this.file, stagedAddon);
}
else {
LOG("Addon " + this.addon.id + " will be installed as " +
"a packed xpi");
stagedAddon.append(this.addon.id + ".xpi");
if (stagedAddon.exists())
stagedAddon.remove(true);
this.file.copyTo(this.installLocation.getStagingDir(),
this.addon.id + ".xpi");
}

"this.addon.id + ".xpi");" line is located on line 5221 which is what could be causing this error that fails to install add-ons in the first place. I will probably need to compare that to a Firefox 22 installation to see what changes were made that caused the error.

If for some reason, I'm missing anything, please let me know and I'll get back to you.

Edited October 8, 2013 by blackwingcat

[ppgrainbow]

That's what I've been thinking. stagedAddon.exists() can be found on line 5218 which might be preventing the add-ons from being installed correctly.

Edited October 8, 2013 by ppgrainbow