HWND of Firefox browser on Windows

[Frank]

I am trying to port an Internet Explorer add-on to Firefox. I need to
get the windows handle (HWND) of the Firefox browser so that it can be
passed to an XPCOM component that will be used by my Firefox extension.

How can this be done?

It might be related to nsIEmbeddingSiteWindow and siteWindow. How do I
get the window using Javascript in a Firefox extension.

Thanks,

Frank

[eric...@yahoo.com]

I've never seen a way to get the HWND for a browser (note there is more than one if one than one browser is open) from an XPCOM service or component. That doesn't mean there's no way to do it, but you can alwaysfind the HWND by using the WinAPI to enumerate all top-level windows looking for Firefox's window class.

Thanks,

Frank
_______________________________________________
dev-extensions mailing list
dev-ext...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-extensions

[techguy]

i don't have a direct answer, but some hints.

'window', to me, usually refers to the current Firefox window. it seems
like it more be a little more complicated than that, according to some
code core and extension code i've seen, but it usually works for me.

i'd suggest downloading a couple of big/popular extensions and see how
they work and do these things. just save them to your hard drive and
expand them and search for 'window' and 'getBrowser()' and
'getWindow()' - stuff like that.

i'd also download the mozilla source. lots of good hints in there.

for instance, the core bookmarks.js file has this code in it:

window.openDialog("chrome://browser/content/migration/migration.xul",
"migration", features, "bookmarks");

it looks like 'window' is just implicit - it's certainly not a local
var. it's just somehow there.

sorry i can't be more specific!

[Mook]

The way I've found is to go through nsIBaseWindow.parentNativeWindow;
see the sources in minimizetotray.mozdev.org (core.js, function
getBaseWindow) for getting to a nsIBaseWindow - note that that is
totally in unfrozen stuff land, and might change between revisions of
Gecko. That's why I'm doing it via JS - it's more tolerant of IDL changes.

(I have no idea if going via the Accessibility route - MSAA - would be
of any help in your case, since you'd still need to figure out which
window some how. At least that's more stable...)

HTH,

--
Mook
mook dot moz plus stuff at gmail dot communism

[eric...@yahoo.com]

Wow, that's really cool, Mook... thanks for sharing.

[Frank]

I was able to get the nsIBaseWindow (using the code from
minimizetotray), but the parentNativeWindow property does not exist.

Any other suggestions?

Thanks,

Frank

[John Schultz]

Here's how I solved it using the Win32 API:

http://www.xulplanet.com/forum/viewtopic.php?t=2288

Also see the NPAPI for obtaining the HWND:

http://developer.mozilla.org/en/docs/NPWindow

"Frank" <fspa...@yahoo.com> wrote in message
news:Hq6dnT3Yoc5Jp2rZ...@mozilla.org...

[eric...@yahoo.com]

John,

I'm not sure why you referenced http://developer.mozilla.org/en/docs/NPWindow if you are using the code posted at http://www.xulplanet.com/forum/viewtopic.php?t=2288. The problem with the code posted at http://www.xulplanet.com/forum/viewtopic.php?t=2288 is that the process can have multiple top-level windows. Open multiple FF 1.5.0.7 browsers and look in the Windows task manager--you'll see only a single firefox.exe process. The code at xulplanet.com will only give you one of the associated HWNDs. Maybe that's OK for your needs, but if you need all of the HWNDs, don't return false from your callback function and use an array (or std::list) of HWNDs to store all HWNDs instead of using a single HWND variable.

http://www.xulplanet.com/forum/viewtopic.php?t=2288

http://developer.mozilla.org/en/docs/NPWindow

[John Schultz]

Eric,

For the first version of our project (first time working with
Mozilla/FireFox), we needed any window handle from the current process
(needed by existing windows-handle-based event mechanisms from the ActiveX
control being ported: I created a hidden, subclassed window to process
custom messages- this method is no longer used, and would have been a
problem with multiple windows from the same process, where the user closed a
window with the subclassed hidden window (with the active page in another
window), etc.).

We now understand that we should be using a plugin via the NPAPI instead of
an extension via XPCOM (audio app with no rendering). Getting the window
handle from the NPAPI for a plugin ensures a unique window handle per
instance (also allows gfx rendering if necessary in the future).
Additionally, using the NPAPI with a plugin should also solve installation
restart (provided XPInstall::refreshPlugins() works as documented?) and
javaScript security issues (found with XPCOM when served from a webserver:
no more need to use enablePrivilege("UniversalXPConnect"), signed pages (to
fix enablePrivilege() failure), or other complex methods (our installer is
signed, nsISecurityCheckedComponent is fully implemented)). Another
advantage of using the NPAPI and a plugin implementation: trivial
implementation of callbacks using NPN_GetURL() instead of the more
complicated (to compile, link in C++, and to implement code in javaScript)
nsIObserverService:

void nsScriptablePeer::FireEvent(const char * eventName,PRInt16 wParam) {
#if 0
nsCOMPtr<nsIObserverService> observerService =
do_GetService("@mozilla.org/observer-service;1");
PRUnichar myData[2] = {wParam,0};
observerService->NotifyObservers(reinterpret_cast<nsISupports
*>(this),eventName,&myData[0]); // Requires more complex js setup code.
#else
char jsEventStr[256];
sprintf(jsEventStr,"JavaScript:%s(%d)",eventName,wParam); // Implement
eventName with one param in js as event function handler. Nothing else is
required.
NPN_GetURL(mPlugin->getInstance(),jsEventStr,0);
#endif
} // FireEvent

It might be helpful to have a dedicated documentation repo (less important
to me), along with working, up to date examples (more important to me), for
those porting ActiveX controls to Mozilla. Currently a google search for
"port activex mozilla" returns a non-recommended solution (using the
unsupported wrapper), followed by less relevant hits.

John

<eric...@yahoo.com> wrote in message
news:mailman.6509.11598173...@lists.mozilla.org...