Closed Bug 292248 Opened 19 years ago Closed 19 years ago

Adblock can't be installed: vanishes from EM after download; NS_ERROR_FILE_NOT_FOUND

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: steffen.wilberg, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

fixed install.rdf
1.21 KB, text/xml
Details 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050428
Firefox/1.0+

Using a new profile, when clicking on the install link for Adblock on u.m.o.
(see URL above), and you accept the install dialog, the extension manager shows
the download progress, but once the download is completed, the extension
vanishes from the extension manager, i.e. it is empty again.

The js console displays:
RDFItemUpdater:checkForUpdates sending a request to server for:
http://adblock.mozdev.org/update.rdf, item =
({id:"{34274bf4-1d97-a289-e984-17e546307e4f}", version:"0.5.2.039",
installLocationKey:"app-profile", minAppVersion:"0.7+", maxAppVersion:".10+",
name:"Adblock", xpiURL:"", iconURL:"",
updateRDF:"http://adblock.mozdev.org/update.rdf", type:2})
RDFItemUpdater:onDatasourceLoaded: Found info about the installed
version of this item: ({id:"{34274bf4-1d97-a289-e984-17e546307e4f}",
version:"0.5.2.039", installLocationKey:"app-profile", minAppVersion:"0.9",
maxAppVersion:"10.0", name:"Adblock", xpiURL:"", iconURL:"", updateRDF:"", type:2})
Version Check Phone Home Completed

Error: [Exception... "Component returned failure code: 0x80520012
(NS_ERROR_FILE_NOT_FOUND) [nsIFile.copyTo]"  nsresult: "0x80520012
(NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
file:///D:/Internet/Firefox/components/nsExtensionManager.js :: anonymous ::
line 1056"  data: no]
Source File: file:///D:/Internet/Firefox/components/nsExtensionManager.js
Line: 1056

I don't know if the Adblock extension is malformed, but at least we should
display an error.

Other extensions are shown as "will be installed the next time you restart
Firefox" even after a restart.
does your build include the patch for bug 291666 ?
(was not included in the daily build)
I suspect it does and I can also verify with the patch applied... this is a
different issue that I saw yesterday and I have a patch in my tree for it. Since
there are additional paths available now (e.g. install by dropping in a file,
etc.) I have been testing as many possible scenarios as I can think of due to
patches in this section of the code could break other functionality.
Same result using a brand-new homemade Linux build.
OS: Windows XP → All
I see this with a new profile current build setup.
Googlebar Lite 0.9.2, Forecastfox 0.7.1, and EMButtons 1.1.3 show as "will be
installed the next time you restart
Firefox" even after restarting.

I then checked my profile and found the XPIs sitting untouched in a
<profile>\extensions\staged-xpis\{"there GUID"}\ untouched.

When I click on either Disable or Uninstall in the EM, the entry in the EM
disappears as well as the empty {"there GUID"} in <profile>\extensions\ but
staged-xpis\{"there GUID"}\ still has the XPI sitting there.

I haven't a clue why this is happening with some extensions. 

Tab Mix 0.2 (hacked trunk fix version) and Linkifaction 0.9.20 (fairly old and
hasn't been updated in a while) are not affected by this bug...

I get this in the Javascript Console after drag/dropping Googlebar Lite 0.9.20
in the EM.

Error: [Exception... "Component returned failure code: 0x80520015
(NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.remove]"  nsresult: "0x80520015
(NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame ::
file:///F:/PROGRA~1/Firefox/components/nsExtensionManager.js :: anonymous ::
line 1054"  data: no]
Source File: file:///F:/PROGRA~1/Firefox/components/nsExtensionManager.js
Line: 1054

  /**
   * Stages the specified file for later.
   * @param   file
   *          The file to stage
   * @param   id
   *          The GUID of the item the file represents
   */
  stageFile: function(file, id) {
    var stagedFile = this.location;
    stagedFile.append(DIR_STAGE);
    stagedFile.append(id);
    stagedFile.append(file.leafName);
    if (stagedFile.exists()) 
      stagedFile.remove(false);
      
    file.copyTo(stagedFile.parent, stagedFile.leafName);
    
    // If the file has incorrect permissions set, correct them now.
    if (!stagedFile.isWritable())
      stagedFile.permissions = PERMS_FILE;
    
    return stagedFile;
  },

The above is the code that was being pointed to by the Javascript Console.
Sorry to double post but I found something.. strange..
Okay more weirdness about the staged-xpis thing.
1) Try to install one of the extensions (do not use EMButtons it breaks the EM
(whoops) lol) so use Googlebar Lite 0.9.2
2) Restart Firefox, It won't install.
3) Go to your profile\extensions directory.
4) Copy the XPI in the staged-xpis\GUID directory to the extensions directory.
(do not change anything just copy it)
5) Restart Firefox this time. You get a message about "There was an extension
found in the Extensions folder would you like to install it?"
6) Click yes.
7) Viola, extension is Installed :)

I hope that is clear to everybody. This workaround was found totally by accident.

WFM on beast build...no problems whatsoever installing the adblock extension...
(In reply to comment #6)
> WFM on beast build...no problems whatsoever installing the adblock extension...

well now with further testing, the EM is still acting scewy....I was able to
download, install, and use adblock and IEView...but when extensions were
enabled, bookmark items were not doing anything when clicked upon.....after i
disabled the extensions, bookmarks were fine....i then tried to re-enable the
extensions, but I could only get IEView to enable...and the text which states
'This extension is disabled' (something like that) was red on adblock's....

Obviously the EM has some major problems which need to be resolved:)....getting
closer though :)

Chris Holderfield


