295013 - Installing the same theme a second time or uninstalling after install in one session fails

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Robert Strong (they/them - no direct email)]

The jar file is still in use and this starts with the the call to
nsChromeRegistry::ProcessContentsManifest in nsExtensionManager.js.in. A couple
of ways this could be resolved are:
1) Add jar files to chrome-flush-skin-caches and then notify in a similar manner
as the last patch in bug 251026.
2) Change nsChromeRegistry::ProcessContentsManifest to extract contents.rdf to
the temp directory instead of reading them from within the jar.
3) Create a method for forcing the release of a single jar (perhaps
nsZipReaderCache::ReleaseZip could be used). Since this is during an install we
should be the only ones with a reference to the jar so it should be safe.

From the js console:
safeInstallOperation: failed to clean up item location after its contents were
properly backed up. Failed to clean up:
<path>\extensions\{9f08cb5a-76b1-4bcf-aff9-90e1a5d60b1e} ... rolling back file
moves and aborting installation.

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
 location: "JS frame :: <path>/components/nsExtensionManager.js ::
safeInstallOperation :: line 1764"  data: no]
Source File: <path>/components/nsExtensionManager.js
Line: 1764

Comment 1

[Robert Strong (they/them - no direct email)]

This same issue prevents uninstalling a theme after installing it during the
same session - adjusting summary. From the js console:

safeInstallOperation: failed to clean up item location after its contents were
properly backed up. Failed to clean up:
<path>\extensions\{9f08cb5a-76b1-4bcf-aff9-90e1a5d60b1e} ... rolling back file
moves and aborting installation.

_finalizeUninstall: failed to remove directory for item:
{9f08cb5a-76b1-4bcf-aff9-90e1a5d60b1e} at Install Location: app-profile, rolling
back uninstall

Comment 2

[Robert Strong (they/them - no direct email)]

Attachment: patch

This seems like the simplest way to fix this bug. It adds a param for
specifying the base uri to processContentsManifest so the contents.rdf can be
read from outside of the jar and thereby prevent the zipreader cache from
getting a hold of it. This fixes both cases I cited.

Comment 3

[Benjamin Smedberg]

Comment on attachment 184223 [details] [diff] [review]
patch

This is rather more scary than I would like for 1.1a1, but it might be
necessary to fix bug 295723.

Comment 4

[Mike Shaver (:shaver emeritus)]

Comment on attachment 184223 [details] [diff] [review]
patch

a=shaver.

Comment 5

[Benjamin Smedberg]

Fixed on trunk for 1.1a2