413682 - Contract-based component re-registration fails

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Mike Perry]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10 XPCOMViewer/1.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre

The Torbutton extension 'hooks' a couple of different components by implementing their interfaces under a new class id, but with the same contract-ID. However, for some components, this does not seem to be possible under Firefox 3. In particular, the sessionstore;1 and sessionstartup;1 seem to be no longer augmentable in this way. In the case of the sessionstartup, the NSGetModule is called, but the new doRestore implementation does not seem to get called (though registerFactoryLocation does seem to succeed).

Reproducible: Always

Steps to Reproduce:
1. Download https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/crash-observer.js
2. Pepper it with dump statements
3. Place it in the components directory of an arbitrary extension
Actual Results:  
The NSGetModule is called, as is the registerSelf method, but the doRestore method does not seem to get called.

Expected Results:  
doRestore gets called when the sesstionstartup;1 component is used, as happens in Firefox 2.

If you download the torbutton extension to test this, it needs a couple of hacks to work with firefox 3: it needs its rdf to be updated, and you need to remove the ignore-history.js file, which causes a firefox crash due to attempting to look up an obsolete class-id.

The other component that exhibits this behavior is sessionstore;1. In Firefox 2, Torbutton was simply able to copy nsSessionStore.js from the Firefox components directory, augment it, and have it get registered in place of the old one. This no longer seems possible. This may be an easier way to reproduce this bug without involving any Torbutton code.

Comment 1

[timeless]

I'm going to assume that code isn't yours, but i feel like commenting on it anyway...

StoreWrapper.prototype =
{
  QueryInterface: function(iid) {

    if (iid.equals(Components.interfaces.nsISupports) ||
        iid.equals(Components.interfaces.nsIClassInfo)) {
      return this.QueryInterface(iid);

this just looks wrong, Unless i'm missing something, if i get a StoreWrapper object and call it.QueryInterface(Components.interfaces.nsISupports), i'll get an exception about infinite recursion, and similarly if i call it.QueryInterface(Components.interfaces.nsIClassInfo).

      if(typeof(store[method]) == "function") {
          obj[method] = function(a, b, c, d, e, f, g) {

is cute, but wrong. you should really use .apply(..., arguments), in case someone's evil and passes extra arguments, or the callee happens to check the argument count. Note that you should really setup proper length for functions (which can be retrieved from arguments.length)

perhaps some amusing reading:
http://viper.haque.net/~timeless/impersonator.js (old, simple)
http://www.webwizardry.net/~timeless/windowStubs.js specifically WrappedNative.prototype.wrapFunction

Comment 2

[Mike Perry]

Ok, I have updated the SVN to reflect your suggestions (hitting that URL should provide an updated crash-observer.js). They seem unrelated to this bug, but I agree making the arguments.length check work is probably a good idea.

The registration problem still remains, and prevents Torbutton from working at all on Firefox 3.

Comment 3

[Mike Perry]

This seems to have been fixed in 3.0beta4.