Closed
Bug 603611
Opened 14 years ago
Closed 14 years ago
XPI's inside the extensions folder aren't getting installed correctly in older versions of Firefox
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: whimboo, Assigned: mossop)
References
Details
(Keywords: verified1.9.2)
Attachments
(1 file)
3.36 KB,
patch
|
robert.strong.bugs
:
review+
dveditz
:
approval1.9.2.13+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 With the placement of full XPI files in the extensions folder, older versions of Firefox do not install those extensions correctly: * Extension without a GUID as id will not getting installed at all (i.e. Addons Compatibility Reporter) * Inconsistent installation of multiple extensions with a GUID. Sometimes both, get installed. But mostly one or both get deleted (i.e. TwitterBar, RSS Ticker) Looking at the log, there is nothing shown for an id like 'grwatcher@ajnasz.hu.xpi' but as you can see below, the add-ons with a GUID have been lost: *** EM_LOG *** A Item Package appeared at: /Users/henrik/Library/Application Support/Firefox/Profiles/2hqiufva.sdfg/extensions/{1a0c9ebe-ddf9-4b76-b8a3-675c77874d37}.xpi that we know nothing about, assuming it was dropped in by the user and configuring for installation now. Location Key: app-profile *** EM_LOG *** A Item Package appeared at: /Users/henrik/Library/Application Support/Firefox/Profiles/2hqiufva.sdfg/extensions/{1f91cde0-c040-11da-a94d-0800200c9a66}.xpi that we know nothing about, assuming it was dropped in by the user and configuring for installation now. Location Key: app-profile *** EM_LOG *** Item Uninstalled via file removal from: rel%{1a0c9ebe-ddf9-4b76-b8a3-675c77874d37} Item ID: {1a0c9ebe-ddf9-4b76-b8a3-675c77874d37} Location Key: app-profile, uninstalling item. *** EM_LOG *** Item Uninstalled via file removal from: rel%{1f91cde0-c040-11da-a94d-0800200c9a66} Item ID: {1f91cde0-c040-11da-a94d-0800200c9a66} Location Key: app-profile, uninstalling item.
Reporter | ||
Updated•14 years ago
|
Assignee | ||
Comment 1•14 years ago
|
||
I wasn't able to reproduce any issue with GUID named add-ons, but if there is an issue there it is going to be something different to the problem with email-style ID add-ons. The branch assumes that any file that has a name matching the ID regexp can only be file pointers. This code simply drops through to allowing us to find them later as XPI files and extracts them. It also augments an existing test to verify it.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #484735 -
Flags: review?(robert.bugzilla)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch][needs review rs]
Assignee | ||
Updated•14 years ago
|
Version: 1.9.1 Branch → 1.9.2 Branch
Comment 2•14 years ago
|
||
Comment on attachment 484735 [details] [diff] [review] patch rev 1 >diff --git a/toolkit/mozapps/extensions/src/nsExtensionManager.js.in b/toolkit/mozapps/extensions/src/nsExtensionManager.js.in >--- a/toolkit/mozapps/extensions/src/nsExtensionManager.js.in >+++ b/toolkit/mozapps/extensions/src/nsExtensionManager.js.in >@@ -1222,20 +1222,21 @@ DirectoryInstallLocation.prototype = { > break; > entry instanceof Ci.nsILocalFile; > if (!entry.isDirectory() && gIDTest.test(entry.leafName)) { > var linkedDirectory = this._readDirectoryFromFile(entry); > if (linkedDirectory && linkedDirectory.exists() && > linkedDirectory.isDirectory()) { > locations.push(linkedDirectory); > this._locationToIDMap[linkedDirectory.persistentDescriptor] = entry.leafName; >+ continue; > } > } >- else >- locations.push(entry); >+ >+ locations.push(entry); > } > entries.close(); nit: perhaps add a finally to the try block and move entries.close() to it? Since this is the 1.9.2 branch I don't have a problem with not moving it.
Attachment #484735 -
Flags: review?(robert.bugzilla) → review+
Updated•14 years ago
|
Whiteboard: [has patch][needs review rs] → [has patch]
Assignee | ||
Comment 3•14 years ago
|
||
Comment on attachment 484735 [details] [diff] [review] patch rev 1 I'd like to land this on the branches to make migration from Firefox 4 to previous versions a little nicer. Should be extremely low risk
Attachment #484735 -
Flags: approval1.9.2.12?
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch] → [has patch][needs approval]
Comment 4•14 years ago
|
||
Comment on attachment 484735 [details] [diff] [review] patch rev 1 Approved for 1.9.2.12, a=dveditz for release-drivers
Attachment #484735 -
Flags: approval1.9.2.12? → approval1.9.2.12+
Assignee | ||
Comment 5•14 years ago
|
||
Landed: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/bb2e67d1661e Henrik, if you can still see an issue with GUID extensions can you file a new bug.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
status1.9.1:
? → ---
Flags: in-testsuite+
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch][needs approval]
Reporter | ||
Comment 6•14 years ago
|
||
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12pre) Gecko/20101024 Namoroka/3.6.12pre The installation works fine for both type of extension ids now. So there is no need for another bug. What about the 1.9.1 branch? Do we also wanna have the fix landed there or do we only support the last branch?
Status: RESOLVED → VERIFIED
status1.9.1:
--- → ?
Keywords: verified1.9.2
Version: 1.9.2 Branch → 1.9.1 Branch
Marking 1.9.1 as wonfix unless someone objects.
You need to log in
before you can comment on or make changes to this bug.
Description
•