I installed Adblock and Googlebar lite online and both are working normally.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050428
Firefox/1.0+
The adblock extension on UMO has a maxVersion of 0.10 and it has a custom rdf
that has a maxVersion of 10.0. The EM will go out and use this higher maxVersion
but at this time it may enter into the state described in this bug. I have been
able to duplicate it and I have a patch that fixes this bug. I am thoroughly
testing this patch along with several others due to there being several new
scenarios for installing / updating extensions and themes and changes to one
method can affect other methods. I hope to have the patch ready tomorrow evening
but I am going to first verify it thoroughly. These patches also fix themes and
remove the requirement for the theme to have a chrome.manifest file.
(In reply to comment #7)
> (In reply to comment #6)
> > WFM on beast build...no problems whatsoever installing the adblock extension...
> 
> well now with further testing, the EM is still acting scewy....I was able to
> download, install, and use adblock and IEView...but when extensions were
> enabled, bookmark items were not doing anything when clicked upon.....after i
> disabled the extensions, bookmarks were fine....i then tried to re-enable the
> extensions, but I could only get IEView to enable...and the text which states
> 'This extension is disabled' (something like that) was red on adblock's....
> 
> Obviously the EM has some major problems which need to be resolved:)....getting
> closer though :)
> 
> Chris Holderfield

well now after installing the latest beast build (Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050429 Firefox/1.0+).....adblock does
not work again...lol....*re-votes for bug*

Thanks,
Chris Holderfield
Installed Adblock online here (latest link) in a new profile:
http://www.extensionsmirror.nl/index.php?s=65f3d7569d7688b052bba8d0773b5c1a&showtopic=774

Installed the latest tinderbox-build as is.
WFM, deleted every component in the "blockable items" on the startpage.
Sorry, I meant the normal but repackaged Adblock version.
Online installation of Adblock_0.5.2.039 recovered here between the nightlies of
28 and 29 April 2005.
Attached file fixed install.rdf (obsolete) — 
Adblock installs in recent nightlies with this corrected install.rdf.
Download the adblock xpi, pack the install rdf into the xpi (which is just a
zip file), copy the xpi into your "extensions" folder in your profile, restart
Firefox, click Install.

I basically entered sane values for minVersion and maxVersion and removed the
reference to the updateURL http://adblock.mozdev.org/update.rdf, which sets
maxVersion to 10.0, which is probably not a good idea.
Attachment #182304 - Attachment mime type: application/rdf+xml → text/rdf
Attachment #182304 - Attachment mime type: text/rdf → text/xml
Attached file fixed install.rdf — 
Same as above, but with Windows-style line-endings, and spaces instead of tabs.
Attachment #182304 - Attachment is obsolete: true
The NS_ERROR_FILE_NOT_FOUND error is due to the xpi file being deleted from the
staging dir after the phone home to check if the extension has had its
maxVersion bumbed up to be compatible. The patch in bug 292506 (and the two bugs
it depends on) fixes this and several other issues.

In regards to the extension disappearing from the EM after install this is the
same as previous behavior when installing an incompatible extension. If after
the phone home is complete and the extension is found to be compatible it will
then be re-added to the UI and installed. If it is found to still not be
compatible it will display an alert stating this instead. This I think can and
should be improve on but in a different bug.
I filed bug 292619 for the issue with the extension disappearing from the ui
during the incompatible update check.
(In reply to comment #15)
> Created an attachment (id=182378) [edit]
> fixed install.rdf
> 
> Same as above, but with Windows-style line-endings, and spaces instead of tabs.

Adblock 0.5.2.039 d2 installed with no problems into a new profile using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050501
Firefox/1.0+ for me with this "patch". Works fine and shows up in the EM.
*** Bug 292928 has been marked as a duplicate of this bug. ***
This bug is fixed by the checkin of the patch in bug 291946 - I checked both a
new install and an upgrade of adblock from U.M.O. The remaining issue of an
extension disappearing from the Extensions Manager during an incompatible update
is bug 292619.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
No longer depends on: 292506
This does still not work on some builds. It works flawless on zip-builds but not
on installer-builds.

1. Install the latest win32 installer build.
2. Install Adblock (makes no difference what version or update).
3. Adblock does not install.

It works on win32 installer build with this workaround:

1. Install the latest win32 installer build.
2. Install no matter what extension with a valid guid, e.g Dictionary Search.
3. In the same session, install Adblock.
 
After a restart (or 10) you'll see that Adblock is installed, but not Dictionary
Search. This extension is in an ever lasting state of "This extension will be
installed after...etc."

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050510
Firefox/1.0+
Here are the steps I used which worked with an installer.

1. Installed clean installer build from today (e.g. 20050510), created a new
profile and started, and then restarted.
2. Went to the url to install adblock supplied in this bug.
3. Clicked Install Now
4. Got the software installation popup and then ignored warning by adding
"do-not-add.mozilla.org" to my allow list
5. Clicked Install Now again and then Install to install the extension.
6. Let the extension install - it showed will be installed after restart.
7. Restarted
8. Went into Tools - Extensions and Adblock was listed correctly (e.g. no
restart message).
9. Opened the adblock options successfully.
10. Opened the adblock preferences from Tools - Adblock - Preferences

I suspect the strange results for your two extension install is bug 293583 or a
variation of it. There can also be issues with installing, uninstalling,
enabling, disabling, etc. extensions due to there being a bug in the enumerator
code for doing so. I can think of several other parts of the code where this
could be failing but I am very sure that the part of the code that caused this
bug (e.g. NS_ERROR_FILE_NOT_FOUND, etc.) is fixed as described originally in the
report.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: