1

I am working on adding support for Firefox 6 for my add-on on Mac OS, where the following logic is working in Firefox 4,5 versions but fails in Firefox 6.

XPCOM component has subclass of IObserverClient and which adds itself as observer for a custom event. This custom event is posted from browser overlay.js passing the selected browser's content window.

var observerService = Components.classes["@mozilla.org/observer-service;1"]
                                .getService(Components.interfaces.nsIObserverService);
if (observerService) {
    var data =  gBrowser.selectedBrowser.contentWindow.location.href;

    observerService.notifyObservers(gBrowser.selectedBrowser.contentWindow, JSEventTopic, data);
}

In XPCOM components handler, trying to get the nsIDOMWindow interface from nsISupports

void XXX::Observe(nsISupports *aSubject, const char *aTopic, const PRUnichar *aData)
{
    nsCOMPtr<nsIDOMWindow> pWin;
    aSubject->QueryInterface(nsIDOMWindow::GetIID(), getter_AddRefs(pWin));
}

The problem is, with Firefox 6 pWin is nil. In Firefox 4 and 5 pWin is as expected and not nil.

Swetha
  • 115
  • 1
  • 7
  • 1
    This is unlikely to be related to your issue but you should consider using [`do_QueryInterface`](https://developer.mozilla.org/en/Using_nsCOMPtr/Reference_Manual#nsCOMPtr.3CT.3E_.3D_do_QueryInterface.28_nsISupports.2A_.29.2CnsCOMPtr.3CT.3E_.3D_do_QueryInterface.28_nsISupports.2A.2C_nsresult.2A_.29): `nsCOMPtr pWin(do_QueryInterface(pSubject));` – Wladimir Palant Aug 22 '11 at 12:49
  • I notice that your `Observe` function uses the parameter name `aSubject`, but the code inside the function uses `pSubject` instead. This might just be a copy-paste error, or it might be a serious problem in your actual code. – Stuart Cook Aug 22 '11 at 13:08
  • Thanks for pointing out , it is a copy-paste error in the post. – Swetha Aug 23 '11 at 03:52

2 Answers2

1

The immediate problem seems to be that whatever object is being delivered as aSubject doesn't implement the nsIDOMWindow interface, which naturally causes the QueryInterface to fail and yield null. You can't QI an object to an interface that it doesn't implement, and you can't QI null to anything.

I don't know off-hand what causred this change, but here are a few things to check that might help you find the real problem:

  • Make sure the subject you're receiving isn't null, and that the pointer you're trying to QI is the argument received by the listener method.
  • In your JavaScript code, check that the window object you're passing isn't nil, and is actually something that should implement nsIDOMWindow.
  • Check that aTopic contains the value you expect, and not some other event string.
Stuart Cook
  • 3,994
  • 25
  • 23
  • Looks like there is nothing wrong with code.I can't exactly figure out what has fixed the problem but removing the binarycomponent directive for this dylib has fixed the problem. With binarycomponent directive specified in chrome.manifest(binary-component components/XXX5.dylib appversion>=5.0,binary-component components/XXX6.dylib appversion>=6.0 )since both are true for FF6 dylib of ver5 and 6 getting loaded,though the proper dylib's code is getting executed.(deleting FF5dylib from components,it works).The proper version of this dylib is loaded another dylib so entry in chrome not required. – Swetha Aug 24 '11 at 04:43
0

I am not much familiar with add-on development. But this works for me in my application(C++). 

nsCOMPtr<nsIDOMWindow> domWindow; 
nsresult rv = mWebBrowser->GetContentDOMWindow(getter_AddRefs(domWindow));

nsCOMPtr<nsIDOMWindowUtils> windowUtils(do_GetInterface(domWindow));
Karthik Mahalingam
  • 1,071
  • 8
  • 10