388042 - the init method in nsIZipReader in FF v3.0a7pre is not functioning

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[sdb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071105 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071105 Minefield/3.0a7pre

I use the following code to retrieve nsIZipReader objects.  It has been working well in FF 2.0.0.4, SM 1.1.2, and NS 9.0b2.  I recently tried to retrieve an nsIZipReader in FF v3.0a7pre with the code below.

var zipReader = Components.classes["@mozilla.org/libjar/zip-reader;1"].
getService(Components.interfaces.nsIZipReader);
zipReader.init(zipFile);
zipReader.open();

Instead of successfully retrieving the nsIZipReader the following error was thrown.

Error: zipReader.init is not a function

Perhaps the nsIZipReader interface has changed in the latest trunk?

Reproducible: Always

Steps to Reproduce:
1. Retrieve an nsIZipReader object using the code listed above.
Actual Results:  
An error was thrown stating that the init method could not be found.

Expected Results:  
The nsIZipReader should have been initialized with the zip file and then opened.

This problem only started appearing in v3.0a7pre.  The code works well in other versions as well as other browsers.

Comment 1

[Dave Townsend [:mossop]]

Correct, the interface changed some time ago. You just use the open method now.

Comment 2

[sdb]

Unfortunately using the open method to create and initialize an nsIZipReader for an open jar file does not work.  I've been using the nsIZipReader to search the jar files of installed extensions.  With the init method everything works fine, but by using the open method it simply returns an nsIZipReader object with the file property undefined.  I haven't looked at the source code but I'm assuming that it's coded to return if the nsIZipReader is shared or the file is already open.  If that's the case then the only way to retrieve the nsIZipReader for an open jar file is to get it from the zip reader cache.

var zipReader = Components.classes['@mozilla.org/libjar/zip-reader-cache;1'].
getService(Components.interfaces.nsIZipReaderCache).
getZip(zipFile); //or retrieve the JARCache from nsIJARProtocolHandler

However by using the nsIZipReader that is returned by the nsIZipReaderCache interface it causes all sorts of problems to occur in the browser.  And on many occasions the browser will completely crash.  The init method seemed to solve all of these conflicts and I was able to successfully search the open jar files using the findEntries method.

Is there any other way to retrieve an nsIZipReader for the jar file of an installed extension?  If not, then the source code really needs to be changed to allow multiple instances of nsIZipReader to be opened for the same file.

Comment 3

[Dave Townsend [:mossop]]

I dont understand, if you create a new interface of nsIZipReader and open the jar file then you have your own nsIZipReader, not a shared on or anything. Are you saying it does not open the file?

Comment 4

[sdb]

No it does not open the file.

I need to open an nsIZipReader for a jar file that belongs to an extension which is currently installed and enabled.  It appears that by trying to create an nsIZipReader for an open jar file (one currently in use by an extension) the interface never gets initialized.  If I use the code below to create a new interface and then check the file property to make sure the jar file is initialized it shows up as undefined.  So I'm guessing that there is code in place to prevent an nsIZipReader from being initialized for open zip files?  Or if there is already an nsIZipReader in cache for the same file?

var zipReader = Components.classes["@mozilla.org/libjar/zip-reader;1"].
getService(Components.interfaces.nsIZipReader);
zipReader.open(zipFile);
alert(zipReader.file);
//the path of the jar file would be something like the following
//C:\Docume~1\username\Applic~1\Mozilla\Firefox\Profiles\abcdefg.default\extensions\{GUID}\chrome\extension.jar

So the only way I can retrieve the nsIZipReader for the open jar file is to get it from the nsIZipReaderCache.  But for some reason it causes all sorts of havoc with the browser anytime I try to access the shared nsIZipReader.  I've had the popup menus on the toolbar stop functioning, the error console and the dom inspector won't open, and occasionally the browser will stop responding altogether.  The only way I was able to access the open jar file with an nsIZipReader was to use the init method, but since it is no longer a part of the interface I'm unable to search the contents of open jar files.

Comment 5

[Dave Townsend [:mossop]]

Your code contains an error. You must use createInstance, not getService when creating a zipreader or you will always retrieve the same instance, and most likely end up breaking a lot of things.

I have just tested what you are trying to do and it works for me with the change mentioned.

Comment 6

[sdb]

It seems to be working now.  Although I'm a bit worried about using createInstance.  The original reason that I began using getService was to avoid the problems I ran into with createInstance.  I've tested the code above with createInstance in FF 2.0.0.4 and 3.0a7pre in Win XP and everything appears to be working fine.  I'm not sure if this is a platform specific bug, but I was previously doing most of my testing on Linux.  And anytime I would use createInstance to get an nsIZipReader in 2.0.0.4 on Linux it would cause the browser to freeze.  Using getService instead seemed to solve those problems.  Out of curiosity what platform did you test the code on?  Unfortunately I don't currently have access to a Linux machine so I'm not able to test it at the moment.

Many thanks for your help. :)

Comment 7

[Dave Townsend [:mossop]]

OSX. I am quite frankly amazed that you didnt get problems using getService. createInstance is the way to create a new zipreader instance. If you are having bugs with that then please file them.

Comment 8

[sdb]

After quite a bit of testing it turns out that the problem is related to the nsIChromeRegistry interface and not nsIZipReader.  I use a number of interfaces to convert a chrome url to a nsIFile.  Apparently nsIChromeRegistry has to be retrieved with getService otherwise it will cause all kinds of problems with the browser's popup menus.  I thought I had narrowed down the problem to the nsIZipReader interface which is why I was using getService to retrieve the nsIZipReader.  As long as I don't use createInstance to retrieve nsIChromeRegistry then everything appears to work well.

I'm not sure if this is a bug or if that's normal behavior for nsIChromeRegistry.  I was under the impression that most interfaces would contain the word 'service' if they needed to be retrieved using getService instead of createInstance.  Should I file this as a bug?  I've attached an example script to reproduce the error.

Comment 9

[sdb]

Attachment: To reproduce the bug change getService to createInstance for nsIChromeRegistry

Comment 10

[Dave Townsend [:mossop]]

No, the chrome registry is a service and needs to be retrieved as such.